Automatic Problem Resolution logic?

[ottow]

Hi,

We are evaluating Zabbix as a possible replacement for our current monitoring solution, and have a small Zabbix environment set up for testing.
This weekend some of the monitored servers got automatically patched, which resulted in them triggering the "Problem: Linux: Number of installed packages has been changed".
What is not obvious to us is why the Problem was automatically resolved some time later.
Taking one of the systems as an example, the graph for Linux: Number of installed packages shows the package count increased from 782 to 787 and has remained there since, past the time the problem was resolved.
The Problem was triggered at at 03:10:26 on 2024.09.21
The Proplem was automatically resolved at 16:10:06 on 2024.09.21, 12h 59m 40s later.

We are seeing similar behaviour on all monitored Linux systems, though the exact time to resolve is similar but not identical (12h 50-something minutes)

I am looking to understand why this happened. I can't find anything on the trigger that says the Problem should automatically resolve after a certain period, the trigger has not been modified from default.

[nubslee]

Hey ottow,

Zabbix problems become resolved when the trigger expression evaluates to False or, if a recovery expression is set, the recovery expression evaluates to True.

It is difficult to give a specific answer without further insight into the trigger expression (and recovery expression if set). Please share these details if you require more specific analysis.

[cyber]

Default Linux template has this trigger defined as

change(/Linux by Zabbix agent active/system.sw.packages.get)<>0

item itself it updated in 1h interval. So minimal time to resolve it automatically is 1h, if there is no further changes in package count.

BUT... that item has preprocessing.. "discard unchanged with heartbeat" set to 12h.. Which effectively delays that resolution for 12h.. No values are saved during that time, so trigger does not get recalculated. When "heartbeat" comes and package count is saved again, trigger gets recalculated to false, as there is no change any more.