Zabbix to otwartoźródłowy (open source) system do monitorowania infrastruktury IT: serwerów, sieci, baz danych, aplikacji, urządzeń sieciowych, a nawet temperatury w serwerowni, jeśli masz odpowiedni czujnik. Jego zadanie jest proste do opisania, a trudne do zbudowania samemu: ma w jednym miejscu zbierać metryki, pokazywać je na czytelnych wykresach i krzyczeć (mailem, Slackiem, SMS-em), zanim klient zauważy, że coś padło. Projekt założył Alexei Vladishev, a od lat rozwija go firma Zabbix LLC. Aktualna wersja z długim wsparciem to Zabbix 7.0 LTS, a na drugą połowę 2026 zapowiedziano 8.0 LTS z integracją OpenTelemetry.
Jak to działa
W centrum siedzi Zabbix server (napisany w C), który zbiera dane i podejmuje decyzje, oraz frontend w PHP, czyli panel webowy, gdzie klikasz wykresy i dashboardy. Dane lądują w bazie SQL (MySQL/MariaDB, PostgreSQL, często z TimescaleDB dla wydajności). Metryki możesz zbierać na kilka sposobów: przez Zabbix agent instalowany na monitorowanej maszynie, przez SNMP (typowo switche i routery), przez IPMI, JMX albo zwykłe checki HTTP/ICMP bez żadnego agenta.
Sercem logiki są itemy (pojedyncze metryki, np. obciążenie CPU), triggery (warunki typu „użycie dysku > 90%”) i akcje (co zrobić, gdy trigger się odpali). Żeby nie konfigurować każdego serwera ręcznie, używasz szablonów i autodiscovery — dodajesz hosta, przypinasz template „Linux by Zabbix agent” i masz od ręki kilkadziesiąt sensownych metryk.
Przykład z praktyki
Masz 20 serwerów Ubuntu i chcesz wiedzieć, gdy zabraknie miejsca na dysku. Na każdym instalujesz agenta (apt install zabbix-agent2), w pliku konfiguracyjnym ustawiasz Server=10.0.0.5 wskazujący na Zabbix server, restartujesz usługę. W panelu dodajesz hosty, przypinasz oficjalny template dla Linuksa — i autodiscovery samo wykrywa wszystkie partycje. Definiujesz akcję: gdy trigger „dysk > 85%” zmieni stan na Problem, leci powiadomienie na kanał w Slacku. Skończyłeś robić to ręcznie raz, działa dla wszystkich 20 maszyn.
Na co uważać
Najczęstszy mit: „postawię Zabbix i będzie sam działał”. Nie będzie — out of the box dostajesz zbieranie danych, ale sensowne triggery i progi musisz przemyśleć, inaczej utopisz się w fałszywych alarmach albo przegapisz prawdziwą awarię. Druga pułapka to baza danych: przy setkach hostów i krótkich interwałach historia rośnie szybko, więc bez TimescaleDB i rozsądnego housekeepingu baza spuchnie. I nie myl Zabbixa z Grafaną — Zabbix zbiera dane i alarmuje, Grafana głównie je ładnie rysuje (często z Zabbixa jako źródła).
Pojęcia powiązane
Prometheus, Grafana, Nagios, SNMP, OpenTelemetry, monitoring infrastruktury, alerting, observability.