I am currently working on a monitoring for our new EDI System, BISv6.7 for Seeburger.
I was told by the Seeburger consultant that they implemented an exporter for Prometheus and this would be their preferred way of monitoring.
I don’t want to install a Prometheus instance just for this.
As the node exporter is reachable via HTTP/HTTPS protocol and the output seems to be in a structure that could be parsed, I am wondering if not already someone tried to develop a Datasource Agent to acquire the data from a node exporter.
At least at the know places I found nothing useful.
Am i wrong, but the documentation explicit talks about a connection to a node exporter?
As from your description and the documentation it seems exactly like what are you looking for.
(linked the german version )
Thanks tosch, as far as I understood this, it connects to the Prometheus server and not to the node itself. The config option just define the initial data source.
Nevertheless I will have a look at the code if I find something useful.
@mike1098 mentioned it already correctly. There is no native connection to a node exporter.
However, if you look into the new Kubernetes special agent, you will see methods how to parse Prometheus metrics. Because that’s what is happening there massively.
May you can explain this for a poor schoolboy like me
If I do a curl to the node exporter I get mainly key/value pairs
# HELP go_memstats_alloc_bytes Number of bytes allocated and still in use.
# TYPE go_memstats_alloc_bytes gauge
# HELP go_memstats_alloc_bytes_total Total number of bytes allocated, even if freed.
# TYPE go_memstats_alloc_bytes_total counter
# HELP go_memstats_buck_hash_sys_bytes Number of bytes used by the profiling bucket hash table.
# TYPE go_memstats_buck_hash_sys_bytes gauge
# HELP go_memstats_frees_total Total number of frees.
# TYPE go_memstats_frees_total counter
For some we see also items in the key:
# TYPE node_cpu_scaling_frequency_max_hertz gauge
# HELP node_cpu_scaling_frequency_min_hertz Minimum scaled CPU thread frequency in hertz.
# TYPE node_cpu_scaling_frequency_min_hertz gauge
Looks to me as pretty good parsable but maybe I overlocked something
Did you create a custom datasource program for the prometheus output?
I have a similar case where we have a Sonatype Nexus application which has an API for metics. They serve a JSON format as well as a prometheus format, both are not supported right now bij CheckMK.
The prometheus format seems easier since CheckMK would already know how to handle this data format by the node export functionality, except that it needs some customization to handle the data directly.
I have encountered even more applicable applications that would benefit from being able to handle prometheus exporter data:
Jenkins with Prometheus plugin
RabbitMQ with rabbitmq_prometheus plugin
This is useful when there is no possibility to install a CheckMK agent, but another benefit of using the prometheus data is that there are also many application specific checks in the prometheus data, for instance a license expiry check in SonarQube.