Scenariusz 1: Zabbix na LAN — wszystko w jednej sieci

To najprostszy i najczęstszy model. Serwer Zabbix stoi w tej samej sieci co monitorowane hosty. Agenty na serwerach raportują bezpośrednio do serwera Zabbix, który zbiera dane, przetwarza triggery, wysyła alerty i wyświetla dashboardy.

Jak to wygląda w praktyce

[Host 1] ──┐
[Host 2] ──┤── LAN ──── [Zabbix Server + Frontend + DB]
[Host 3] ──┘

Serwer Zabbix odpytuje agentów (passive checks) lub agenty same wysyłają dane (active checks). Wszystko dzieje się w jednym segmencie sieci. Nie ma firewalli po drodze, nie ma NAT-u, nie ma opóźnień WAN.

Konfiguracja

Minimalna. Instalujesz serwer Zabbix, stawiasz bazę (PostgreSQL lub MySQL), wdrażasz agentów na hostach. W zabbix_agentd.conf ustawiasz:

ini

Server=192.168.1.10          # IP serwera Zabbix (passive checks)
ServerActive=192.168.1.10    # IP serwera Zabbix (active checks)
Hostname=web-server-01       # unikalna nazwa hosta

I gotowe. Agent raportuje, serwer zbiera. Żadnego proxy, żadnych tuneli, żadnych komplikacji.

Zalety

• Prostota — jeden serwer, jedna baza, jedna instancja do zarządzania.
• Niskie opóźnienia — dane z agentów trafiają do serwera natychmiast, bo wszystko jest na LAN-ie.
• Passive i active checks bez ograniczeń — serwer ma bezpośredni dostęp do agentów, więc działają oba tryby. Możesz korzystać z remote commands do automatycznego restartowania usług.
• SNMP, IPMI, HTTP bez problemów — serwer odpytuje urządzenia sieciowe bezpośrednio, bez pośredników.
• Łatwy troubleshooting — jedna maszyna, jeden log, jedno miejsce do sprawdzenia.

Wady

• Skala ograniczona do jednej lokalizacji — jeśli masz drugi oddział albo sieć klienta, ten model nie wystarczy.
• Brak redundancji — padnie serwer Zabbix, padnie monitoring. W małych środowiskach to akceptowalne, w większych — nie.
• Brak separacji — serwer Zabbix widzi wszystko i ma dostęp do wszystkiego. W kontekście bezpieczeństwa i segmentacji sieci to niekoniecznie pożądane.

Kiedy stosować

Jedna firma, jedna serwerownia, jeden LAN. Monitorujesz swoje serwery, switche, NAS-y, UPS-y. Masz pełną kontrolę nad siecią. Nie musisz monitorować niczego zdalnie. To scenariusz dla 80% małych i średnich wdrożeń.

Scenariusz 2: Zabbix z active proxy u klienta

Tu zaczyna się ciekawiej. Masz centralny serwer Zabbix — np. w swoim DC albo na VPS-ie. Klient ma swoją sieć, za NAT-em, za firewallem, do której nie masz (i nie chcesz mieć) bezpośredniego dostępu. U klienta stawiasz Zabbix proxy w trybie active. To proxy inicjuje wszystkie połączenia do serwera — serwer nigdy nie łączy się do proxy. Serwer nawet nie musi znać IP proxy.

W tym modelu Serwer zabixa sam nigdy nie komunikuje się z Proxy u klienta. To Proxy wysyła dane na ip serwera w świat (czśto na wysokim porcie), a jeśli np firewall na serwerze przyjmuje dane tylko z podanych ip to to jest najbezpieczeniejsze co można wymyślić poza VPN .

Jak to wygląda w praktyce

Sieć klienta (za NAT/firewall):                    Twój DC:
┌──────────────────────────┐                ┌──────────────────┐
│ [Host 1] ──┐             │                │                  │
│ [Host 2] ──┤── LAN ── [Zabbix Proxy] ──────────► [Zabbix Server]  │
│ [Host 3] ──┘   (active)  │   port 10051   │  + Frontend + DB │
│ [Switch] ──┘             │                │                  │
└──────────────────────────┘                └──────────────────┘
         ← proxy inicjuje połączenie →
         ← serwer NIE łączy się do proxy →

Kluczowa sprawa: active proxy sam puka do serwera. Pobiera konfigurację (jakie hosty monitorować, jakie itemy zbierać) i odsyła zebrane dane. Serwer nie musi mieć routingu do sieci klienta. Firewall u klienta musi przepuścić tylko jeden port wychodzący (domyślnie 10051 TCP) do serwera Zabbix.

Konfiguracja proxy

Na maszynie u klienta instalujesz Zabbix proxy. W zabbix_proxy.conf:

ini

ProxyMode=0                          # 0 = active (domyślne)
Hostname=klient-abc-proxy            # musi się zgadzać z nazwą w frontendzie
Server=zabbix.twojafirma.pl:10051   # adres Twojego serwera Zabbix
DBName=/tmp/zabbix_proxy.db          # SQLite wystarczy dla małych wdrożeń
ConfigFrequency=120                  # co ile sekund pobierać konfigurację
DataSenderFrequency=5                # co ile sekund wysyłać dane
ProxyOfflineBuffer=72                # ile godzin trzymać dane przy braku łączności

Na frontendzie serwera Zabbix: Administration → Proxies → Create proxy — wpisujesz nazwę klient-abc-proxy, tryb Active. Nie musisz podawać żadnego IP proxy.

Konfiguracja agentów u klienta

Agenty wskazują na lokalne IP proxy, nie na serwer Zabbix:

ini

Server=192.168.10.50           # IP proxy w sieci klienta
ServerActive=192.168.10.50     # IP proxy w sieci klienta
Hostname=klient-abc-dc01       # unikalna nazwa hosta

Agent nie wie, że rozmawia z proxy a nie z serwerem — protokół jest identyczny.

Przepływ danych

1. Proxy → Serwer: Proxy łączy się z serwerem co ConfigFrequency sekund i pobiera konfigurację (lista hostów, itemów, triggerów do monitorowania).
2. Agenty → Proxy: Agenty w sieci klienta raportują dane do proxy (LAN, bez wychodzenia na zewnątrz).
3. Proxy → Serwer: Proxy buforuje dane lokalnie i wysyła je do serwera co DataSenderFrequency sekund.
4. Serwer przetwarza: Triggery, eventy, alerty — to wszystko dzieje się na serwerze. Proxy jest tylko kolektorem danych.

Serwer nigdy nie inicjuje połączenia do proxy. Proxy puka do serwera. To fundamentalna różnica, która rozwiązuje problem NAT-u, firewalli i braku bezpośredniego dostępu do sieci klienta.

Co się dzieje, gdy padnie łącze?

Proxy buforuje dane lokalnie. Parametr ProxyOfflineBuffer (domyślnie 1 godzina) określa, jak długo proxy trzyma dane, gdy nie może połączyć się z serwerem. Ustawiasz np. 72 godziny — i proxy przeżyje weekend bez łączności. Gdy połączenie wróci, proxy wyśle zaległe dane i serwer je przetworzy.

W trybie ProxyBufferMode=hybrid (od Zabbix 7.0) proxy trzyma dane w pamięci dla szybkości, a gdy pamięć się zapełni — zrzuca na dysk. Najlepsze z obu światów.

Zalety

• Firewall-friendly — jedyne wymaganie: port wychodzący z proxy do serwera. Żadnych portów przychodzących u klienta, żadnego VPN-a, żadnego otwierania dziur.
• Serwer nie ma dostępu do sieci klienta — i to jest feature, nie bug. Separacja jest pełna. Serwer nie może skanować sieci klienta, nie może łączyć się z hostami. Dane płyną tylko w jedną stronę: od proxy do serwera.
• Buforowanie offline — awaria łącza nie oznacza utraty danych. Proxy trzyma metryki lokalnie i dosyła je po przywróceniu połączenia.
• Skalowalność — jeden serwer Zabbix, dziesiątki proxy u różnych klientów. Każde proxy zbiera dane ze swojego segmentu, serwer centralizuje wszystko.
• Odciążenie serwera — proxy wykonuje preprocessing danych i skanowanie sieci (discovery) lokalnie. Serwer dostaje gotowe dane.
• Prosta konfiguracja sieciowa — nie musisz znać publicznego IP proxy, nie musisz konfigurować port forwarding u klienta. Proxy samo się łączy.

Wady

• Brak remote commands — serwer nie może wysłać komendy do hosta przez active proxy, bo nie ma do niego bezpośredniego połączenia. Od Zabbix 7.0 active agent potrafi odbierać remote commands, ale wymaga to dodatkowej konfiguracji.
• Opóźnienie w danych — dane nie trafiają na serwer natychmiastowo. Jest bufor, jest DataSenderFrequency. W praktyce opóźnienie to kilka sekund, ale nie jest zerowe.
• Opóźnienie w konfiguracji — po zmianie itemów na serwerze proxy musi pobrać nową konfigurację. Domyślnie ConfigFrequency=3600 (1 godzina!). Warto zmniejszyć do 120-300 sekund. Można też wymusić ręcznie: zabbix_proxy -R config_cache_reload.
• Dodatkowy komponent — proxy to kolejna maszyna do utrzymania, kolejna baza danych, kolejny serwis do monitorowania (tak — monitoruj swoje proxy).
• Brak passive checks z serwera — serwer nie może odpytać agenta przez proxy w trybie active. Agenty muszą pracować w trybie active checks.

Kiedy stosować

Monitorujesz infrastrukturę klientów jako usługę (MSP/MSSP). Masz wiele oddziałów za NAT-em. Klient nie chce (słusznie) otwierać VPN-a do Twojego serwera. Potrzebujesz centralnego dashboardu dla wielu lokalizacji. Chcesz separacji — serwer nie powinien mieć dostępu do sieci klienta.

Porównanie: LAN vs Active Proxy

Cecha	Zabbix na LAN	Zabbix + Active Proxy
Złożoność wdrożenia	Niska	Średnia
Firewall/NAT	Nie przeszkadza	Rozwiązany — proxy łączy się na zewnątrz
Serwer ma dostęp do sieci klienta	Tak (pełny)	Nie (zero)
Kierunek połączenia	Serwer Agent	Proxy → Serwer (jednokierunkowy)
Passive checks	Tak	Nie (tylko active)
Remote commands	Tak	Ograniczone
Buforowanie offline	Nie	Tak (do 72h+)
Skalowalność lokalizacji	Jedna	Wiele
Opóźnienie danych	Brak	Kilka sekund
Koszt	1 serwer	1 serwer + N proxy
Monitoring SNMP/IPMI	Bezpośredni z serwera	Przez proxy (lokalnie)

Który model wybrać?

To nie jest kwestia „lepszy/gorszy”. To kwestia kontekstu.

Jeśli monitorujesz swoją infrastrukturę, w jednej lokalizacji, na jednym LAN-ie — stawiasz serwer Zabbix i nie komplikujesz sobie życia. Proxy jest zbędne.

Jeśli monitorujesz infrastrukturę klientów, zarządzasz wieloma lokalizacjami, albo potrzebujesz monitoringu bez VPN-a i bez otwierania portów u klienta — active proxy to jedyna sensowna droga. Proxy puka do Twojego serwera, wysyła dane, a serwer nigdy nie widzi sieci klienta. Bezpiecznie, skalowalne, firewall-friendly.

W praktyce oba modele mogą współistnieć. Serwer Zabbix monitoruje lokalny LAN bezpośrednio, a jednocześnie odbiera dane z proxy rozsianych po lokalizacjach klientów. To nie jest albo-albo — to kwestia dopasowania architektury do potrzeb.

Artykuł Zabbix na LAN vs Zabbix Proxy – dwa modele, które warto znać pochodzi z serwisu Z IT Wzięte.