Closed adrianlzt closed 1 year ago
This sounds like a good idea. However, i am a bit concerned about the change in format. Before this change, the perfomance data was a single line of tab separated text. Custom Variables are now added with newlines. This might break current performance data consumers. Also this patch potentially increases the payload a lot when having huge custom variables. So i think it would be good to make it optional. Or it would be nice to define a few custom variables which should be exported. Finally, if we could add a custom prefix to the export, ex. Nagflux could directly add custom variables as tags or values into the influxdb (https://github.com/Griesbacher/nagflux/commit/7c28bcf6a1df7ee38fb6042ddd06ce8fff80540e#diff-4ac32a78649ca5bdd8e0ba38b7006a1eR3)
Thinking about it, adding a "perfdata template" setting would solve all those issues with a single setting.
I have used newlines because I saw it was already used:
"HOSTSTATETYPE::%d\n"
"HOSTINTERVAL::%f\n\n",
Thanks for the pointer to nagflux, I was starting to develop something similar. But it doesn't solve my problem neither. I want to send each metric to a different influxdb database selected by a host custom variable (_HOSTPROJECT).
What's the idea with "perfdata template"?
What's the idea with "perfdata template"?
Something like the service_perfdata_file_template
and host_perfdata_file_template
option in Nagios/Icinga. Should be even possible to reuse the parse/expand functions from nagios/icinga for that since mod-gearman runs in the same memory.
please reopen if its still relevant.
With these changes custom variables are now added to the perfdata.
Could be useful to other metric consumers to handle the data according to these variables.
Example ouput for a service with a custom variable owned by a host with two custom variables: