Infrastructure Monitoring with Zabbix
A monitoring case study built around one question: can an operator detect, understand, and verify a fault before users report it? The workflow combines host inventory, reusable templates, service checks, trigger logic, dashboards, and recovery testing.
MONITORING ARCHITECTURE
A small lab can use one Zabbix server, a database, the web frontend, and several monitored Linux/network hosts. Host groups provide structure; templates keep item and trigger definitions reusable.
AGENT & HOST CONFIGURATION
Linux hosts can expose system metrics through the Zabbix agent while network equipment may use SNMP. The configuration emphasizes stable hostnames, predictable interfaces, and explicit metadata such as environment and role.
TRIGGER ENGINEERING
Good triggers describe an operational condition, not just a number. CPU saturation, disk pressure, service failure, and unreachable-host events should have thresholds that reflect a baseline and an action path.
$ zabbix_agentd -t 'system.cpu.util[,user]' system.cpu.util[,user] [t|0.42] $ systemctl status zabbix-agent --no-pager Active: active (running) $ ss -lntp | grep 10050 LISTEN ... :10050 ... zabbix_agentd
$ sudo systemctl stop demo-web.service $ systemctl is-active demo-web.service inactive # Zabbix UI: trigger changes to PROBLEM $ sudo systemctl start demo-web.service active # Zabbix UI: trigger returns to OK
CONTROLLED FAILURE TEST
A safe lab test is to stop a non-critical test service, observe the item/trigger transition, confirm the alert, restore the service, and verify recovery. This validates both detection and recovery rather than only dashboard cosmetics.
LESSONS LEARNED
Monitoring becomes useful when it reduces uncertainty. The best dashboard answers what is broken, where it is broken, how long it has been broken, and whether the condition is improving.