Zabbix triggers and problem expressions

All steps use the frontend at https://zbx01.lab and commands on web01. Open Data collection > Hosts, click Triggers next to web01, and use Create trigger for each one. If you skipped Lesson 7, create the item “Nginx: number of processes” (proc.num[nginx], Zabbix agent (active), 1m) first.

1A simple trigger: Nginx down

Use the Add button next to the Expression box (the expression constructor) to pick the host, item and function, or type it directly. Click Add to save.

Then on web01:

sudo systemctl stop nginx
sleep 90
sudo systemctl start nginx

Within about a minute of stopping Nginx, Monitoring > Problems shows a red High problem:

Monitoring > Problems a minute after Nginx stopped

When you start Nginx again, the next value is 2 or 3, the expression becomes false, and the problem moves to RESOLVED in green.

✅ Checkpoint: Stopping Nginx raised “Nginx is down on web01” (High) and starting it resolved the problem.

2Use a time window: high CPU over 5 minutes

Before saving, open web01’s Macros tab and add {$CPU.HIGH} = 70. Then generate some load on web01 for six minutes:

Run this on web01:

sudo apt install -y stress-ng
stress-ng --cpu 1 --cpu-load 95 --timeout 6m &

About five minutes later Problems shows:

Average  web01  High CPU on web01 (5m average above 70)    Now: 94.8 %

The 5-minute average needs a few minutes of high values before it crosses 70, which is the point: short spikes don’t wake anyone up. The operational data keeps updating while the event name stays as it was.

✅ Checkpoint: A High CPU problem appeared after a few minutes of load and resolved after stress-ng stopped.

3Detect silence with nodata

nodata is checked on a timer by the server (every 30 seconds), not when values arrive, because the whole point is that nothing is arriving. It’s the right tool for active agents and trapper items, where the server can’t poll to find out the host is gone.

✅ Checkpoint: The nodata trigger is saved and shows status OK while the agent is sending data.

4Add a dependency

Edit “Nginx is down on {HOST.NAME}”, open the Dependencies tab, click Add and select “No data from agent on web01 for 3 minutes”. Click Update. Now, if the whole agent goes silent, you get one “No data” problem instead of that plus a possibly stale “Nginx is down”.

Test it on web01:

sudo systemctl stop zabbix-agent2 nginx
sleep 300
sudo systemctl start zabbix-agent2 nginx

After about 3 minutes only the “No data” problem appears. Dependencies hide the dependent problem while the parent is in PROBLEM state; they don’t delete it.

✅ Checkpoint: With the agent stopped, Problems shows “No data from agent” and not “Nginx is down”.

5Acknowledge, comment and close a problem

Stop Nginx again to raise the “Nginx is down” problem. In Monitoring > Problems click Update in the problem’s row to open the problem update dialog. Type a message (“Checking, Nginx stopped for lab test”), tick Acknowledge and click Update.

Acknowledging tells the team someone is on it and, with escalations (Lesson 16), stops further notifications. Open the dialog again, tick Close problem and click Update. Because “Allow manual close” is ticked, the problem closes even though Nginx is still stopped; it opens again on the next value of 0, which is why manual close suits problems that can’t recover by themselves (like a log line), not this one.

Start Nginx again.

✅ Checkpoint: You acknowledged a problem with a message and closed it manually.

6Use a macro with context

The Linux template already has {$VFS.FS.PUSED.MAX.WARN} (80) and {$VFS.FS.PUSED.MAX.CRIT} (90) for file systems. On web01’s Macros tab, click Inherited and host macros to see them, then add {$VFS.FS.PUSED.MAX.WARN:"/"} = 40 and click Update.

Root is about 48% full on web01, and the template trigger uses min(...,5m), so within about five minutes Problems shows a Warning for root only, with the threshold from your macro in the event name and the live value in operational data.

Warning  web01  Linux: FS [/]: Space is low (used > 40%, total 14.6GB)    Space used: 48.5%

Remove the macro (or set it back to 80) and the problem resolves. This is how you raise or lower one threshold for one file system on one host without touching the template.

✅ Checkpoint: A context macro for “/” changed the warning threshold for the root file system only.