Conversation
|
I don't see a blocker from the Pushgateway side. There are many options how the PGW could incorporate this. If it's not the client library taking the target_info as a default for the grouping key, it could even be done by the PGW itself. |
|
|
||
| def _target_info_metric(): | ||
| m = Metric('target', 'Target metadata', 'info') | ||
| m.add_sample('target_info', self._target_info, 1) |
There was a problem hiding this comment.
I see, would it be required to also emit an actual value (i.e. in this case 1) or could we avoid that perhaps and special case it in the parser that metrics without a value are info metrics?
There was a problem hiding this comment.
This is a standard info metric, so the value of 1 is required.
c5eceed to
41f7165
Compare
|
I've added unittests, and a basic check that we're not exporting two target_infos. |
| if labels: | ||
| if not self._target_info and 'target_info' in self._names_to_collectors: | ||
| raise ValueError('CollectorRegistry already contains a target_info metric') | ||
| self._names_to_collectors['target_info'] = None |
There was a problem hiding this comment.
I'm a little confused about this one, from my rudimentary understanding (or extreme rudimentary understanding should I say) - every value in _names_to_collectors should be a collector yeah?
If None is a value in _names_to_collectors and then it gets added to collectors var in restricted_registry:
names = set(names)
collectors = set()
metrics = []
with self._lock:
for name in names:
if name in self._names_to_collectors:
collectors.add(self._names_to_collectors[name])
if 'target_info' in names and self._target_info:
metrics.append(self._target_info_metric())
for collector in collectors:
for metric in collector.collect():
samples = [s for s in metric.samples if s[0] in names]
if samples:
m = Metric(metric.name, metric.documentation, metric.type)
m.samples = samples
metrics.append(m)Wouldn't the collector.collect() be a call to None from the line for metric in collector.collect() if names happens to contain target_info?
|
Hm, I was able to reproduce the issue I described in the comment I left: |
This allows target labels as needed by push-based systems to be provided, in a way that doesn't mess up Prometheus's own top-down pull based approach to SD. Signed-off-by: Brian Brazil <brian.brazil@robustperception.io>
41f7165 to
7c1cefd
Compare
|
Right you are, fixed and unittest added. |
This allows target labels as needed by push-based systems to be
provided, in a way that doesn't mess up Prometheus's own
top-down pull based approach to SD.
@SuperQ @RichiH @robskillington @sumeer Here's roughly what I'm thinking. Needs unittests etc.
@beorn7 Your input would be appreciated on the pgw front. prometheus/OpenMetrics#63 is the general background. Pgw could continue to do this out of band for grouping labels (potentially with the client library using this as a default), or have this as an option.