Powiadomienia o zdarzeniach w UniFi

Ekosystem UniFi potrafi rejestrować awarie połączenia internetowego, problemy z urządzeniami, zdarzenia bezpieczeństwa oraz zmiany wykonywane przez administratorów. Odpowiednio skonfigurowane powiadomienia sprawiają, że istotna informacja nie pozostaje wyłącznie w dzienniku, lecz trafia do właściwej osoby przez aplikację mobilną, wiadomość email albo zewnętrzny system.

Od zdarzenia do powiadomienia

Gdy połączenie WAN przestaje działać, urządzenie przechodzi w tryb offline albo switch wykrywa problem z portem, UniFi zapisuje takie zdarzenie w dzienniku. Wpis może zawierać czas wystąpienia, kategorię, poziom ważności oraz informacje o urządzeniu lub kliencie. Filtry Severity, Time Range, Category, Type i Event pozwalają ograniczyć listę do zdarzeń potrzebnych podczas diagnostyki.

Sam dziennik nie gwarantuje jednak, że administrator zauważy problem w odpowiednim momencie. Dopiero reguła w Alarm Managerze wskazuje, które zdarzenia wymagają reakcji, czego dotyczą oraz co system ma wtedy zrobić. W praktyce należy więc rozdzielić cztery pojęcia: zdarzenie jest faktem zarejestrowanym przez system, log jest jego zapisem, alarm opisuje warunki reakcji, a powiadomienie jest wiadomością wysłaną do konkretnej osoby lub usługi.

O jakich zdarzeniach może informować UniFi

Zakres dostępnych zdarzeń zależy od aplikacji, zainstalowanych urządzeń oraz wersji oprogramowania. Wspólna logika pozostaje podobna, ale inne informacje będą ważne w sieci, inne w monitoringu wizyjnym, a jeszcze inne w systemie kontroli dostępu.

UniFi Network

W aplikacji Network zdarzenia są grupowane między innymi w kategoriach Monitoring, Internet, Power, Security i System. Administrator może reagować na niedostępność łącza WAN, wysokie opóźnienia, utratę pakietów, przejście urządzenia w tryb offline, problemy z PoE, wykrycie zagrożenia, rozłączenie VPN, błędy portów oraz zmiany konfiguracji. Nie każda instalacja wygeneruje wszystkie typy wpisów, ponieważ część z nich wymaga określonego gatewaya, switcha albo włączonej funkcji bezpieczeństwa.

UniFi Protect

W Protect alarm może być uruchomiony przez wykrycie osoby, pojazdu, paczki, zwierzęcia, twarzy lub tablicy rejestracyjnej. Dostępne są także zdarzenia ruchu, dźwięku, przekroczenia linii, użycia dzwonka, stanu kamer oraz czujników, na przykład zalania, dymu lub tlenku węgla. Dostępność zaawansowanych detekcji zależy od modelu urządzenia.

UniFi Access

W Access powiadomienia mogą dotyczyć otwarcia drzwi, odmowy dostępu, użycia dzwonka, zmiany stanu urządzenia, aktualizacji danych użytkownika albo uruchomienia trybu awaryjnego. Akcją może być nie tylko wiadomość, lecz również reakcja systemu, na przykład zablokowanie lub odblokowanie wybranych drzwi.

Alarm Manager, czyli wybór informacji wymagających reakcji

Alarm Manager jest centralnym miejscem do tworzenia reguł. Główny ekran pokazuje utworzone alarmy, ich kategorie, akcje, ostatnie uruchomienie oraz ustawienia powiadomień bieżącego użytkownika. Dzięki temu można szybko sprawdzić, czy alarm jest aktywny i jaką drogą ma zostać dostarczona informacja.

Każda reguła składa się z trzech podstawowych elementów:

• Trigger, czyli zdarzenie uruchamiające alarm, na przykład utrata łączności z urządzeniem.
• Scope, czyli zakres obejmujący określone urządzenia, klientów, sieci VLAN albo cały system.
• Action, czyli działanie wykonywane po spełnieniu warunku, na przykład powiadomienie lub webhook.

Trigger, czyli co ma uruchomić alarm

Tworzenie reguły zaczyna się od wyboru zdarzenia. Kategorie po lewej stronie ułatwiają odnalezienie zdarzeń związanych z internetem, zasilaniem, bezpieczeństwem, urządzeniami lub aktywnością klientów. Dobry alarm powinien opisywać konkretną sytuację. Reguła „UniFi Device Offline” jest czytelniejsza i łatwiejsza do obsługi niż próba wysyłania każdego wpisu z kategorii System.

Scope i harmonogram, czyli czego dotyczy reguła

Zakres ogranicza alarm do właściwych elementów infrastruktury. W małej instalacji można objąć regułą wszystkie urządzenia, ale w większej sieci lepiej oddzielić gatewaye, główne switche, punkty dostępowe i urządzenia mniej istotne. Im precyzyjniejszy zakres, tym mniej zbędnych komunikatów.

Część wyzwalaczy pozwala także wybrać tryb Always lub ustawić Custom Schedule. Harmonogram ma znaczenie między innymi przy zdarzeniach, które są normalne w godzinach pracy, ale po jej zakończeniu powinny zostać potraktowane jako incydent.

Action, czyli co system ma zrobić

W Network podstawowymi akcjami są Notify oraz Webhook. Notify kieruje informację do wybranych użytkowników, natomiast webhook przekazuje zdarzenie do zewnętrznej usługi. Dostępne akcje zależą od aplikacji. Protect może dodatkowo uruchamiać reakcje sprzętowe, a Protect i Access mogą sterować drzwiami zgodnie z obsługiwanym scenariuszem.

Opcja Ignore Repeated Alarms ogranicza powtarzanie tej samej reakcji. Ma to szczególne znaczenie przy niestabilnym łączu lub urządzeniu, które wielokrotnie zmienia stan. Bez takiego ograniczenia jeden problem może wygenerować serię podobnych komunikatów.

Wbudowane kanały powiadomień

Akcja Notify pozwala wskazać odbiorców oraz kanał Mobile App lub Email. Powiadomienie push jest wygodne przy zdarzeniach wymagających szybkiej reakcji, ponieważ pojawia się w aplikacji mobilnej UniFi. Email lepiej sprawdza się jako dodatkowy zapis, przy mniej pilnych alarmach oraz wtedy, gdy wiadomość ma pozostać w skrzynce odbiorczej do późniejszej analizy.

Po utworzeniu alarmu każdy użytkownik zarządza dostarczaniem przez kolumnę My Notifications. Push jest domyślnie włączony dla wybranego użytkownika, natomiast email trzeba aktywować osobno. Preferencje mogą działać zawsze, według własnego harmonogramu albo zostać wyłączone. Ustawienia są przypisane do użytkownika, więc ten sam alarm może być dostarczany różnym osobom innymi kanałami.

Webhook, czyli przekazanie alarmu do innego systemu

Webhook wysyła żądanie HTTP do wskazanego adresu, gdy alarm zostanie uruchomiony. UniFi obsługuje metody GET i POST. GET może wystarczyć do prostego wywołania adresu, natomiast POST pozwala przekazać dodatkowe dane związane z alarmem. Formularz umożliwia również skonfigurowanie nagłówków, uwierzytelnienia i zawartości żądania.

Webhook nie musi prowadzić bezpośrednio do komunikatora. Często lepszym rozwiązaniem jest przekazanie zdarzenia do własnego endpointu albo platformy automatyzacyjnej, która sprawdzi dane, ustali priorytet i dopiero potem utworzy wiadomość lub zgłoszenie. W ten sposób można zrealizować między innymi:

• Wiadomość na kanale zespołu technicznego, na przykład w Slacku, Teams lub innym komunikatorze.
• Automatyczne utworzenie zgłoszenia w systemie helpdesk albo ServiceNow.
• Uruchomienie własnego skryptu, funkcji serwerowej lub scenariusza automatyzacji.
• Przekazanie alarmu do centralnego systemu obsługującego wiele lokalizacji.

Adres webhooka, tokeny i niestandardowe nagłówki należy traktować jak dane poufne. Przed wdrożeniem regułę trzeba przetestować na neutralnym odbiorniku, a następnie sprawdzić, czy zewnętrzna usługa poprawnie rozpoznaje ponowienia, błędy i kilka alarmów występujących w krótkim czasie.

SIEM, SNMP i API, czyli monitoring poza Alarm Managerem

Alarm Manager odpowiada na wybrane zdarzenia, ale większe środowiska zwykle potrzebują także historii, korelacji i stałej obserwacji parametrów. Właśnie tutaj pojawiają się SIEM, SNMP oraz API. Te mechanizmy uzupełniają alarmy, lecz nie są ich prostymi zamiennikami.

Eksport logów do SIEM

W ustawieniach Integration, w sekcji System Logging lub SIEM, można wybrać kategorie logów oraz podać adres i port zewnętrznego serwera. UniFi eksportuje logi w formacie Common Event Format, czyli CEF. Uporządkowana struktura ułatwia parsowanie zdarzeń, wyszukiwanie ich razem z logami innych systemów, tworzenie reguł korelacyjnych oraz zachowanie historii przez okres wymagany w organizacji.

SIEM jest szczególnie przydatny, gdy administrator chce powiązać zmianę konfiguracji z logowaniem konkretnego konta, zestawić incydent sieciowy z alertami zapory albo analizować kilka lokalizacji w jednym miejscu. Nie zastępuje jednak prostego powiadomienia push, gdy potrzebna jest szybka informacja o awarii.

SNMP jako źródło parametrów dla monitoringu

SNMP pozwala systemom takim jak Zabbix, PRTG lub Nagios regularnie odpytywać obsługiwane urządzenia UniFi o wartości OID. Plik MIB zamienia część numerów OID na czytelne nazwy parametrów. Dzięki temu zewnętrzny monitoring może obserwować stan urządzeń i tworzyć własne progi alarmowe niezależnie od reguł dostępnych w interfejsie UniFi.

UniFi udostępnia SNMP v1 i v2c z community string oraz SNMP v3 z uwierzytelnianiem i opcjonalnym szyfrowaniem. W nowym wdrożeniu lepiej użyć SNMP v3, jeżeli system monitoringu je obsługuje. Nie wszystkie modele udostępniają SNMP. Dokumentacja wskazuje między innymi brak obsługi w switchach USW Flex i Ultra.

API dla jednej lub wielu lokalizacji

Oficjalne Site Manager API udostępnia dane wysokiego poziomu dotyczące wszystkich lokalizacji powiązanych z kontem. Może służyć do zbierania informacji o stanie internetu, urządzeniach i wydajności wielu wdrożeń. Lokalne API poszczególnych aplikacji zapewniają bardziej szczegółowe dane i funkcje dotyczące jednej instalacji. Dokumentację zgodną z używaną wersją Network można otworzyć w sekcji Integrations.

API ma sens wtedy, gdy gotowe alarmy i webhooki nie wystarczają, na przykład przy budowie własnego panelu dla wielu klientów albo przy łączeniu danych UniFi z wewnętrznym systemem operacyjnym. Wymaga jednak obsługi kluczy, limitów zapytań, błędów oraz zmian wersji, dlatego nie powinno być pierwszym wyborem w prostej instalacji.

Dobór metody do wielkości instalacji

Najprostszy skuteczny system nie musi korzystać ze wszystkich dostępnych integracji. Powinien jednak dostarczyć istotną informację właściwej osobie i zachować dane potrzebne do późniejszej analizy. Poniższe zestawienie pokazuje rozsądny punkt startowy.

Dobór kanałów zależy od znaczenia usługi, liczby lokalizacji i czasu reakcji, którego wymaga organizacja.

Jak uniknąć alarmów, które wszyscy zaczną ignorować

Największym problemem zwykle nie jest brak danych, lecz ich nadmiar. Jeżeli każde rozłączenie telefonu, roaming klienta i krótkie wahanie jakości WAN generuje wiadomość, odbiorcy szybko przestają na nią reagować. Alarm powinien wskazywać sytuację, w której od konkretnej osoby oczekuje się działania.

• Nie wysyłaj wszystkiego do wszystkich. Rozdziel alarmy dotyczące sieci, bezpieczeństwa, systemu i zasilania według odpowiedzialności.
• Ogranicz zakres. Awaria głównego switcha jest ważniejsza niż chwilowe odłączenie urządzenia używanego sporadycznie.
• Używaj harmonogramów. Zdarzenie normalne w godzinach pracy może wymagać reakcji, gdy wystąpi w nocy.
• Ogranicz powtórzenia. Funkcja Ignore Repeated Alarms pomaga uniknąć serii wiadomości wynikających z jednego niestabilnego elementu.
• Regularnie testuj cały łańcuch. Sam zapis reguły nie potwierdza, że aplikacja mobilna, skrzynka email, webhook albo system zewnętrzny rzeczywiście odbiera alarm.

Prosty zestaw alarmów na początek

Zamiast włączać dziesiątki reguł, lepiej rozpocząć od kilku sytuacji mających realny wpływ na działanie sieci. Dokładne nazwy zdarzeń mogą zależeć od wersji aplikacji i urządzeń, ale praktyczny zestaw startowy może obejmować:

• Niedostępność połączenia WAN, wysyłaną przez push do osób reagujących na awarie internetu.
• Przejście kluczowego urządzenia w tryb offline, z zakresem ograniczonym do gatewaya, głównych switchy i ważnych punktów dostępowych.
• Problem z PoE lub zasilaniem, szczególnie na switchach obsługujących kamery i punkty dostępowe.
• Wykrycie zagrożenia albo zdarzenie honeypota, kierowane do osoby odpowiedzialnej za bezpieczeństwo.
• Zmianę konfiguracji przez administratora, przekazywaną do emaila lub systemu przechowującego logi.

Po kilku tygodniach można sprawdzić, które alarmy faktycznie prowadziły do działania, które powtarzały się zbyt często i jakich informacji brakowało podczas diagnozy. Dopiero na tej podstawie należy rozszerzać zestaw reguł.

Checklista wdrożenia

Powiadomienie ma prowadzić do działania

UniFi dostarcza wszystkie elementy potrzebne do zbudowania prostego systemu powiadomień. Dziennik rejestruje zdarzenia, Alarm Manager wybiera sytuacje wymagające reakcji, a push, email i webhook dostarczają informację poza sam interfejs. SIEM, SNMP i API pozwalają rozszerzyć ten model o historię, korelację, własne progi oraz zarządzanie wieloma lokalizacjami.

Skuteczność nie zależy od liczby aktywnych reguł. Dobry alarm ma właściwy zakres, trafia do konkretnego odbiorcy i jasno wskazuje, że potrzebna jest reakcja. Kilka dobrze dobranych powiadomień daje więcej niż długa lista komunikatów, których nikt już nie czyta.

Źródła

• UniFi Alarm Manager, alerty, integracje i automatyzacje
• UniFi System Logs i integracja z SIEM
• SNMP Monitoring in UniFi Network
• Getting Started with the Official UniFi API

Stan funkcji i ścieżek w interfejsie zweryfikowany w lipcu 2026 roku.