Zabbix 8.0 LTS przynosi to, o co administratorzy pytali od lat: oficjalną aplikację mobilną i powiadomienia push wysyłane prosto na telefon. Bez przekaźnika pocztowego, bez własnego skryptu, bez bramki po drodze.
To przydatny dodatek. Rodzi jednak oczywiste pytanie, na które wolimy odpowiedzieć wprost, niż udawać, że nikt go nie zadał:
Skoro Zabbix sam wyśle alert na telefon, czy bramka SMS jest jeszcze potrzebna?
Uczciwa odpowiedź brzmi tak: push i SMS zawodzą z zupełnie innych powodów, a sens ścieżki alertowania polega właśnie na tym, żeby jej kolejne poziomy nie padały razem. Poniżej opisujemy, jak naprawdę wygląda architektura push według dokumentacji Zabbiksa, jakie zależności wprowadza i w czym SMS oraz połączenia głosowe nadal robią coś, czego push z założenia nie potrafi.
Najważniejszy szczegół stoi w pierwszym akapicie dokumentacji komponentu bridge adapter: aplikacja mobilna nie łączy się z Twoim serwerem Zabbix bezpośrednio. Pomiędzy nimi stoją dwa elementy.
Zabbix Bridge to centralnie hostowana usługa, prowadzona przez Zabbix SIA, która wymienia dane z aplikacją na Twoim telefonie.
Zabbix bridge adapter to komponent, który instalujesz i utrzymujesz sam, na serwerze Zabbix albo na osobnej maszynie. Łączy Twój serwer z usługą Zabbix Bridge i decyduje, które metody API wolno wywołać aplikacji.
Droga alertu push wygląda więc tak:
Zabbix 8.0 dokłada do tego resztę: typ powiadomień Push notification, sekcje Users > Devices i User settings > Devices, osobny obszar Devices w rolach użytkowników oraz dwa nowe parametry serwera, BridgeAdapterURL i EnableMobileDevices.
Dwa zdania z dokumentacji warto powtórzyć, bo pokazują, jak mocno te części są ze sobą związane. Pierwsze: bez skonfigurowanego adaptera typ powiadomień push da się utworzyć, ale nie zadziała. Drugie: EnableMobileDevices jest domyślnie włączony, co samo w sobie niczego nie zmienia, dopóki adapter nie jest osiągalny.
Aplikacja, adapter i centralny Bridge to nie jest otwartoźródłowy Zabbix. To osobne komponenty na własnych warunkach licencyjnych, spoza pakietu serwera, który już u siebie masz. Jeśli Twój dział zakupów albo compliance traktuje „otwarte źródła, własna infrastruktura” jako rzecz oczywistą dla systemu monitorowania, push jest dla nich nowym pytaniem, a nie kolejną funkcją w czymś, co zostało już przyklepane.
Klaster wysokiej dostępności Zabbiksa nie obejmuje adaptera. Uruchomienie Zabbiksa w HA nie sprawia, że bridge adapter staje się wysokodostępny. Każdy węzeł potrzebuje własnego, osiągalnego adaptera, a jego dostępność, odtwarzanie i stan rejestracji trzeba zaplanować osobno. W ścieżce alertowania pojawia się element, którego Twój dotychczasowy projekt HA po prostu nie pokrywa.
Adapter widzi treść alertu. Serwer Zabbix przekazuje mu tytuł, treść i metadane zdarzenia. Szyfrowanie ładunku po stronie urządzenia i TLS między komponentami to osobne warstwy ochrony, a to rozróżnienie przydaje się przy decyzji, co w ogóle może znaleźć się w treści powiadomienia.
Uwaga na marginesie: w chwili pisania tego tekstu dokumentacja 8.0 opisuje oficjalną aplikację mobilną jako zapowiedzianą, jeszcze niedostępną. Jeśli planujesz alertowanie wokół aktualizacji do 8.0, warto o tym wiedzieć, zanim oprzesz grafik dyżurów na kanale, którego nie ma jeszcze w sklepach z aplikacjami.
Każdy kanał dostarczania ma listę rzeczy, które muszą działać, żeby wiadomość doszła. Przy poczcie wszyscy znają ją na pamięć. Przy push jest dłuższa, niż się wydaje na pierwszy rzut oka:
| Co musi działać | Powiadomienie push | SMS lub połączenie głosowe z lokalnej bramki |
|---|---|---|
| Po Twojej stronie | ||
| Serwer Zabbix | ✓ | ✓ |
| Bridge adapterdodatkowy komponent, który instalujesz i utrzymujesz | ✓ | – |
| Ruch wychodzący do internetu z Twojej sieci | ✓ | – |
| Zabbix Bridgeusługa hostowana przez podmiot zewnętrzny | ✓ | – |
| Po stronie odbiorcy | ||
| Transmisja danych albo Wi-Fi w telefonie | ✓ | – |
| Zainstalowana aplikacja, zalogowana, z włączonymi powiadomieniami | ✓ | – |
| Zasięg sieci komórkowej i aktywna karta SIM | – | ✓ |
| Rzeczy, które muszą działać | 6 | 2 |
Żadna z kolumn nie jest lepsza. To dwie różne listy i w tym rzecz.
Żadna z kolumn nie jest „lepsza”. To po prostu dwie różne listy i w tym rzecz. Alert wysłany drogą z prawej kolumny nie przejmuje się tym, czy droga z lewej w ogóle stoi.
1. Awaria dotyczy samego łącza internetowego. Pada operator, umiera router brzegowy, zmiana reguły na firewallu odcina ruch wychodzący. Zabbix widzi to natychmiast i uruchamia akcję. Alert push potrzebuje teraz tego samego łącza, żeby opuścić Twoją sieć, dotrzeć do Zabbix Bridge i wrócić na telefon. Powiadomienie o awarii zostaje uwięzione za tą awarią. Transmisja danych w telefonie dyżurnego tu nie pomoże, bo przerwa jest po stronie nadawcy. SMS z bramki stojącej w Twojej szafie wychodzi siecią komórkową, niezależnie od tego, co dzieje się z łączem.
2. Dyżurny ma zasięg, ale nie ma transmisji danych. Serwerownia w podziemiach, winda, hala produkcyjna, pociąg w tunelu, roaming z wyłączonymi danymi. Połączenie głosowe i SMS przechodzą przy jednej kresce zasięgu. Powiadomienie push czeka w kolejce, aż telefon znajdzie używalne połączenie danych.
3. Powiadomienie dotarło i nikt się nie obudził. Ta najcichsza. Powiadomienia push podlegają optymalizacji baterii, trybowi Nie przeszkadzać, trybom skupienia i ustawieniom per aplikacja. Dzwoniący telefon zachowuje się inaczej niż baner, i to z założenia. O trzeciej w nocy, przy zdarzeniu najwyższej wagi, ta różnica jest całą wartością kanału.
Dochodzi do tego kwestia zgodności, która wraca w środowiskach regulowanych i w sektorze publicznym. Push oznacza, że dane o problemie i metadane wędrują przez usługę hostowaną na zewnątrz. Dla większości organizacji to zupełnie normalne. Dla części wykluczone, a wtedy architektura odpowiada na pytanie, zanim ktokolwiek zacznie porównywać funkcje.
Jesteśmy producentem bramek, więc nasze spojrzenie nie jest bezstronne. Oto niezależne.
Tomáš Heřmánek z initMAX, firmy ze statusem Zabbix Premium Partner, szczegółowo opisał architekturę push w swoim omówieniu Zabbiksa 8.0, razem z sekcją o tym, co z niej wynika dla alertowania. O granicach push jako kanału do zgłaszania awarii łączności pisze, że „push nie jest niezależnym kanałem zgłaszania awarii połączenia internetowego”, a o kwestii pracy we własnej infrastrukturze, że „sam lokalny adapter nie czyni jeszcze rozwiązania w pełni on-premises”.
Jego wnioski o alternatywnej ścieżce warto przeczytać w całości w oryginalnym artykule, łącznie z zastrzeżeniami, jakie do niej zgłasza: bramka potrzebuje zasilania, zasięgu, aktywnej karty SIM i działającego połączenia lokalnego z Zabbiksem, a leżącego serwera ani całej sieci LAN nie zastąpi. SMS nie jest też szyfrowany końcowo, więc w treści powiadomienia powinno znaleźć się tylko to, co konieczne.
I to jest właściwe ujęcie sprawy. Żaden kanał nie działa bezwarunkowo. Pytanie brzmi, czy Twoje kanały zawiodą z tego samego powodu i w tym samym momencie.
Zabbix obsługuje SMS od zawsze i warto być precyzyjnym co do tego, czym ta obsługa jest. Wbudowany typ powiadomień SMS steruje modemem GSM podłączonym do portu szeregowego serwera Zabbix. Dokumentacja wymienia dwa przetestowane modemy, Siemens MC35 i Teltonika ModemCOM/G10, i odnotowuje ograniczenie, które przy większej skali waży najwięcej: powiadomienia SMS nie są wysyłane równolegle.
W praktyce wiadomości wychodzą jedna po drugiej, z pojedynczego modemu na jednym serwerze. Przy kilku alertach to bez znaczenia. Przy lawinie zdarzeń, długiej liście dyżurnych albo serwerze, którego wolałbyś nie przywiązywać fizycznym kablem, robi się z tego wąskie gardło dokładnie wtedy, gdy przepustowość jest najbardziej potrzebna.
Bramka sprzętowa w sieci znosi oba ograniczenia. Jest osiągalna przez API z dowolnego miejsca w infrastrukturze, nie jest przypisana do jednego hosta, mieści kilka modemów i przeżywa restart albo migrację serwera Zabbix.
Nie „push albo SMS”. Warstwy, uszeregowane według tego, od ilu rzeczy każda z nich zależy.
Warstwa 1, push i poczta. Pełny kontekst, możliwość reakcji z poziomu powiadomienia, brak kosztu za wiadomość. Właściwe ustawienie domyślne dla większości zdarzeń, kiedy inżynier siedzi przy biurku, a sieć działa.
Warstwa 2, SMS. Podłoga pod warstwą pierwszą. Nie wymaga niczego poza zasięgiem sieci komórkowej. Właściwy kanał dla zdarzeń najwyższej wagi i dla kroku eskalacji po niepotwierdzonym powiadomieniu push.
Warstwa 3, połączenie głosowe. Dla zdarzeń, przy których ktoś musi się obudzić. Dzwoniący telefon przebija się przez tryb Nie przeszkadzać tak, jak nie zrobi tego żaden baner.
Zabbix pozwala to poskładać bez żadnej własnej logiki, krokami eskalacji w konfiguracji akcji. Push jest po prostu kolejnym krokiem eskalacji. Praktyczny układ wygląda tak:
Alert eskaluje się sam, a każdy kolejny krok zależy od mniejszej liczby rzeczy niż poprzedni. I to jest cała zasada. Ostatnia deska ratunku powinna być kanałem o najkrótszej liście zależności, nie najdłuższej.
Jeszcze jeden argument za tym, żeby trzymać skonfigurowany SMS: alert, którego potrzebujesz najbardziej, to ten mówiący, że sam Zabbix albo sieć, w której stoi, mają kłopot. A to dokładnie ten alert, na którego dostarczenie przez łańcuch push nie można liczyć.
SMSEagle to sprzętowa bramka SMS, która stoi w Twojej szafie rack i wysyła przez sieć komórkową, bez usługi chmurowej w ścieżce dostarczania i bez opłaty za wiadomość. Integracja z Zabbiksem to natywny typ powiadomień: importujesz jeden plik, wskazujesz urządzenie i SMS, MMS oraz połączenia głosowe z syntezą mowy stają się w Zabbiksie dostępne w tej samej ścieżce eskalacji co push i poczta. Działa na bieżących wersjach Zabbiksa, w tym na 8.0.
Jeśli interesuje Cię szerszy wywód o usługach zewnętrznych w ścieżce alertowania, opisaliśmy go osobno w tekście SMS online czy SMS offline.
Czy powiadomienia push w Zabbix 8.0 zastępują bramkę SMS?
Nie. Push zależy od ruchu wychodzącego z Twojej sieci, od hostowanej usługi Zabbix Bridge i od transmisji danych w telefonie odbiorcy. SMS zależy wyłącznie od zasięgu sieci komórkowej. To uzupełniające się warstwy ścieżki eskalacji, nie alternatywy.
Czy aplikacja mobilna łączy się bezpośrednio z moim serwerem Zabbix?
Nie. Zgodnie z dokumentacją Zabbiksa aplikacja komunikuje się z centralnie hostowaną usługą Zabbix Bridge, która przekazuje żądania do adaptera uruchomionego u Ciebie. Dopiero adapter rozmawia z lokalnym API Zabbiksa.
Czy powiadomienia push są częścią otwartoźródłowego Zabbiksa?
Typ powiadomień i zarządzanie urządzeniami są w serwerze i interfejsie, ale aplikacja mobilna, bridge adapter i centralna usługa Zabbix Bridge to osobne komponenty na własnych warunkach licencyjnych, spoza pakietu otwartoźródłowego serwera.
Czy klaster HA Zabbiksa obejmuje bridge adapter?
Nie. Uruchomienie Zabbiksa w klastrze wysokiej dostępności nie czyni adaptera wysokodostępnym. Każdy węzeł serwera potrzebuje skonfigurowanego, osiągalnego adaptera, a jego dostępność planuje się osobno.
Co trzeba zainstalować, żeby push zadziałał?
Bridge adapter, na serwerze Zabbix albo na osobnej maszynie, plus parametry serwera BridgeAdapterURL i EnableMobileDevices oraz typ powiadomień Push. Bez skonfigurowanego i osiągalnego adaptera parowanie urządzenia i dostarczanie powiadomień się nie powiedzie.
Czy mogę używać push i SMS jednocześnie?
Tak i właśnie tak radzimy to ustawić. Skonfiguruj je jako osobne typy powiadomień i ustaw jako kolejne kroki eskalacji w akcji, tak aby niepotwierdzony push eskalował się do SMS-a, a potem do połączenia głosowego.
Czy wbudowany typ SMS wystarczy?
Steruje modemem GSM podłączonym do portu szeregowego serwera Zabbix i nie wysyła powiadomień równolegle. Przy małych wdrożeniach to działa, przy lawinie zdarzeń albo długiej liście dyżurnych staje się wąskim gardłem. Bramka w sieci znosi oba ograniczenia.
Czy integracja SMSEagle działa na Zabbix 8.0?
Tak. Szczegóły i instrukcja konfiguracji są na stronie integracji.
