Zabbix jest elastyczny. Możesz go postawić na jednym serwerze i monitorować wszystko w jednej sieci. Możesz też rozciągnąć monitoring na dziesiątki lokalizacji, gdzie serwer Zabbix nigdy nie widzi sieci klienta bezpośrednio. W tym artykule porównuję dwa konkretne scenariusze wdrożenia: Zabbix działający lokalnie na LAN-ie oraz Zabbix z active proxy postawionym u klienta, gdzie to proxy inicjuje połączenie do serwera — a nie odwrotnie.
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 hostaI 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ściNa 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 hostaAgent nie wie, że rozmawia z proxy a nie z serwerem — protokół jest identyczny.
Przepływ danych
- Proxy → Serwer: Proxy łączy się z serwerem co
ConfigFrequencysekund i pobiera konfigurację (lista hostów, itemów, triggerów do monitorowania). - Agenty → Proxy: Agenty w sieci klienta raportują dane do proxy (LAN, bez wychodzenia na zewnątrz).
- Proxy → Serwer: Proxy buforuje dane lokalnie i wysyła je do serwera co
DataSenderFrequencysekund. - 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.
Zabbix - Lan vs Proxy
Zabbix proxy to komponent pośredniczący między monitorowanymi hostami a serwerem Zabbix. Zbiera dane z agentów w lokalnej sieci, buforuje je i przesyła do centralnego serwera. Dzięki temu można monitorować zdalne lokalizacje bez konieczności otwierania bezpośredniego dostępu do sieci klienta.
W trybie active to proxy inicjuje połączenie do serwera Zabbix — sam pobiera konfigurację i odsyła zebrane dane. Serwer nie musi znać adresu IP proxy. W trybie passive to serwer łączy się do proxy i odpytuje je o dane. Tryb active jest preferowany w środowiskach za NAT-em i firewallem, ponieważ wymaga jedynie połączenia wychodzącego z proxy.
Tak, Zabbix proxy w trybie active działa bez problemu za NAT-em i firewallem. Proxy samo inicjuje połączenie wychodzące do serwera Zabbix na porcie 10051 TCP. Nie trzeba otwierać żadnych portów przychodzących u klienta ani konfigurować przekierowania portów.
Zabbix proxy buforuje zebrane dane lokalnie. Parametr ProxyOfflineBuffer określa, jak długo proxy przechowuje dane bez łączności z serwerem — domyślnie 1 godzinę, ale można ustawić nawet 72 godziny lub więcej. Po przywróceniu połączenia proxy automatycznie dosyła zaległe dane do serwera.
Nie, VPN nie jest wymagany. Zabbix proxy w trybie active pozwala monitorować zdalną sieć klienta bez VPN-a. Proxy instaluje się w sieci klienta, gdzie zbiera dane lokalnie, a następnie samo łączy się z centralnym serwerem Zabbix przez internet. Serwer nigdy nie uzyskuje bezpośredniego dostępu do sieci klienta.
Zabbix bez proxy wystarczy, gdy monitorujesz infrastrukturę w jednej lokalizacji i jednej sieci LAN. Serwer Zabbix ma bezpośredni dostęp do wszystkich hostów, agentów i urządzeń sieciowych. To najprostszy model wdrożenia — idealne dla małych i średnich firm z jedną serwerownią.
Wydajność proxy zależy od liczby monitorowanych metryk (NVPS — new values per second) i zasobów sprzętowych. Dla instalacji zbierających poniżej 1000 NVPS wystarczy lekka maszyna z bazą SQLite. Przy większym obciążeniu zaleca się PostgreSQL lub MySQL oraz więcej pamięci RAM. Jedno proxy może obsłużyć setki hostów z tysiącami metryk.
Nie. W modelu z active proxy serwer Zabbix nie ma żadnego dostępu do sieci klienta. Dane płyną jednokierunkowo — proxy łączy się z serwerem i wysyła zebrane metryki. Serwer nie może skanować sieci klienta, łączyć się z hostami ani inicjować żadnych połączeń do proxy. To zapewnia pełną separację sieciową.
W pliku zabbix_proxy.conf ustawiasz ProxyMode=0 (active), Hostname zgodny z nazwą w frontendzie serwera, adres serwera w parametrze Server oraz bazę danych (np. SQLite). Na serwerze Zabbix tworzysz proxy w sekcji Administration — Proxies, podając tę samą nazwę i tryb Active. Agenty u klienta wskazują na lokalne IP proxy zamiast na serwer.
Tak, oba modele mogą współistnieć. Serwer Zabbix może jednocześnie monitorować hosty w lokalnej sieci LAN bezpośrednio oraz odbierać dane z wielu proxy rozsianych po zdalnych lokalizacjach klientów. Hosty przypisuje się do konkretnego proxy w konfiguracji hosta na frontendzie Zabbix.
