Zabbix

Zabbix’s default templates cover the basics pretty well, but accepting only the defaults, puts you in the spectator seat: green or red, up or down, basic alerting. The moment you want to know in-depth why a server feels off, not just that something’s wrong, you’re on your own. As in yo can tweak and get more from Zabbix, but some efforts is required.

Hold your seat, I’ll explain myself.

This post covers the metrics I found myself missing, the problems that i faced once I started paying closer attention, and how I closed those gaps with a set of custom user parameters checks.

A fully redundant Zabbix monitoring stack, deployed entirely through code rather than manual configuration:

• Multi-node Zabbix server cluster — native Zabbix HA nodes for server-level failover
• Distributed Zabbix proxies — spread across network segments or regions for resilient, scalable data collection
• Clustered database backend — the catalog/history database itself deployed as a cluster, not a single point of failure
• Infrastructure as Code — the entire stack reproducible from a single set of Terraform/Ansible definitions

The goal is portability: the same IaC definitions should stand up the cluster identically whether the target is on-premise Proxmox VE, or a public cloud — AWS, Azure, or GCP. Same architecture, same automation, different provider underneath.

Windows Firewall disabled on multiple hosts. Our monitoring never noticed the change

A few months back while working with Zabbix for our mixed environment, I realized that the default Windows template doesn’t monitor whether Windows Firewall is actually enabled across its three zones (Domain, Private, and Public). There also wasn’t a straightforward way to see who was or still is logged into each Windows machine. For something as critical as firewall status, this felt like an important gap, so I came up with a two-fold solution: