[dev.icinga.com #11572] icingaweb2-module-graphite schema/templates don't work with check_command=nrpe we are required to use the $service variable

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/11572

Created by mthode on 2016-04-12 00:36:37 +00:00

Assignee: mthode
Status: New
Target Version: (none)
Last Update: 2016-10-06 15:49:05 +00:00 (in Redmine)

---

Because multiple services use the same check_command when using nrpe and '$service' is required to be in the filter string we get into a situation where we are filtering with just the check_command.

In the generic template we have this
icingaService = icinga2.$hostname.services.$service

In my case it resolves to 'icinga2.test_example_com.services.memory-usage'

In the template I wish to use we have this filter.
filter = $icingaService.nrpe.perfdata.free

In my case this expands into 'icinga2.test_example_com.services.memory-usage.nrpe.perfdata.free', unfortunately this will match every other check that has 'nrpe.perfdata.free' at the end too, so I tried to remove the '$service' variable and replace it with the particular service I'm monitoring.

filter = icinga2.$hostname.services.memory-usage.nrpe.perfdata.free

This doesn't work, shows a plain white screen, to show that the service name is correct here's the url to view graphite that icingaweb2 provides.
https://netmon.example.com/icingaweb2/graphite/show/service?host=test.example.com&service=memory-usage&check\_command=nrpe

If I change the filter to the following I get it to work, but it will match too many things.
filter = icinga2.$hostname.services.$service.nrpe.perfdata.free

so in short I'm forced to make generic filters, kinda the opposite intention of a filter I think.

[icinga-migration]

Updated by mthode on 2016-04-12 00:43:09 +00:00

removing this line seems to 'fix' it for me, not sure of other implications, there's another line like it a couple dozen lines up

https://github.com/Icinga/icingaweb2-module-graphite/blob/master/application/controllers/ShowController.php#L231

[icinga-migration]

Updated by mthode on 2016-04-12 00:57:46 +00:00

more info, that variable just needs to be unquoted

[icinga-migration]

Updated by mthode on 2016-04-12 03:15:41 +00:00

• Assigned to set to mthode

Created a PR for this. The PR does not address $hostname being quoted as well, I'm not sure about that as it's usage is more complex and my PHP SUCKS.

#1

[icinga-migration]

Updated by mfriedrich on 2016-04-12 06:07:51 +00:00

• Project changed from Icinga 2 to Graphite
• Category deleted 213

[icinga-migration]

Updated by mthode on 2016-05-24 15:04:56 +00:00

Anything else I need to do with this?

[icinga-migration]

Updated by mthode on 2016-10-06 15:49:05 +00:00

ping?

[rafaelorafaelo]

Hi, same problem here with command "postgres", which is https://bucardo.org/wiki/Check_postgres. I have ~10 services with this command. All templates for this command show up in Icingaweb2, but only the one belonging to the service where I clicked "Graphite" is filled with data. The other templates show "no data".

[Al2Klimov]

As discussed with @bobapple:

@bobapple is going to talk to the colleagues and depending on the number of customers who are using NRPE, check_by_ssh or similar legacies (rel. to the total customers) we will either

1. implement a generic solution for non-Icinga-Agent distributed monitoring or
2. constrain everyone to use Icinga agents.

[bobapple]

Using check_by_ssh and nrpe is still widespread for various reasons, so we need a general solution for the issue.

A possible solution would be to call the Icinga 2 API to get the last executed command. This would require a user to configure a valid api user with sufficient permissions. This is an extra effort the user needs to take. Someday, we will need an implementation of this functionality in Icinga Web 2 anyway (display the executed command for debugging). Building it now only for the graphite module and then building it again for Icinga Web 2 seems not reasonable.

This module should rely on a custom variable "vars.check_command". If this variable is set on a service, it will be used instead of the actual check command. Discussions showed that this solution is more portable to users than requiring an extra api user.

[Al2Klimov]

after #55