-
Notifications
You must be signed in to change notification settings - Fork 580
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
delta perfdata counters #5322
Comments
I'm wondering how this relates to Icinga 2. That sounds more of a plugin logic question, and without knowing much details about it, hard to answer. I suggest to ask on the community channels how others deal with that problem. |
Maybe you can add parameters to your plugin which have the values of the last check result performance data. A quick test with the dummy CheckCommand: apply Service "test-check-result" {
import "generic-service"
check_command = "dummy"
vars.dummy_text = {{ "$service.last_check_result.execution_start$" }}
assign where host.address
} The dummy command does not have performance data, so you have to play around a little bit. For the CheckResult type see https://docs.icinga.com/icinga2/latest/doc/module/icinga2/toc#!/icinga2/latest/doc/module/icinga2/chapter/value-types#value-types-checkresult |
thats sort of what im doing now now, using those macros from the initial get request, except i then minus from the new result before sending. im looking for an icinga function so i could do something like
|
alternatively I'm wondering if it would be preferable to simply send the perfdata with no service state (if thats possible). icinga2 writes that to influx/grafana and then one the 2 updates the service state when it matches a threshold? |
I would use Memcached or Redis for this (Only use API if there is no hit from cache). Or just try and push the last state / performance data back to the plugin in a parameter... |
This is best to be solved with external fast storage resources. I don't think that there's a reliable solution for a built-in access. |
I have been writing custom checks for a while now and more recently utilizing performance data. I could be going about this the wrong way so id welcome anyone pointing me in the right direction.
basically i have a number of checks ive written which query things like switch interfaces, the problem is every time the check runs i each metric is since the switch or server last rebooted and i need to write thresholds based on the last time the check completed. so currently i have resorted to querying the icinga API to get the last recorded metrics of that service, running the check and subtracting the icinga API result from the new result creating the delta. i then send the result agian using the icinga2 API as a passive check.
two points id like to improve:
Ideally id like to specify when sending the new metric that its a counter that id like the delta recorded. using the UOM 'c' doesnt seem to really do anything. if there anything i can do to improve this process?
thanks in advance.
The text was updated successfully, but these errors were encountered: