Question: where are service.state and service.state_id stored

Icinga 2
1

Hi,
I have defined a service that needs to send the last service.state and service.state_id to the checkcommand

object CheckCommand "some-command" {
    command = [ "python", CustomPluginDir + "monitor_this.py"]
    arguments += {
.....
        "--service_name" = {
        value = "$service_name$"
      }
      "--last_state" = {
        value    = "$service.state$"
      }
      "--last_state_id" = {
        value    = "$service.state_id$"
      }
    }

I have noticed, that when the service is changed to a different zone, the check is executed with the default values:

(from the api: https://localhost:5665/v1/objects/services )
                "last_check_result": {
                    "active": true,
                    "check_source": "icinga",
                    "command": [
                        "python",
                        "/.../monitor_this.py",
                        ...
                        "--last_state",
                        "UNKNOWN",
                        "--last_state_id",
                        "3",
...

Can you tell me where are the values for this runtime objects are stored ?

are they local to the icinga-satellite node?
are they shared among the two icinga-satellites in the zone?
are they pooled from the “master” zone ?

Thanks in advance,

2

Hi,

the runtime macros are evaluated upon check execution. Wherever the service check is fired, this evaluates to their runtime state. Can you share a concrete example how you move the service, and which zone tree is used here?

Cheers,
Michael

3

You could use something like this:

vars.icinga_current_state = {{get_service(host.name, “your service name”).state}}

Within your check command definition you could than access this variable e.g.:

      "-x" = {
         value = "$icinga_current_state$"
         description = "Current state in Icinga"
         }
4

Hi,

we have a hughe datacenter, named ABC, so we are in need of having 6 satellites in there. we do an automated split in 3 children zones: ABC-a , ABC-b, ABC-c, and we have this particular service, that requires the service state.

We have found that when our split script happens to move the host with said service from one zone to the other, the check execution passes the “Unknown” state “3”, ; instead of the value that same service had on the other zone,
which is in line with the idea of the satellite-node generating the check doing the service evaluation.

Thanks for the reply, I’ll look for a work-around

5

Can you share that script, and its design? It would add to understand the described problem here.

Cheers,
Michael

6

will check with my boss, not sure if I can.