Skip to content
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

Closed
anarcat opened this issue Nov 22, 2023 · 3 comments · Fixed by #308
Closed

prometheus metrics output #291

anarcat opened this issue Nov 22, 2023 · 3 comments · Fixed by #308
Labels

Comments

@anarcat
Copy link
Contributor

anarcat commented Nov 22, 2023

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:

# HELP needrestart_timestamp information about the running version and when it was last updated
# TYPE needrestart_timestamp gauge
needrestart_timestamp{version=3.6} 1700675409
# HELP needrestart_kernel_info information about the kernel
# TYPE needrestart_kernel_info info
needrestart_kernel_info{running=6.5.0-1-amd64,expected=6.5.0-1-amd64,status="current"} 1
# HELP needrestart_ucode_info information about the CPU microcode
# TYPE needrestart_ucode_info info
needrestart_ucode_info{running=0x042c,expected=0x042c,status="current"} 1
# HELP needrestart_services_count number of services requiring a restart
# TYPE needrestart_services_count gauge
needrestart_services_count = 3

It would probably need gauges for containers and sessions too...

Would people here be open to this idea?

@anarcat
Copy link
Contributor Author

anarcat commented Nov 22, 2023

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 reboot-required file, however...

@liske
Copy link
Owner

liske commented Mar 3, 2024

I'm open for changes required for a metrics endpoint. 👍

@tewfik-ghariani
Copy link

I just came across this project that might be a good solution: https://git.fsmpi.rwth-aachen.de/thomas/needrestart2prom/-/tree/main

lelutin pushed a commit to lelutin/needrestart that referenced this issue Jul 30, 2024
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)
lelutin pushed a commit to lelutin/needrestart that referenced this issue Jul 31, 2024
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)
@liske liske closed this as completed in #308 Aug 9, 2024
@liske liske closed this as completed in b372b17 Aug 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants