# Monitoring satellite connectivity

**URL:** <https://community.icinga.com/t/monitoring-satellite-connectivity/3518>\
**Category:** Icinga 2\
**Created:** [February 17, 2020, 12:26am UTC](https://community.icinga.com/t/monitoring-satellite-connectivity/3518 "2020-02-17T00:26:21Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![0xliam](https://community.icinga.com/user_avatar/community.icinga.com/0xliam/32/1513_2.png) [@0xliam](https://community.icinga.com/u/0xliam)\
**Post date:** [February 17, 2020, 12:26am UTC](https://community.icinga.com/t/monitoring-satellite-connectivity/3518/1 "2020-02-17T00:26:22Z")

</div>

I am wondering if anyone has a better way to monitor connectivity to satellites - we would like to use this to monitor overall connectivity to a customer’s site.

e.g. if a master (or both masters) loses connectivity to a satellite this could notify us that site is down.

Currently we’re using the ‘cluster’ check on our masters which lists connected/disconnected satellites, but if I could seperate the status of each satellite into seperate services that would be a bit more ideal for our use case.

Our monitoring architecture looks like this:

Master 1, Master 2 \<------- Satellite \<------ Hosts

Satellites talk up to the masters (all connectivity is upstream).

Any thoughts would be much appreciated.

---

<div class="post-metadata">

**Author:** ![rsx](https://community.icinga.com/user_avatar/community.icinga.com/rsx/32/2094_2.png) [@rsx](https://community.icinga.com/u/rsx)\
**Post date:** [February 17, 2020, 6:28am UTC](https://community.icinga.com/t/monitoring-satellite-connectivity/3518/2 "2020-02-17T06:28:06Z")

</div>

Just try [cluster-zone](https://icinga.com/docs/icinga2/latest/doc/10-icinga-template-library/#cluster-zone) instead of (or in addition to) [cluster](https://icinga.com/docs/icinga2/latest/doc/10-icinga-template-library/#cluster).

---

<div class="post-metadata">

**Author:** ![0xliam](https://community.icinga.com/user_avatar/community.icinga.com/0xliam/32/1513_2.png) [@0xliam](https://community.icinga.com/u/0xliam)\
**Post date:** [February 17, 2020, 11:18am UTC](https://community.icinga.com/t/monitoring-satellite-connectivity/3518/3 "2020-02-17T11:18:17Z")

</div>

Ah, I must have missed that when reading the documentation.

Will test this tomorrow morning and report my findings.

---

<div class="post-metadata">

**Author:** ![0xliam](https://community.icinga.com/user_avatar/community.icinga.com/0xliam/32/1513_2.png) [@0xliam](https://community.icinga.com/u/0xliam)\
**Post date:** [February 28, 2020, 5:37am UTC](https://community.icinga.com/t/monitoring-satellite-connectivity/3518/4 "2020-02-28T05:37:21Z")

</div>

Sorry, was only able to test this now! This seems to do the job! 🙂

I am wondering if anyone would be able to shed some light on how this might be achievable in an automated fashion.

We want this check to apply to every zone on both of our masters - this way we’re monitoring connectivity from both DCs to all of our customers.

This is our current config:

```
apply Service "Connectivity Test" {
    import "Client Connectivity"
    assign where "Icinga Master" in host.templates
    import DirectorOverrideTemplate
}

template Service "Client Connectivity" {
    check_command = "cluster-zone"
    vars.cluster_zone = "satellite.example.com.au"
}

```

We’re using Director, and it’s easy enough to add this check individually for each zone (modifying vars.cluster\_zone as we go).

However I am wondering if something like the below is possible?

Essentially, we need to get a list of child zones of the master, and apply this check for each zone:

```
apply Service "connectivity" for (zone in childZones) {
    import DirectorOverrideTemplate
    display_name = zone + "connectivity"
    check_command = "cluster-zone"
    vars.cluster_zone = zone
    assign where "Icinga Master" in host.templates

```

}

I am not sure if it’s possible to achieve this in Director, but I’m not sure how we’d even achieve it with the DSL.

Is it possible to retrieve a list of child zones? Or am I going about this in a stupid way?

---

<div class="post-metadata">

**Author:** ![rsx](https://community.icinga.com/user_avatar/community.icinga.com/rsx/32/2094_2.png) [@rsx](https://community.icinga.com/u/rsx)\
**Post date:** [February 28, 2020, 6:34am UTC](https://community.icinga.com/t/monitoring-satellite-connectivity/3518/5 "2020-02-28T06:34:22Z")

</div>

You could try something like this:

```auto
apply Service "zone" {
   display_name = "Zone"
   check_command = "cluster-zone"

   assign where get_object("Endpoint", host.name)
   ignore where host.name == NodeName
}

```

---

<div class="post-metadata">

**Author:** ![0xliam](https://community.icinga.com/user_avatar/community.icinga.com/0xliam/32/1513_2.png) [@0xliam](https://community.icinga.com/u/0xliam)\
**Post date:** [March 2, 2020, 10:52am UTC](https://community.icinga.com/t/monitoring-satellite-connectivity/3518/6 "2020-03-02T10:52:25Z")

</div>

As an update, we discussed this internally and ended up defining a Host template in Director with cluster-zone as the host check.

We opted to create these via the API, and the host that is created gets the hostname of the customer’s zone, and a friendly name of the actual customer name.

These hosts sit in our cluster zone.

We then are planning on parenting these to the actual satellite zone, so if the master sees the ‘client check’ go into critical (disconnected), the satellite zone is marked as unreachable.

It’s a bit of a strange setup, but I think it works for our needs.

---

<div class="post-metadata">

**Author:** ![unic](https://community.icinga.com/user_avatar/community.icinga.com/unic/32/200_2.png) [@unic](https://community.icinga.com/u/unic)\
**Post date:** [March 2, 2020, 1:52pm UTC](https://community.icinga.com/t/monitoring-satellite-connectivity/3518/7 "2020-03-02T13:52:45Z")

</div>

We also use the cluster-zone check as the “hostalive” check as a replacement for every host that has an agent or is a satellite. If we need the ping check, we add it separately.