Kontroler UniFi ma dobry interfejs. Naprawdę dobry - wykresy są czytelne, topologia ładna, a lista klientów robi wrażenie podczas prezentacji u klienta. Mimo to obok niego postawiłem własny dashboard i zaglądam do niego codziennie częściej niż do oryginału.
Ten wpis nie jest o tym, że mój panel jest lepszy, bo nie jest. Jest o czterech brakach, które w codziennym administrowaniu siecią realnie bolą, i o kilku wnioskach na temat monitoringu, które wychodzą dopiero wtedy, gdy człowiek sam spróbuje taki system zbudować. Wnioski są uniwersalne - dotyczą każdego monitoringu, niezależnie od producenta sprzętu i użytej technologii.
Czego brakuje w panelu producenta
1. Alertu, który naprawdę dociera. Kontroler potrafi wysłać maila. Mail trafia do folderu z regułą „UniFi”, w którym leży już dwieście innych. Powiadomienie, którego nikt nie przeczyta w ciągu pięciu minut, nie jest alertem - jest wpisem do archiwum. Potrzebowałem czegoś, co ląduje na telefonie i już na poziomie kanału rozdziela to, co wymaga reakcji natychmiast, od tego, co spokojnie poczeka do rana.
2. Widoczności łącza zapasowego wtedy, kiedy ono leży. To paradoks większości paneli: pokazują łącza, które działają. Łącze zapasowe w stanie „down” po prostu nie istnieje w interfejsie - a to jest dokładnie ten stan, o którym chcę wiedzieć. Dowiedzieć się o martwym backupie w chwili, gdy pada łącze główne, to najgorszy możliwy moment.
3. Własnej historii i własnych progów. Panel producenta trzyma dane tyle, ile trzyma, i o zdanie nie pyta. Ja chcę móc powiedzieć: transfer WAN przechowuj rok, zdarzenia bezpieczeństwa trzydzieści dni, a o zmianie stanu tego jednego serwera powiadom mnie zawsze i o każdej porze.
4. Jednej szyby. Sieć w jednym systemie, kamery w drugim, a serwer, NAS i drukarka - nigdzie, bo kontroler traktuje je wyłącznie jako klientów DHCP. Potrzebowałem ekranu, który odpowiada na pytanie „czy wszystko działa”, obejmującego także sprzęt, o którego istnieniu kontroler nie ma pojęcia.
Sedno: panel producenta jest zbudowany po to, żeby pokazać stan jego urządzeń. Monitoring w firmie ma odpowiadać na pytanie, czy działa usługa - a ta prawie nigdy nie kończy się na sprzęcie jednego producenta.
Cztery wnioski o monitoringu
1. Zero to nie to samo co błąd
Najniebezpieczniejsza awaria monitoringu nie polega na tym, że system przestaje działać. Polega na tym, że działa dalej i pokazuje wartości, tyle że nieprawdziwe. Wykres się odświeża, kolory się zgadzają, a linia leży na zerze, bo w tle nie udało się pobrać danych.
Człowiek patrzy na taki ekran i wyciąga wniosek „mały ruch”, zamiast „nie mam danych”. Dlatego brak odczytu musi wyglądać inaczej niż odczyt zerowy - to dwie zupełnie różne informacje i nigdy nie powinny mieć tej samej reprezentacji na wykresie.
Monitoring, który przy nieznanym sprzęcie pokazuje zero zamiast błędu, jest gorszy niż brak monitoringu. Brak monitoringu przynajmniej nikogo nie uspokaja.
2. Filtrowanie „tylko aktywne” ukrywa dokładnie to, czego pilnujesz
Pokazywanie wyłącznie tego, co działa, jest odruchem projektanta interfejsu - po co zaśmiecać widok martwym wpisem. W monitoringu ten odruch jest błędem, bo element, który zniknął z listy, przestaje istnieć także w głowie administratora.
Zapasowe łącze, wyłączony czujnik, kamera bez zasilania: to wszystko są rzeczy, których nieobecność jest informacją. Zdrowa zasada brzmi: obiekt raz wzięty pod nadzór nigdy nie znika z widoku, zmienia tylko stan. Podobnie ze statusem zbiorczym - „wszystko OK” musi wynikać z tego, że coś faktycznie żyje, a nie z tego, że lista nie jest pusta.
3. Nazwa pola w API to nie jest jego znaczenie
Każde API sprzętowe ma pola, których nazwa sugeruje jedno, a zawartość znaczy co innego: prędkość wynegocjowanego łącza wygląda identycznie jak bieżący transfer, licznik od startu urządzenia jak licznik z ostatniej godziny, a jednostki potrafią się różnić między dwoma polami tego samego zapytania.
To nie jest błąd producenta, tylko rzeczywistość integracji. Skutek bywa jednak mylący dla użytkownika: bezczynny telefon leżący na stole potrafi wylądować na szczycie listy największych konsumentów pasma, bo raportowana wartość opisuje jakość jego połączenia, a nie ruch, który generuje.
Praktyczny wniosek: przy każdej wartości, którą pokazujesz, warto wiedzieć za jaki okres ona jest i w jakiej jednostce. Bez tych dwóch informacji liczba na dashboardzie jest ozdobą, nie danymi.
4. Alert po dwóch cyklach, nie po jednym
Pierwsza wersja alertu o padniętym łączu wysyłała powiadomienie przy pierwszym nieudanym odczycie. Przez tydzień dostawałem wiadomości o awariach, których nie było - chwilowa renegocjacja łącza albo timeout zapytania wyglądały dokładnie tak samo jak realna awaria.
Poprawka sprowadza się do dwóch zasad. Po pierwsze: powiadamiaj dopiero, gdy stan utrzyma się przez dwa kolejne cykle. Po drugie i ważniejsze: brak odpowiedzi nie zmienia stanu. Brak danych to brak wiedzy, a nie informacja o awarii. Mylenie tych dwóch rzeczy to najprostszy sposób na to, żeby po miesiącu wszyscy zaczęli ignorować powiadomienia - a wtedy monitoring formalnie działa i praktycznie nie istnieje.
Z tej samej rodziny jest raport dobowy. Zestawienie „co się działo przez ostatnią dobę” buduję z własnej, lokalnej historii, a nie odpytując w tym momencie kontrolera. Powód jest przewrotny: raport ma dotrzeć także wtedy, gdy monitorowany system leży. Wtedy jest najbardziej potrzebny, a jednocześnie nie ma go kogo zapytać.
Co z tego ma firma
Ta historia nie jest o UniFi ani o konkretnym narzędziu. Jest o tym, że monitoring to nie wykres, tylko odpowiedź na dwa pytania: czy to działa i od kiedy nie działa. Panel producenta odpowiada na pierwsze, i to wyłącznie dla własnego sprzętu. Drugie wymaga własnej historii, własnych progów i kanału powiadomień, który ktoś realnie czyta.
Jeśli patrzysz na temat od strony wymagań regulacyjnych, pisaliśmy osobno o tym, jak nie pomylić trzech różnych systemów monitoringu pod NIS2 i DORA - bo „mamy monitoring” znaczy tam coś zupełnie innego niż wykres na ścianie.
Sam projekt, MiniDash, rozwijam jako otwarte oprogramowanie i kod jest dostępny na GitHubie. Jeśli masz sieć na UniFi i chcesz, żeby monitoring realnie odzywał się wtedy, kiedy trzeba - a nie po fakcie - tym zajmujemy się w ramach administracji siecią.
W kolejnym wpisie druga połowa tej układanki: kanał powiadomień. Czyli dlaczego alerty wysyłam na Telegram zamiast na maila i jakie pułapki kryje coś tak z pozoru banalnego jak wiadomość od bota.
