Search code examples
monitoringzabbix

Mark a hostname problem as resolved in Zabbix


I am fairly new to using Zabbix, and I have added a few hosts to it while doing my initial tests with the platform.

When doing this configuration, I have misconfigured a few things, such as leaving the hostname incorrect in one of the agents. When I finally fixed the agent hostname in the agent configuration file, it started appearing as a problem in Zabbix dashboard.

It states that "Host name of zabbix_agentd was changed on [my.monitored.host.tld]". This is a false positive, it was not a problem but in fact a correction.

I want to leave this trigger on, but I would like to be able to mark this as resolved as it was a configuration change, and not a problem due to files being changed inadvertently.

How can I do this? Is the only way to do this having to change the trigger to allow manual closing? And if so, where do I access that? I tried going to the host, clicking on the triggers that are on that host, then select the "host name" trigger, but I see the manual close checkbox disabled.


Solution

  • Some trigger or item fields can only be modified in their relevant templates.

    You won't be able to enable 'Allow Manual Close' in your host's triggers if they are attached to templates on the host. There are two options to get around this:

    1: Move to the top-level template and modify that.

    Whenever you select a trigger that's attached to a template, the top of the trigger configuration page will have a 'Parent Triggers' link or links. (If there are multiple separated by '=>' arrows, it means there's many layers of inheritance, and to edit any you'll have to go right to the top one).

    Once you're at the top, all the fields should be editable, including things like Manual Close and the trigger expression itself.

    Note: This option will modify all the hosts attached to this template. Think carefully about which changes should be made on one host vs. the entire subset.

    2: New, host-specific triggers

    If you don't like the idea of modifying all the hosts that use this template - for example, you may not want any technicians to be able to manually resolve hostname change alerts for all hosts, but rather just the one - you can clone the original trigger within the host, then disable it.

    To explain, since you can't modify the template-based triggers, it's possible to open the trigger configuration, hit 'Clone' (making sure you're still in the host's context, rather than the template's context) and make the changes you want in the newly created trigger. In this way, you can enable manual close, confirm the new trigger, and only the selected host will be affected.

    If you are going to use this workaround, you should make sure not to forget to disable the original one! An easy way to identify which is which from the Triggers list on the host is to check for the Template name next to the Trigger name - template-based triggers will always have a link to their template on the triggers list, while host-specific triggers have none.

    Unfortunately you can't delete the template trigger without removing the entire template. If you find you need to modify a number of hosts like this, you might want to consider creating a new template for these hosts, with the relevant modifications; having too many single host-specific conditions can make changing their conditions quite time consuming in the long run. As always, consider your environment and what makes most sense for your organisation.

    As an aside, manual close is (probably) the best option for cases like this. In an alerting system, particularly one like Zabbix, we can tend to prefer a few false positives, so leaving the trigger on is (for most cases) the right idea. In Zabbix, you could ignore the trigger until it resolves (config change triggers like this one tend to be resolved at the next check, by default), but if you're relying on the Zabbix web interface itself to provide information, these ignored/acknowledged triggers can make spotting the actual problems harder. Without disabling them entirely, manual close makes sure you can resolve them immediately whenever necessary and still have them around otherwise.