-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
prometheus metrics output #291
Comments
Note that there's some overlap between this and the node exporter's support for such thing. This was requested in prometheus/node_exporter#625 but actually implemented in the "collectors" project. It only tracks the |
I'm open for changes required for a metrics endpoint. 👍 |
I just came across this project that might be a good solution: https://git.fsmpi.rwth-aachen.de/thomas/needrestart2prom/-/tree/main |
This new `-o` option will make needrestart output information in a format that can be scraped by Prometheus or any other daemon that ingests OpenMetrics format. The -l, -w and -k options can be used in combination with -o in order to choose what information gets exported. (Closes: liske#291)
This new `-o` option will make needrestart output information in a format that can be scraped by Prometheus or any other daemon that ingests OpenMetrics format. The -l, -w and -k options can be used in combination with -o in order to choose what information gets exported. Note that the combination of options -ol needs root access in order to correctly determine which services use outdated libraries. The kernel and microcode statuses are output as StateSet type metrics since there are more than one states for each one. This way users can track the state with more granularity and for example decide to ignore "unknown" microcode state or "version_upgrade" (e.g. non ABI-compatible upgrade) kernel state. For kernel and microcode, there's one Info type metric each that informs of the currently running vs. the expected newer version. (Closes: liske#291)
Hi!
We're (possibly) transitioning away from Icinga to Prometheus for our monitoring down here and it would be quite nice to have the equivalent functionality to Icinga, but as an OpenMetrics endpoint.
I am not exactly sure what the metrics would be like. It seems to me there could be different metrics for kernel, ucode, and services, possibly with a separation between user and system services. So something like this, maybe:
It would probably need gauges for containers and sessions too...
Would people here be open to this idea?
The text was updated successfully, but these errors were encountered: