Icinga 2 - Database - cars.Arguments

Dear community,

i just migratet our configration to Icinga2.
I missing some Values in the database, and im not sure where these Arguements…

We got for example, in the commands.conf following check:

# 'check_tcp' command definition
object CheckCommand  "check_tcp" {
  command = [ PluginDir + "/check_tcp", "-H", "$address$", "-p$service.vars.ARG1$", "$service.vars.ARG2$"]

Now i’m looking for service.vars.ARG1 and service.vars.ARG2 in the database, and i cant finde the values, in the icinga_services table.

Where are the Arguments saved in the database.
Has somebody a hint for me?

Best regards,

They’re in icinga_customvariables, but you’ll probably find it’s easier to query via the API (json objects are returned).

What exactly are you trying to gather these from IDO for?

Hi thanks for the fast answer,

we havesome passive checks in our old configuration, which we like to run against the database, but in our script, the arguments are necassary, so i have to find an sql statemant, where i can see the the display name, check_command_object_id from the icinga services, the host object_id from the icinga_hosts and the arguments from the icinga_services.

so i need to understand the database connections.


such a command definition is not considered best practice. Always use the arguments attribute and refine the specific arguments and parameters in there. Especially ARGx from the old world is not very readable, use the proposed long and telling names.

Since there’s also the tcp CheckCommand object available inside the Icinga Template Library, I highly recommend that you’re going this route.

Bonus: address is already set.

apply Service "tcp" {
  check_command = "tcp"

  vars.tcp_port = 22
  vars.tcp_ssl = true
  vars.tcp_ipv4 = true


I’m not sure about ARG2 here, since it is a standalone parameter - my guesses are either -4/-6 or -S for enabling TLS.

As you can see, a telling name for that attribute also would allow others to better understand the meaning :wink:

Once you have those better names, it is far more easy to search for them inside the database as well. The custom vars are stored in an extra table and require some more joins.

select * from icinga_objects so join icinga_customvariables cvs on so.object_id=cvs.object_id where so.name1='hostname' and so.name2='servicename' and cvs.varname='tcp_port';

(I have not tested the above, should work.)