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

delta perfdata counters #5322

Closed
cbnorman opened this issue Jun 4, 2017 · 6 comments
Closed

delta perfdata counters #5322

cbnorman opened this issue Jun 4, 2017 · 6 comments
Labels
area/metrics General metrics handling no-issue Better asked in one of our support channels

Comments

@cbnorman
Copy link

cbnorman commented Jun 4, 2017

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:

  1. calling the API twice in my check.
  2. working out the delta in my checks

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.

@dnsmichi
Copy link
Contributor

dnsmichi commented Jun 6, 2017

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.

@tobiasvdk
Copy link
Contributor

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

@cbnorman
Copy link
Author

cbnorman commented Jun 9, 2017

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

"performance_data": {metric1 = (new_value1 -$service.last_check_result.performance_data.label == 'metric1').value};0;0;0, metric2 = (new-value2 -$service.last_check_result.performance_data.label == 'metric2').value};0;0;0

@cbnorman
Copy link
Author

cbnorman commented Jun 9, 2017

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?

@dnsmichi dnsmichi added the area/metrics General metrics handling label Jun 9, 2017
@Stefar77
Copy link
Contributor

Stefar77 commented Jul 15, 2017

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...

@dnsmichi
Copy link
Contributor

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.

@dnsmichi dnsmichi added no-issue Better asked in one of our support channels and removed no-issue Better asked in one of our support channels question labels May 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/metrics General metrics handling no-issue Better asked in one of our support channels
Projects
None yet
Development

No branches or pull requests

4 participants