Ad Widget

Collapse

Trigger dependencies to another hosts trigger

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • nahueld
    Junior Member
    • Nov 2021
    • 13

    #1

    Trigger dependencies to another hosts trigger

    Hello, I need some help with an issue i'm having.

    I'm monitoring with zabbix 5.0 several locations that look like this:
    Click image for larger version  Name:	image.png Views:	0 Size:	32.6 KB ID:	453796
    ​​
    The problem i'm having right now is that when the "location" loses internet access there are plenty alarms, one for each host in that location.
    I want to know if theres a way to make the "unavailable by ICMP PING" trigger of each PC depend on the routers "Unavailable by ICMP Ping".



    Every host is in a hostgroup that identifies the location where it is located, and another to identify the device. So there are some coincidences of hostgroups in terms of devices.
    For example, a router located in location 1
    is identified with hostgroups:
    -router
    -location1
    -/routerbrand/

    and another router in location 2 has
    -router
    -location2
    -/routerbrand/


    So i was thinking doing this with a script, that searches in each location all the hosts and update the dependency of the "unavailable by icmp ping" to depend on the routers icmp alarm.
    But i'm still thinking what could go wrong before executing it.
    Because if theres a new location added i want to be easier to add it with the same configuration, and if it is possible to make it easier to make other people capable of do this.

    I want to know if the way im approaching the problem makes sense, and if there's a simpler way i'm open to suggestions.



    Thanks
    Nahuel
  • tim.mooney
    Senior Member
    • Dec 2012
    • 1427

    #2
    Originally posted by nahueld
    I want to know if theres a way to make the "unavailable by ICMP PING" trigger of each PC depend on the routers "Unavailable by ICMP Ping".
    Yes, it is.

    We do this for the exact same reason: to cut down on spurious triggers alerting when the real problem is the connection between two datacenters.

    When I originally implemented this, it was very early in the Zabbix 2.0 series. The way I chose to do it based on the capabilities of Zabbix at that time was by having separate datacenter-specific templates (actually, a pair of linked templates per datacenter). Because my workgroup was responsible for both Linux and Windows servers in 3 different datacenters, I created a "Datacenter A Linux base system" template, "Datacenter A Windows base system" template, "Datacenter B Linux base system", etc. template. These "base system" templates included just the very basic items and triggers that we wanted on every Windows or Linux system. We could add additional templates for service-specific stuff, etc., but the "base system" templates just contain the basics we want for every system.

    All of triggers in each of the "Datacenter <whatever> <host OS whatever> base system" templates depend upon the trigger for the Zabbix agent.ping. That item and trigger are not in the base system templates, they are in a separate template that just contains that item and trigger. I did that to avoid duplication of the lower-level template, so that I could link the same template to both the Linux and Windows hosts for a particular datacenter. I need separate "base system" templates for Linux vs. Windows because of the items monitored there, but I can share the "Datacenter X Host Unreachable" template with the agent.ping item and trigger for both Windows and Linux.

    It's in the "Datacenter X Host Unreachable" template where I set the dependency for network topology. The differences between the 3 "Datacenter X Host Unreachable" templates is just in what the agent.ping trigger depends upon. The one for Datacenter A depends upon the appropriate network core device trigger, the one for Datacenter B depends upon a different network core trigger, etc.

    The thing that makes this easy for my coworkers (and could also be easy for autodiscovery) is that all they have to know about a system is what datacenter it's in and what type of host (Linux or Windows) it is, and then they just pick the correct "base system" template from the list and apply it. That gets the system the very basic monitors, and by virtue of the linked template, it gets them an agent.ping trigger that all the base system triggers can depend upon and that agent.ping trigger is itself specific to whatever network gear it depends upon.

    As I said at the start, I designed this around what was available in Zabbix 2.0. There are additional things in the software now (especially tags) that might make sense to be part of this if I were going to redesign. However, it mostly works well for our needs, and all of my coworkers are comfortable with it and know how the existing system works, so there's little interest in updating it.

    However you decide to handle network topology dependencies, I highly recommend you do this: gather the item(s) for the network dependencies more frequently than you gather the items for the hosts that depend upon that network link. That will reduce the chance of a host appearing down when actually it's that the network link went down in the time since it was last checked.
    Last edited by tim.mooney; 02-11-2022, 22:36.

    Comment

    • nahueld
      Junior Member
      • Nov 2021
      • 13

      #3
      Ok, thank you
      I'll see if i can apply this to my infraestructure, this help me a lot thanks.

      When i solve how to do it i'll try to remember to post it here.

      Comment

      Working...