Ignore ping for specific machines

Hi all,

I am attempting to not monitor for ping/icmp for a particular set of machines. All objects in our environment are monitored for ping/icmp, but I have just a handful of objects that don’t respond to icmp requests by the vendor’s software’s design.

The only unique identifier that I can find for these machines in Icinga is a Notes property with the word “VTMN”.

The current code I’ve attempted to use, which unfortunately does not work, is the following:

apply Service for (ping => config in host.vars.ping) {
import "generic-service"

check_command = "ping4"
zone=config.src
vars += config

vars.delay=2m
vars.ping_wrta=550
vars.ping_crta=600
vars.ping_wpl = 20
vars.ping_cpl = 40

assign where host.notes != "VTMN" 
  }

Other than the unique word in the Notes property, how can I specify not to monitor that set of machines? Of course, I could hardcode the names, but I don’t believe that is ideal, since it’s possible in the future we would add more of those machines, so I’d like to be able to make it dynamic.

I’ve also attempted adding them as a Custom Host object, with no ping, which works fine and I can monitor other properties that I want, but then that means I have duplicate objects in Icinga based on my testing since Icinga automatically ingests new Objects in our environment.

Alternatively, would I use an if statement in the code above? So something like:

if (host.notes == "VTMN") {
check_command = "dummy"
vars.dummy_state = 0
vars.dummy_text = UP 
}

So then as an example:

apply Service for (ping => config in host.vars.ping) {

if (host.notes == "VTMN") {
    check_command = "dummy"
    vars.dummy_state = 0
    vars.dummy_text = UP 
    }
else {

import "generic-service"

check_command = "ping4"
zone=config.src
vars += config

vars.delay=2m
vars.ping_wrta=550
vars.ping_crta=600
vars.ping_wpl = 20
vars.ping_cpl = 40
 }
}

Any thoughts or feedback would be greatly appreciated, and if any additional info is needed, please let me know.

Thanks!

  • Icinga Web 2 version - 2.11.4
  • Used modules and their versions (System - About) - Grafana, Icingadb, Monitoring
  • Web browser used - Chrome, Edge, etc
  • Icinga 2 version used (icinga2 --version) - 2.11.4
  • PHP version used (php --version) - 8.1.2-1ubuntu2.13
  • Server operating system and version - Ubuntu Linux

How are these hosts without “VTMN” defined? Can you show a sample config of one of these hosts (munge the specific details besides the VTMN field, please).

I apologize for the delay in responding.

Of course. Here is an example:

object Host “VTMN123” {
import “generic-host”

    address = "192.168.114.52"
    groups = [ "Operators" ]
    notes = "VTMN"
    vars = {
            domain = "NONE"
            origin = "api"
            os = "Linux"
            owner = "Operators"
            region = "VMTNHQ-1"
            site = "VTMNHQ"
            svc = {
                    https = "on"
            }
            type = "vm"
    }
    version = 1703775504.739548
    zone = "VMTNHQ-1"
}

Hi, @RNewton,

The only oddity I noticed is that your example host doesn’t have a variable “host.vars.ping”, so I’m not really understanding how the service you’ve explained would even be work. I generally try to positively assign first, and then add a second stanza to exclude hosts.

Maybe you could try to assign the service only when “host.vars.ping” is defined and then add an exclude for the host.vars.notes field?? Here’s how I handle something similar in my environment, as an example:

assign where match("infra_k8s_app1*", host.vars.hosttype) && host.vars.hostenv != "development"

Thank you for the information. Great question and point. I wasn’t the original creator of the Icinga system, so I’m still learning how it’s configured. We do have a loop that checks ping for custom hosts. However, as for individual host objects, they seem to be using a hostalive check_command, but I am unsure where to find how that is configured.

So I have done something similar to what you’ve suggested in our ping loop check, but since it’s possible that this is for a custom host object check, then I need to determine another area in the code to add a condition to.

Here is the loop check with the condition:

Ultimately, I created a hostgroup and tried to filter that with an ignore where:

object HostGroup "VTMN" {
  display_name = "VTMN"
  assign where host.notes == "VTMN"
}

apply Service for (ping => config in host.vars.ping) {
import "generic-service"

check_command = "ping4"
zone=config.src

vars += config
vars.delay=2m
vars.ping_wrta=550
vars.ping_crta=600
vars.ping_wpl = 20
vars.ping_cpl = 40

assign where ! ("VTMN" in host.groups)
}

But this didn’t work as expected.

However, I tried creating a custom host object that contains the following:
dummy_state = 0
dummy_text = UP

This worked great for the individual custom host object to ignore ping, but I still have the existing objects in Icinga that are being pinged.

That’s a strange looking assign where condition statement.

However, I think - potentially, mind you - the issue is that the host.notes field is supposed to be a markdown-formatted field for displaying help text in the Icinga2 Web interface. I’m not sure how conditions work on that field, honestly.

This is how the notes field is normally stated in my systems, and it renders well in the host object in Icinga Web:

object HOST "myVTMNHost123" {
  ...
  notes = {{{To resolve this..
  - step one
  - step two
  - step three
  - <my link to follow up escalation>}}}
}

If you dump that host’s object using icinga2 object list | grep -A 50 myVTMNHost123, what does the host.notes field look like that has “VTMN” in it? I’m just wondering if it’s internally stored slightly differently due to the markdown intent, and thus your match on host.notes is failing.

Well, I’ve just noticed an interesting observation. The notes field when running that command shows “NTRL VTMN” instead of what I see in Icinga, which is “VTMN”. When I open the host object .conf file, I see “VTMN”, and not “NTRL VTMN”.

Is the discrepancy possibly the issue?

Yeah, that would do it. Try matching against “NTRL VTMN” - see if that fixes your original issue!

Will do, thanks! I’ll give that a shot.

I know I was communicating with you on my other thread, Icinga2 daemon -C --dump-objects - Icinga 2 - Icinga Community.

Would running the icinga2 daemon -C --dump-objects command potentially resolve the discrepancy?

Eh, I don’t think so, but it could. I’ve never, ever seen icinga2 daemon -C cause any issues with a running environment. Not once in my 6 years of running it, but it has about the likelihood of half-logging into the console killing a mainframe (don’t laugh, but this happened at my first corporate job years ago…)