[dev.icinga.com #6918] Out of the box support of PNP4Nagios

[icinga-migration]

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

Created by dgoetz on 2014-08-14 14:14:25 +00:00

Assignee: (none)
Status: Closed (closed on 2016-01-13 16:41:10 +00:00)
Target Version: (none)
Last Update: 2016-01-13 16:41:10 +00:00 (in Redmine)

Icinga Version: 2.0.2

---

Not sure if this should be classified as a bug, but at least it is small documentation bug, mostly use it as feedback.

PNP4Nagios uses the old style for check command names prefixed with check_ in all its configuration and to find their templates. On one hand this could be changes by some links on the filesystem, on the other with the following PerfdataWriter configuration:

object PerfdataWriter "perfdata" {
    host_format_template = "DATATYPE::HOSTPERFDATA\tTIMET::$icinga.timet$\tHOSTNAME::$host.name$\tHOSTPERFDATA::$host.perfdata$\tHOSTCHECKCOMMAND::check_$host.check_command$\tHOSTSTATE::$host.state$\tHOSTSTATETYPE::$host.statetype$"
    service_format_template = "DATATYPE::SERVICEPERFDATA\tTIMET::$icinga.timet$\tHOSTNAME::$host.name$\tSERVICEDESC::$service.name$\tSERVICEPERFDATA::$service.perfdata$\tSERVICECHECKCOMMAND::check_$service.check_command$\tHOSTSTATE::$host.state$\tHOSTSTATETYPE::$host.statetype$\tSERVICESTATE::$service.state$\tSERVICESTATETYPE::$service.statetype$"
    }

From documentation I had to change checkcommand to check_command, service.description to service.name and include the prefix check_.

Changesets

2014-08-14 14:32:51 +00:00 by (unknown) 92448a2

Documentation: s/service\.description/service\.name/

refs #6918

---

Relations:

• relates #6858
• relates #6918

[icinga-migration]

Updated by mfriedrich on 2014-08-14 14:37:37 +00:00

• Description updated

• service.description is a documentation bug, the default setting already uses service.name. Fixed in git.
• for the pnp templates - imho the check names should remain 1:1 and it's the addons reponsibility to provide the correct templates. Other than that, use your own custom CheckCommand objects matching the PNP templates available (which isn't really the right way to go).

[icinga-migration]

Updated by gbeutner on 2014-08-15 08:35:36 +00:00

Here's a workaround which lets you overwrite the PNP service name in case some of your check commands already have a name which matches check_*:

template Service "generic-service" {
  vars.pnp_check_name = "check_$command.name$"
}

service_format_template = "... SERVICEDESC::$pnp_check_name$ ..."

template Service "http-service" {
  check_command = "check_http"
  vars.pnp_check_name = "check_http" // Overwrite pnp_check_name because otherwise this would be "check_check_http"
}

[icinga-migration]

Updated by dgoetz on 2014-08-28 07:23:51 +00:00

Used your workaround and works fine with some tweaks.

template Host "generic-host" {
  max_check_attempts = 5
  check_interval = 5m
  retry_interval = 1m

  check_command = "hostalive"
  vars.pnp_check_name ="check_$host.check_command$"
}

template Service "generic-service" {
  max_check_attempts = 3
  check_interval = 5m
  retry_interval = 1m
  vars.pnp_check_name ="check_$service.check_command$"
}

Now I am struggeling with the next problem. Remote check commands like nrpe I can configure in pnp4nagios to use the first argument, but with icinga2 I have no arguments when I use variables like var.nrpe_command. Of course I can manually set vars.pnp_check_name to check_nrpe!check_disk or just to check_disk, but is there a way to automatically do this?

Like in pseudo code:
if var.nrpe_command is unset
then vars.pnp_check_name = "check_$service.check_command$"
else vars.pnp_check_name = var.nrpe_command

[icinga-migration]

Updated by mfriedrich on 2014-08-28 07:29:48 +00:00

• Relates set to 6858

[icinga-migration]

Updated by mfriedrich on 2015-01-12 09:52:28 +00:00

• Category changed from Perfdata to Documentation

[icinga-migration]

Updated by davidak on 2015-01-13 16:33:20 +00:00

i tried to implement this workaround in my setup.

if/else is not yet implemented in icinga2: https://blog.netways.de/2015/01/09/neue-features-in-icinga-2-3/

so i added a templatte to all nrpe services, but that didn't work. i gave up :/

template Service "generic-service" {
  max_check_attempts = 3
  check_interval = 5m
  retry_interval = 1m
  vars.pnp_check_name ="check_$service.check_command$"
}

template Service "nrpe-pnp4nagios-check-name" {
  vars.pnp_check_name ="check_$service.check_command$$vars.nrpe_command$"
}


apply Service "crm" to Host {
  import "generic-service"
  import "nrpe-pnp4nagios-check-name"
  display_name = "ClusterManager"
  check_command = "nrpe"
  vars.nrpe_command = "check_pacemaker"
  assign where "nrpe" in host.groups && "pacemaker" in host.groups
}

it would be helpful if icinga2 works by default with pnp4nagios!

[icinga-migration]

Updated by mfriedrich on 2015-01-13 16:45:54 +00:00

You'll likely forgot to adapt the service template using the different macro for the checkcommand name.

'service_format_template'

Imho it's not a matter of support in Icinga 2, but rather a documentation issue. And it doesn't look like PNP will officially support Icinga 2 so everyone is invited to help update the documentation finding a reasonable way to document common pitfalls (and yes, the checkcommand name and arguments are such a thing, as they are automagic and uncontrollable).

http://dillinger.io & git format-patch

PS: I highly doubt that if/then/else will solve this issue without further documentation & adaptions.

[icinga-migration]

Updated by dgoetz on 2015-01-21 08:23:18 +00:00

@davidak: You missed the exclamation mark between the two values:

vars.pnp_check_name ="check_$service.check_command$!$vars.nrpe_command$" 

But it would also work like:

vars.pnp_check_name ="$vars.nrpe_command$" 

This would remove the lookup over custom template

@dnsmichi:
"And it doesn't look like PNP will officially support Icinga 2" -> I had a talk with the pnp developer at osmc and he said he likes to implemented support if icinga team tells him what is needed / if somethingis needed, at the moment he has not many work to do on pnp but also not that many time to try icinga 2 on its own.

[icinga-migration]

Updated by mfriedrich on 2015-01-23 13:12:09 +00:00

I had an idea, but I don't have time to implement a patch or document it anywhere.

Patch for PNP:

• define an attribute in the host/service perfdata template, similar to "SERVICECHECKCOMMAND::", give it the name "PNPTEMPLATENAME::"
• make sure process_perfdata.pl understands the attribute and stores the value inside the updated XML file
• ensure that the PNP frontend uses this attribute prior to looking up the checkcommand value automatically

Icinga 2:

• modify the default PerfdataWriter templates to use "PNPTEMPLATENAME::" and set the default value inside the generic templates as custom attribute

While it does not really solve the problem itself, it still shows a possibility to pass pnp template names to PNP, no matter which core is used. Feel free to propose/discuss that with the PNP developers.

[icinga-migration]

Updated by mfriedrich on 2015-04-27 12:17:37 +00:00

• Relates set to 9185

[icinga-migration]

Updated by mfriedrich on 2016-01-13 16:41:11 +00:00

• Status changed from New to Closed

Everything which works so far as a workaround probably is the best we can do. I have no further ideas, and instead of leaving this issue open forever without any comments, I'll close it as no-more-fix.