Zabbix – monitoring infrastruktury, serwerów i sieci
Zabbix to kompleksowa platforma do monitorowania infrastruktury IT. W odróżnieniu od Loki, Grayloga czy Wazuha jego głównym zadaniem nie jest analiza logów, ale monitorowanie dostępności, wydajności i stanu urządzeń oraz usług.
Najprościej:
Zabbix → "Czy infrastruktura działa i jak się ma?"
Prometheus → "Jakie metryki generuje system?"
Loki → "Co mówią logi?"
Wazuh → "Czy dzieje się coś podejrzanego?"
Architektura Zabbixa
Typowa instalacja:
Zabbix Web UI
|
v
Zabbix Server
|
+------------+------------+
| | |
Agent SNMP IPMI
| | |
Linux Switches Servers
Windows Routers
Zabbix Server zbiera dane, wykonuje monitoring i generuje alerty.
Zabbix Agent
Na serwerze można zainstalować Zabbix Agent.
Przykład:
Linux Server
|
Zabbix Agent
|
+--> CPU
+--> RAM
+--> Disk
+--> Network
+--> Processes
+--> Services
|
v
Zabbix Server
Agent pozwala monitorować parametry, których nie da się wygodnie uzyskać wyłącznie przez sieć.
Co Zabbix monitoruje?
Bardzo dużo:
CPU
RAM
Disk
Network
Processes
Services
Applications
Databases
Websites
Virtual Machines
Containers
Network Devices
Możemy monitorować zarówno pojedynczy serwer, jak i ogromną infrastrukturę.
Monitoring CPU
Przykład:
CPU usage
20% ───────────
30% ───────────
40% ───────────
95% ─────────── ⚠
98% ─────────── 🔴
Możemy ustawić trigger:
CPU > 90% przez 5 minut
|
v
ALERT
Monitoring RAM
Analogicznie:
RAM usage
|
+--> 50% OK
+--> 70% OK
+--> 85% WARNING
+--> 95% CRITICAL
Zabbix może automatycznie wygenerować alert.
Monitoring dysku
Jeden z najważniejszych przypadków:
Disk /var
70% → OK
80% → WARNING
90% → HIGH
95% → CRITICAL
Możemy ustawić:
IF disk usage > 90%
THEN alert
To pozwala wykryć problem zanim serwer przestanie działać.
Monitoring usług
Zabbix może sprawdzać, czy określona usługa działa.
Na przykład:
nginx
|
+--> running → OK
|
+--> stopped → ALERT
Podobnie:
mysql
postgresql
docker
sshd
apache
Monitoring portów
Możemy sprawdzać dostępność:
80 → HTTP
443 → HTTPS
22 → SSH
53 → DNS
3306 → MySQL
5432 → PostgreSQL
Przykład:
443
|
+--> OPEN → OK
|
+--> CLOSED → ALERT
Monitoring stron internetowych
Zabbix może monitorować również aplikacje webowe.
Przykład:
User
|
v
HTTPS
|
v
Website
|
+--> HTTP 200 → OK
+--> HTTP 500 → ALERT
Możemy sprawdzać:
- kod HTTP,
- czas odpowiedzi,
- dostępność,
- zawartość strony,
- scenariusze webowe.
Monitoring SSL/TLS
Możemy również monitorować certyfikaty.
Przykład:
Certificate expires in:
60 days → OK
30 days → WARNING
7 days → HIGH
1 day → CRITICAL
To jeden z bardzo praktycznych monitoringów.
Zabbix i SNMP
Zabbix jest szczególnie mocny w monitorowaniu urządzeń sieciowych.
Zabbix
|
SNMP
|
+-----------+-----------+
| | |
Router Switch Firewall
Możemy monitorować:
Interface traffic
CPU
RAM
Temperature
Packets
Errors
Uptime
Monitoring switcha
Przykładowo:
Switch
|
+-- Gi0/1 → 2 Gbps
+-- Gi0/2 → 800 Mbps
+-- Gi0/3 → 0 Mbps
+-- Gi0/4 → 10 Gbps
Zabbix może wykryć:
Interface errors ↑
i wygenerować alert.
Zabbix + pfSense / OPNsense
W naszej wcześniejszej architekturze Zabbix świetnie pasuje do monitorowania firewalla.
Internet
|
pfSense / OPNsense
|
+--> CPU
+--> RAM
+--> WAN
+--> LAN
+--> VPN
+--> Interfaces
|
v
Zabbix
Wtedy mamy:
Firewall Security → Suricata
Firewall Logs → Graylog/Loki
Firewall Metrics → Zabbix
Zabbix + Linux
Na Linuxie Zabbix może monitorować praktycznie cały host:
Linux
|
+--> CPU
+--> RAM
+--> Swap
+--> Disk
+--> I/O
+--> Network
+--> Processes
+--> Services
+--> Filesystems
Dzięki agentowi otrzymujemy znacznie więcej informacji niż zwykłym pingiem.
Zabbix + Windows
Możemy monitorować:
Windows
|
+--> CPU
+--> RAM
+--> Disk
+--> Services
+--> Processes
+--> Network
+--> Event-related metrics
Przykład:
Windows Server
|
+--> SQL Server
+--> IIS
+--> Active Directory
+--> DNS
Każda z tych usług może być monitorowana.
Zabbix + Docker
Zabbix może również monitorować środowiska kontenerowe.
Docker Host
|
+---+---+---+
| | | |
Web API DB Redis
| | | |
+---+---+---+
|
Metrics
|
v
Zabbix
Możemy monitorować zarówno hosta, jak i poszczególne elementy środowiska.
Zabbix + Kubernetes
W Kubernetes monitoring jest jeszcze bardziej interesujący.
Kubernetes
|
+---------------+---------------+
| | |
Node Node Node
| | |
Pods Pods Pods
+---------------+---------------+
|
Zabbix
Możemy monitorować:
Nodes
Pods
Deployments
CPU
Memory
Network
Cluster state
Zabbix i Kubernetes vs Prometheus
Tutaj pojawia się ciekawa konkurencja.
Prometheus jest naturalnym wyborem dla cloud-native/Kubernetes.
Kubernetes
|
Prometheus
|
Grafana
Zabbix również może monitorować Kubernetes:
Kubernetes
|
Zabbix
|
Zabbix Dashboard
Jeżeli środowisko jest mocno oparte o Kubernetes, Prometheus zwykle będzie bardziej naturalnym elementem observability.
Jeżeli mamy natomiast:
Linux
Windows
Switches
Routers
Firewalls
VMs
Applications
Zabbix staje się bardzo atrakcyjny jako jeden system monitoringu całej infrastruktury.
Zabbix vs Prometheus
| Cecha | Zabbix | Prometheus |
|---|---|---|
| Linux | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Windows | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| SNMP | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Network devices | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Kubernetes | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Cloud-native | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Alerting | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Agent | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| Out-of-box monitoring | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| Ecosystem | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
Najprościej:
Zabbix
→ klasyczny monitoring całej infrastruktury
Prometheus
→ metrics/observability, szczególnie cloud-native
Zabbix + Grafana
Nie musimy wybierać między Zabbixem a Grafaną.
Możemy wykorzystać:
Zabbix
|
v
Metrics
|
v
Grafana
Czyli:
Grafana
|
+-----+-----+
| |
Prometheus Zabbix
| |
Metrics Metrics
Grafana może wtedy być wspólną warstwą wizualizacyjną.
Zabbix i alerting
Jedną z największych zalet Zabbixa jest system triggerów.
Przykład:
CPU > 90%
|
v
Trigger
|
v
Problem
|
v
Notification
Możemy wysyłać powiadomienia np. przez:
Email
SMS
Webhook
Messaging systems
Severity
Zabbix pozwala klasyfikować problemy według poziomu ważności.
Przykładowo:
Information
Warning
Average
High
Disaster
Dzięki temu administrator może odróżnić:
"Filesystem 80%"
od:
"Database server is down"
Zabbix Templates
Jednym z bardzo praktycznych elementów są templates.
Zamiast ręcznie tworzyć dziesiątki metryk dla każdego serwera, możemy zastosować gotowy template.
Template Linux
|
+--> CPU
+--> RAM
+--> Disk
+--> Network
+--> Processes
Następnie:
Template Linux
|
+--> Server01
+--> Server02
+--> Server03
+--> Server04
To ogromnie upraszcza administrację.

Low-Level Discovery
Zabbix może automatycznie wykrywać elementy infrastruktury.
Przykładowo:
Server
|
+--> eth0
+--> eth1
+--> eth2
+--> eth3
Zabbix może automatycznie utworzyć monitoring dla wykrytych interfejsów.
Podobnie:
Filesystems
Network interfaces
Disks
Services
Zabbix i SLA
Monitoring może również służyć do mierzenia dostępności usług.
Przykład:
Website availability
|
v
99.95%
Możemy następnie analizować:
Availability
Downtime
Response time
Incidents
Zabbix i capacity planning
Zbieranie danych przez wiele miesięcy pozwala przewidywać problemy.
Przykład:
Disk usage
2026-01 → 40%
2026-03 → 50%
2026-05 → 62%
2026-08 → 75%
Możemy przewidzieć:
Disk full
|
v
~October
i rozbudować storage wcześniej.
Zabbix vs Graylog
To zupełnie inne narzędzia:
Zabbix
→ "Serwer ma 92% CPU"
Graylog
→ "Serwer wygenerował 15 000 logów ERROR"
Czyli:
| Zabbix | Graylog | |
|---|---|---|
| Metrics | ⭐⭐⭐⭐⭐ | ⭐⭐ |
| Logs | ⭐⭐ | ⭐⭐⭐⭐⭐ |
| Availability | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| Infrastructure monitoring | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| Log search | ⭐ | ⭐⭐⭐⭐⭐ |
| Alerting | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
Zabbix vs Loki
Zabbix
↓
Metrics + Availability
Loki
↓
Logs
Przykład:
Zabbix:
CPU = 98%
Loki:
ERROR database connection timeout
Połączenie obu daje znacznie lepszy obraz sytuacji.
Zabbix + Loki + Grafana
Możemy stworzyć:
Grafana
/ \
/ \
Zabbix Loki
| |
Metrics Logs
Przykład awarii:
Zabbix
CPU 99%
|
v
Grafana
|
v
Loki
|
v
"Out of memory"
Zabbix + Wazuh
To również bardzo dobre uzupełnienie:
Server
|
+---------+---------+
| |
Zabbix Wazuh
| |
Health Security
| |
CPU/RAM Alerts
Disk FIM
Network Vulnerabilities
Czyli:
Zabbix → Czy serwer działa prawidłowo?
Wazuh → Czy serwer jest bezpieczny?
Zabbix + ELK
Możemy połączyć:
Zabbix → Metrics
Elastic → Logs / Analytics
Kibana → Log visualization
Przykład:
Server
|
+--------+--------+
| |
Zabbix Elastic
| |
Metrics Logs
Pełna architektura
W naszej dotychczasowej układance Zabbix może wyglądać tak:
INTERNET
|
Firewall
|
+-------------+-------------+
| |
Suricata Zeek
| |
+-------------+-------------+
|
NETWORK
|
+--------------------------+--------------------------+
| | |
Linux Windows Kubernetes
| | |
Zabbix Zabbix Zabbix
| | |
+--------------------------+--------------------------+
|
INFRASTRUCTURE
MONITORING
SECURITY MONITORING
|
Wazuh
|
Security Events
LOG MANAGEMENT
|
+-------------------+-------------------+
| | |
Loki Graylog Elastic
| | |
+-------------------+-------------------+
|
Logs
OBSERVABILITY
|
Prometheus
|
Grafana
Oczywiście nie oznacza to, że trzeba instalować wszystkie te systemy. W praktyce najważniejsza jest właściwa specjalizacja.
Przykładowy zestaw dla małej firmy
Jeżeli mamy np.:
3 Linux servers
2 Windows servers
1 firewall
1 switch
kilka aplikacji
sensowny zestaw może wyglądać tak:
Zabbix
|
Infrastructure Monitoring
Wazuh
|
Security Monitoring
Loki
|
Application Logs
Grafana
|
Visualization
Dla większej infrastruktury
Przy większym środowisku:
Monitoring
|
+-----------+-----------+
| |
Zabbix Prometheus
| |
Infrastructure Cloud/K8s
| |
+-----------+-----------+
|
Grafana
Security
|
+-------------+-------------+
| |
Wazuh Suricata/Zeek
| |
+-------------+-------------+
|
SIEM/Logs
|
Elastic/Graylog
Najważniejsze rozróżnienie
Całą naszą serię można już bardzo dobrze uporządkować:
Zabbix → MONITORING INFRASTRUKTURY
Prometheus → METRICS / OBSERVABILITY
Loki → LOGS
Graylog → LOG MANAGEMENT
Elastic → SEARCH / ANALYTICS / SIEM
Grafana → VISUALIZATION
Wazuh → SECURITY MONITORING
Suricata → IDS/IPS
Zeek → NETWORK VISIBILITY
Zabbix jest więc przede wszystkim „strażnikiem stanu infrastruktury”. Jeżeli serwer, switch, firewall, baza danych albo usługa zaczyna działać nieprawidłowo, Zabbix ma to wykryć zanim użytkownik zacznie się zastanawiać, dlaczego coś nie działa.






