systemd.go: Added systemd health metric#113
Conversation
|
Hm~ I understand that you might prefer to still serve The disadvantage of not just stopping to serve that I see is that this approach requires awareness from everyone who writes alerts based on this exporter, because apart from the standard alert on Thoughts? |
jpds
force-pushed
the
health-metric
branch
2 times, most recently
from
a80d5ba to
1392149
Compare
To me, a 5xx error would mean that someone made a serious programming error.
This is just a fact of life when it comes to different exporters exposing different metrics and the vast majority use their name as a prefix, I can see |
| c.scrapeSuccessDesc, prometheus.GaugeValue, 1, namespace) | ||
| } | ||
|
|
||
| ch <- prometheus.MustNewConstMetric(c.scrapeDurationDesc, prometheus.GaugeValue, time.Since(begin).Seconds(), namespace) |
There was a problem hiding this comment.
This doesn't make sense to me, as it's not actually exposing metrics per collector that I can tell. namespace is always systemd, so the label would always be collector="systmed".
This means it's no different than up and scrape_duration_seconds recorded by Prometheus.
There was a problem hiding this comment.
We didn't have collectors up until this point - will fix that in a bit.
The standard for Prometheus is to return a 5xx error for failed scraps. Some exporters do what you're proposing here, but in general it's not encouraged to do this. |
SuperQ
left a comment
SuperQ
left a comment
There was a problem hiding this comment.
This needs a rebase with the change to the new logging library.
Fixes: prometheus-community#112 Signed-off-by: Jonathan Davies <jpds@protonmail.com>
3 participants
Fixes: #112