# How do I call the variable "service.state\_id" from a different host and service?

**URL:** <https://community.icinga.com/t/how-do-i-call-the-variable-service-state-id-from-a-different-host-and-service/13246>\
**Category:** Icinga 2\
**Created:** [February 9, 2024, 8:37am UTC](https://community.icinga.com/t/how-do-i-call-the-variable-service-state-id-from-a-different-host-and-service/13246 "2024-02-09T08:37:26Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![j\_t](https://community.icinga.com/letter_avatar_proxy/v4/letter/j/57b2e6/32.png) [@j\_t](https://community.icinga.com/u/j_t)\
**Post date:** [February 9, 2024, 8:37am UTC](https://community.icinga.com/t/how-do-i-call-the-variable-service-state-id-from-a-different-host-and-service/13246/1 "2024-02-09T08:37:26Z")

</div>

Hi, I think I have a misunderstanding in using variables, but I am not able to fix it myself and I only find references for Nagios (wich state that it should work that way). Help is appreciated.

I am using a current Icinga2 with director on RHEL8

What I want to do:  
check 2 Service States via check\_cluster, return OK, wenn both ok, otherwise warn/critical.

What works:  
Running the check with -d “1,1” (or 0,1, 0,0, etc.) gives a valid result, so the basic check is correctly implemented.

What does not work (entered in the corresponding box in director):  
`$$SERVICESTATEID:hostname:servicename$$;$$SERVICESTATEID:hostname:servicename$$`  
returns always OK, no matter what the service state is (or indeed, if that service is existing at all). The check itself does not seem to handle errors within “-d” as soon as there is a “$” and always returns OK.  
Also tried  
`$$service.state_id:hostname:servicename$$;$$service.state_id:hostname:servicename$$`  
with the same result.

---

<div class="post-metadata">

**Author:** ![rivad](https://community.icinga.com/user_avatar/community.icinga.com/rivad/32/5852_2.png) [@rivad](https://community.icinga.com/u/rivad)\
**Post date:** [February 9, 2024, 8:56am UTC](https://community.icinga.com/t/how-do-i-call-the-variable-service-state-id-from-a-different-host-and-service/13246/2 "2024-02-09T08:56:28Z")

</div>

`$$service.state_id:hostname:servicename$$;$$service.state_id:hostname:servicename$$` looks very off. Try `$host.name$` and `$service.name$` so dollar signs around every single variable and double them up in the director to escape them like this `$$host.name$$`.

---

<div class="post-metadata">

**Author:** ![j\_t](https://community.icinga.com/letter_avatar_proxy/v4/letter/j/57b2e6/32.png) [@j\_t](https://community.icinga.com/u/j_t)\
**Post date:** [February 9, 2024, 1:59pm UTC](https://community.icinga.com/t/how-do-i-call-the-variable-service-state-id-from-a-different-host-and-service/13246/4 "2024-02-09T13:59:57Z")

</div>

Sorry… my last post was wrong, so I deleted it.

hostname & servicename where just my placeholders, no variables. They are manually filled with the right values.

“check\_cluster” expects for “-s” a comma separated list of values. The value being 0,1,2,3

I need the service.state\_id of service X on host Y but I have no Idea how.

$$SERVICESTATEID:hostname:servicename$$ contained that value (the current state of the service) in Nagios. Obviously it does not contain that value in Icinga, as I used the Nagios way, but how do I get that value correctly?

Icinga has a different approach I understand: [Monitoring Basics - Icinga 2](https://icinga.com/docs/icinga-2/latest/doc/03-monitoring-basics/)).  
But I don’t understand how to retrieve that value from any service from any host. (The check collects various states)

---

<div class="post-metadata">

**Author:** ![rivad](https://community.icinga.com/user_avatar/community.icinga.com/rivad/32/5852_2.png) [@rivad](https://community.icinga.com/u/rivad)\
**Post date:** [February 9, 2024, 2:41pm UTC](https://community.icinga.com/t/how-do-i-call-the-variable-service-state-id-from-a-different-host-and-service/13246/5 "2024-02-09T14:41:27Z")

</div>

I don’t know check\_cluster but maybe I did something similar with the Icinga2 DSL.

This checks if all services with the same name on all nodes of a cluster host are OK:

```auto
object CheckCommand "116-cmd-more-then-halve" {
    import "plugin-check-command"
    command = ["/usr/lib64/nagios/plugins/dummy"]
    timeout = 10s
    arguments += {
        "--message" = {
            required = false
            value = {{
                var output_status = ""
                var up_count = 0
                var down_count = 0
                var cluster_nodes = macro("$116_cluster_nodes$")
                var more_then_halve_service_name = macro("$116-cluster-more-then-halve-service$")
            
                for (node in cluster_nodes) {
                  if (get_service(node, more_then_halve_service_name).state > 0) {
                    down_count += 1
                  } else {
                    up_count += 1
                  }
                }
            
                if (up_count > down_count) {
                  output_status = "OK: "
                }
                if (up_count == down_count) {
                  output_status = "WARNING: "
                }
                if (up_count < down_count) {
                  output_status = "CRITICAL: "
                }
            
                var output = output_status
            
                for (node in cluster_nodes) {
                  output += node + ": " + more_then_halve_service_name + ": " + get_service(node, more_then_halve_service_name).last_check_result.output + " "
                }
            
                output += " | count_of_alive_" + more_then_halve_service_name +"="+up_count+";" + string((up_count + down_count) / 2 + 1) + ":;" + string((up_count + down_count) / 2 ) + ":;0;" + string(up_count + down_count)
                log(output)
                return output
            }}
        }
        "--state" = {{
            /* Icinga 2 does not export DSL function bodies via API */
        }}
    }
}

```

The dummy check comes from the Linuxfabrik’s monitoring-plugins and just reports back, what you send it - it was necessary because of a limitation in the director.

It looks like this in the director:

 ![image](https://community.icinga.com/uploads/default/original/2X/2/2299ffbe279fd03b2f9e74fb44425850c0e75e56.png)  
 ![image](https://community.icinga.com/uploads/default/original/2X/f/f3565a3dd7d5c2e87a27e4e49bd9fde7cd128728.png)  
 ![image](https://community.icinga.com/uploads/default/original/2X/6/6d551c098e69ef44943bd6a2bf38bb1aac17fa2a.png)  
 ![image](https://community.icinga.com/uploads/default/original/2X/9/9d0cea9581533ec937175d07300c3ee3b68978a4.png)  
 ![image](https://community.icinga.com/uploads/default/original/2X/e/e923fb0f2a9b3c3e33450041ea88790a78709c07.png)

same for the host check:

 ![image](https://community.icinga.com/uploads/default/original/2X/5/5671880f6603f7fbec10cbcfeb7f3c8e4fe1685d.png)

---

<div class="post-metadata">

**Author:** ![j\_t](https://community.icinga.com/letter_avatar_proxy/v4/letter/j/57b2e6/32.png) [@j\_t](https://community.icinga.com/u/j_t)\
**Post date:** [February 9, 2024, 3:07pm UTC](https://community.icinga.com/t/how-do-i-call-the-variable-service-state-id-from-a-different-host-and-service/13246/6 "2024-02-09T15:07:23Z")

</div>

I think this looks basically the same (in a more flexible way than check\_cluster) than what I would like to archieve, but the simple approach of check\_cluster would suffice for my stuff. I also think its not an issue of the check.

I think if I can answer the rather universal question:

**How do I call the variable “service.state\_id” from a different host and service?**

The check should work perfectly. I changed the header accordingly. My issue is not check\_cluster.

---

<div class="post-metadata">

**Author:** ![rivad](https://community.icinga.com/user_avatar/community.icinga.com/rivad/32/5852_2.png) [@rivad](https://community.icinga.com/u/rivad)\
**Post date:** [February 9, 2024, 3:27pm UTC](https://community.icinga.com/t/how-do-i-call-the-variable-service-state-id-from-a-different-host-and-service/13246/7 "2024-02-09T15:27:21Z")

</div>

In the director you can only use the DSL in command arguments.  
By rearranging the code blocks above you could feed your state\_ids into your cluster\_check.

If you write the icinga config by hand you’re more flexible and can get any host!service.state\_id, in a service, host or command object, to pass it to check\_cluster.

---

<div class="post-metadata">

**Author:** ![j\_t](https://community.icinga.com/letter_avatar_proxy/v4/letter/j/57b2e6/32.png) [@j\_t](https://community.icinga.com/u/j_t)\
**Post date:** [February 9, 2024, 3:35pm UTC](https://community.icinga.com/t/how-do-i-call-the-variable-service-state-id-from-a-different-host-and-service/13246/8 "2024-02-09T15:35:46Z")

</div>

Ok, thanks a lot. I’ll have a thorough check on monday…maybe also with your approach.  
I was hoping I could simply transfer that check from Nagios to Icinga2

---

<div class="post-metadata">

**Author:** ![rivad](https://community.icinga.com/user_avatar/community.icinga.com/rivad/32/5852_2.png) [@rivad](https://community.icinga.com/u/rivad)\
**Post date:** [February 9, 2024, 3:53pm UTC](https://community.icinga.com/t/how-do-i-call-the-variable-service-state-id-from-a-different-host-and-service/13246/9 "2024-02-09T15:53:51Z")

</div>

I guess, you could simplify my approach as, I understand, your check does the logic so you would only need to get the `state_id`s of interesst in a comma separated string in the `-s` message argument and swap out the `dummy` check for your `check_cluster`, spruce it up with some nice variables and fields and it would be quite nicely manageable via the director.

---

<div class="post-metadata">

**Author:** ![j\_t](https://community.icinga.com/letter_avatar_proxy/v4/letter/j/57b2e6/32.png) [@j\_t](https://community.icinga.com/u/j_t)\
**Post date:** [February 12, 2024, 9:28am UTC](https://community.icinga.com/t/how-do-i-call-the-variable-service-state-id-from-a-different-host-and-service/13246/10 "2024-02-12T09:28:20Z")

</div>

I found a bit more on the topic of the now useless “check\_cluster” in the forums by coincidence…I have no Idea why it did not pop up in my search for my issues.

> [@Checking service clusters in Icinga 2](https://community.icinga.com/t/checking-service-clusters-in-icinga-2/752):
>
> Author: @mfrosch Last Edit: 2019-03-28 Today we step into the depths of the Icinga 2 DSL and try to find a nice way to combine the state of several services into one. This approach takes a list of hosts with one service on each and check if a minimum is OK before warning or critical. In Icinga 1.x this would be achieved by check\_cluster using macros like $SERVICESTATEID:host:service$. Features Nice Markup with Links and HTML for Icinga 2 Check working internally in Icinga 2 Simple defini…

as I am absolutely not familiar with DSL, I need more time for that. Thanks for your input. It helps me a lot to understand that issue better.