Migrating from Icinga 1.x using custom attributes and variables

Icinga 2
1

Hey guys,

I’m migrating from Icinga 1.x and I have the following custom check command:

define command {
command_name check_hosts
command_line $NAGIOSDIR$/check_hosts -10 -H $HOSTADDRESS$ -s -c $VAR1$ -a $VAR2$ $VAR3$
}

I know it goes something like:

object CheckCommand “check_hosts” {
command = [
NagiosDir + “/check_hosts” “-5”
]

arguments = {
    "-H" = "$host_address$"
    ...
}

How am I suppose to translate the arguments $VAR1$ $VAR2$ and $VAR3$?

Thanks!

2

Hi,

first off, you should read about arrays and their elements. Your example won’t work this way, array elements need a comma separator.

Second to that, the first argument looks fine. Since you’ve seen those VAR arguments, I would change them into more telling names. “-c” has a purpose, “-a” has one and the last one seems to be free floating for the plugin itself. Or it uses the same principle as nrpe with -a, I am not sure about that - provide real names next time.

Typically what’s shown here.

Also, we encourage everyone to use the PluginDir constant, don’t redefine that by yourself with NagiosDir or similar.

You can see that I’ve also removed the check_ prefix, it is not needed since you already are descriting a CheckCommand object.

object CheckCommand “hosts” {
  command = [
   PluginDir + “/check_hosts”, “-5”
  ]

In terms of the arguments, it is best practice to not only set the value, but move that one level down and add a description field. This can be used later on and helps to immediately see what’s meant here.

Also, keep the prefix of the CheckCommand object being hosts_ for any references custom attribute.

  arguments = {
    "-H" = {
      value = "$hosts_address$"
      description = "The host address (defaults to host.address)"
    }

    "-c" = {
      value = "$hosts_command$" //just a guess
      description = "..."
    }
    "-a" = {
       value = "$hosts_arguments$" //assuming that var2 and var2 are solely meant for -a
       description = "Additional arguments"
       repeat_key = false //do no repeat "-a" for each array element passed on the shell
    }

Now define some default values for the parameters, e.g. the host address which can be used just


  //define a default lookup for the host's address, same as inside the ITL
  vars.hosts_address = "$address$"
}

Then you are good to go. Reading this command definition against sounds like you are rebuilding NRPE as CheckCommand, but using check_hosts instead. Might be worthwhile to re-evaluate the plugin and use a different agent method then too.

A typical service apply rule for this CheckCommand would look this this - make sure to have understood how command parameters work.

apply Service "my-hosts" {
  check_command = "hosts"

   vars.hosts_command = "somecommand" // 
   vars.hosts_arguments = [ "somevar2value", "somevar3value" ]

  //...
}

It would help if you show the original check command and service definition. $VAR1$ isn’t a valid syntax in 1.x :wink:

Cheers,
Michael

1 Like
3

Hey Michael,

Sorry for not providing the real names, I got this example on google. The things files I need to migrate are not as complex as this one, so I used the hardest example. Anyway, in the Migrating Docs, there is this example:

define command {
command_name my-ping
command_line $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -p 5
}

and it goes in icinga 2 like:

object CheckCommand “my-ping-check” {
command = [
PluginDir + “/check_ping”, “-4”
]

arguments = {
…
}

…
}

What is the “-4” parameter in the command = [ ]? Is it the number of parameters the command_line will get?

And also, can I keep some arguments in the command brackets, like:

command = [
PluginDir + "/check_host " “-H” “$hosts_address”
]

arguments = {
…
}

Thanks

4

Hi,

“-4” is a command parameter for check_ping, without any passed value. For simplicity this is left inside the command array and not moved into the key-value arguments dictionary.

While at it, evaluate which CheckCommand objects are already available inside the ITL - ping is one of them, no need to re-invent the wheel. Just transform the parameters into a service apply rule like this:

apply Service "ping4" {
  check_command = "ping4"

  vars.ping_wrta = 200 //single values for each threshold
  vars.ping_crta = 10
  vars.ping_wpl = 400
  vars.ping_cpl = 30

  vars.ping_packets = 10 //defaults to 5 already
}

For the more custom check commands, do you have a really hard example too? :kissing_heart:

Cheers,
Michael

1 Like