Większość firmowych dashboardów to ozdoba. Dwadzieścia paneli, ładne kolory, ktoś złożył je w tygodniu wdrożenia i od tamtej pory nikt tam nie zagląda. Dobra tablica poznaje się po jednym: ktoś otwiera ją z własnej woli, bo szybciej odpowiada na pytanie niż logowanie się na serwer.
Kto zbiera, kto pokazuje
Zabbix i Grafana nie konkurują ze sobą — robią dwie różne rzeczy. Zabbix zbiera dane, trzyma historię, liczy wyzwalacze i wysyła powiadomienia. Grafana nie monitoruje niczego. Grafana rysuje. Podpina się do źródeł danych i pokazuje to, co ktoś inny zebrał. Wtyczka Zabbiksa do Grafany robi dokładnie to: udostępnia elementy, wyzwalacze i historię z Zabbiksa jako źródło dla paneli. Szersze porównanie obu narzędzi z Prometheusem i Nagiosem opisałem w tekście o wyborze systemu monitoringu.
Konsekwencja jest praktyczna. Padnie Grafana — monitoring dalej działa, alerty dalej lecą. Padnie Zabbix — Grafana pokazuje pustą planszę i nikt się o niczym nie dowie. Kolejność wdrożenia wynika z tego sama.
Kiedy sam Zabbix wystarczy — a wystarcza częściej, niż się mówi
Przy jednym środowisku i jednym źródle danych Grafana jest zbędna. Wbudowane tablice Zabbiksa mają widżet aktywnych problemów, wykresy, zestawienie najbardziej obciążonych hostów, mapę sieci i pojedyncze wartości z progami kolorystycznymi. To pokrywa większość potrzeb małej firmy. Dokładanie Grafany oznacza kolejną usługę do aktualizowania, kolejne logowanie i kolejne miejsce, w którym coś się rozjedzie po aktualizacji wtyczki.
Grafanę dokładam, gdy pojawia się jeden z tych powodów:
- Danych jest z kilku źródeł — Zabbix plus baza aplikacji, plus rachunki z chmury, plus coś z logów — i mają być na jednym ekranie.
- Tablica ma wisieć na telewizorze w biurze i po prostu musi dobrze wyglądać.
- Odbiorcą jest ktoś spoza IT i potrzebny jest widok bez żargonu, z podpisami po polsku.
- Trzeba liczyć na metrykach coś własnego, czego wbudowany wykres nie zrobi.
Żaden nie pasuje? Oszczędź sobie roboty.
Trzy tablice, trzej odbiorcy
Uniwersalna tablica nie istnieje. Próba zrobienia jednej dla wszystkich kończy się ekranem, na którym każdy widzi 80 procent rzeczy, które go nie obchodzą. U siebie i u klientów robię trzy osobne — każdą pod inne pytanie.
Tablica dyżurna: czy coś się pali
Pytanie brzmi: mam się teraz czymś zająć, tak czy nie. Odpowiedź musi być widoczna z drugiego końca pokoju. Na tej tablicy jest lista aktywnych problemów posortowana po ważności, kafelek stanu kluczowych usług — poczta, ERP, strona, VPN — i licznik alertów niepotwierdzonych. Nic więcej. Bez wykresów, bez historii, bez procentów.
Kluczowa zasada: pusty ekran ma znaczyć „wszystko gra”. Jeśli w stanie normalnym coś na nim mruga, po tygodniu przestanie być zauważane. To ta sama logika, którą opisuję przy konfiguracji alertów — sygnał traci wartość, gdy jest ciągły.
Tablica infrastruktury: dla administratora
Tu jest miejsce na liczby. CPU, RAM, zajętość dysków, opóźnienia operacji dyskowych, obciążenie systemu, ruch na interfejsach. Ale nie jako 30 osobnych wykresów — jako zestawienia z sortowaniem: dziesięć hostów z najwyższym obciążeniem, dziesięć wolumenów z najmniejszą ilością wolnego miejsca. Sortowanie robi za mnie robotę, której inaczej muszę szukać wzrokiem.
Dokładam do tego dwie rzeczy, których większość tablic nie ma. Trend tygodniowy obok wartości bieżącej — bo 70 procent zajętego dysku znaczy coś zupełnie innego, gdy tydzień temu było 68, a co innego, gdy było 40. I prognozę: Zabbix ma funkcje wyliczające przewidywany czas do zapełnienia zasobu na podstawie trendu, i to właśnie ta liczba — „miejsce skończy się za 11 dni” — powoduje, że ktoś reaguje wcześniej. Sam wykres rosnącej krzywej nie powoduje niczego.
Tablica dla właściciela firmy
Najtrudniejsza z trzech, bo wymaga porzucenia języka technicznego. Właściciela nie interesuje obciążenie węzła. Interesuje go, czy firma mogła pracować. Więc: dostępność kluczowych usług w procentach za bieżący miesiąc, liczba incydentów w podziale na krytyczne i drobne, mediana czasu od wykrycia do zamknięcia, lista trzech ostatnich zdarzeń opisana zdaniem po polsku. Zabbix ma wbudowany moduł usług i raportów SLA, który liczy to bez ręcznego dłubania.
Ta tablica ma jeden dodatkowy cel, o którym się głośno nie mówi: pokazuje, że monitoring na coś idzie. Bez niej wydatek na wdrożenie monitoringu wygląda jak koszt, który nic nie zwraca.
Pięć zasad, które oszczędzają najwięcej czasu
- Bez przewijania. Tyle paneli, ile mieści się na ekranie. Co jest poniżej zgięcia, tego nikt nie ogląda.
- Kolor znaczy stan, nie kategorię. Czerwony to problem. Nie „dział handlowy”. Jeśli kolory rozróżniają serie na wykresie, to na tej samej tablicy nie mogą już oznaczać alarmu.
- Wartość bezwzględna obok procentu. „Dysk 85 procent” nie mówi nic. „85 procent, wolne 44 GB” mówi wszystko.
- Każdy wykres z linią odniesienia. Wykres bez zaznaczonego progu to obrazek. Z progiem to informacja.
- Jedno pytanie na panel. Jeśli nie umiesz powiedzieć, na jakie pytanie panel odpowiada, usuń go.
Pułapki, które widzę najczęściej
Dashboard zamiast alertów. Najkosztowniejszy błąd. Ładna tablica daje poczucie kontroli, więc firma odkłada konfigurację powiadomień. Tymczasem nikt nie patrzy na ekran o 2 w nocy ani w niedzielę. Tablica służy do diagnozy, gdy już wiadomo, że coś jest nie tak. Do dowiadywania się, że jest nie tak, służy alert. To dwie różne funkcje i jedna nie zastępuje drugiej — o czym pisałem szerzej przy okazji tego, dlaczego o awarii dowiadujemy się ostatni.
Za krótkie okno danych. Domyślna godzina na wykresie pokazuje szum. Sensowny podgląd operacyjny to 24 godziny albo 7 dni — dopiero na tym widać, czy skok zdarza się codziennie o tej samej porze, czy naprawdę jest wyjątkiem.
Uśrednianie, które ukrywa skoki. Przy dłuższym oknie system agreguje punkty. Minutowy skok CPU do 100 procent w średniej godzinowej wygląda jak 40 procent. Tam, gdzie ważne są szczyty — czasy odpowiedzi, opóźnienia dysku — pokazuj wartość maksymalną albo maksimum obok średniej. Inaczej zobaczysz spokojny wykres i użytkowników skarżących się, że system muli.
Gotowiec pobrany z internetu. Kusi, bo ma czterdzieści paneli i wygląda profesjonalnie. Problem w tym, że został zrobiony pod czyjeś środowisko, czyjeś nazwy elementów i czyjeś progi. Połowa paneli świeci pustką, druga połowa pokazuje metryki, o których nikt w firmie nie ma zdania. Traktuję takie tablice jako źródło pomysłów, nigdy jako punkt startu — szybciej jest zbudować sześć własnych paneli niż naprawić czterdzieści cudzych.
Panele bez właściciela. Panel, którego nikt nie zamawiał, nie ma komu zgłosić, że przestał działać. Przy każdym nowym pytam wprost, kto go będzie otwierał i jak często. Odpowiedź „no wszyscy” znaczy, że nikt.
Jak to utrzymać, żeby po pół roku nadal miało sens
Tablice gniją. Host znika, element się zmienia, panel pokazuje pustkę i wszyscy się do tej pustki przyzwyczajają. Trzy nawyki, które to powstrzymują.
Po pierwsze: buduj panele na grupach hostów i szablonach, nie na pojedynczych maszynach. Nowy serwer wpada wtedy na tablicę sam, bo wystarczy, że trafi do właściwej grupy przy wdrożeniu agenta. Po drugie: raz na kwartał przejdź tablicę panel po panelu i zadaj jedno pytanie — czy ktoś podjął w tym kwartale decyzję na podstawie tego panelu. Nie podjął, panel wypada. Po trzecie: pusty panel traktuj jak awarię, nie jak kosmetykę. Brak danych zwykle znaczy, że coś przestało być zbierane — a to poważniejsze niż brzydki wykres.
Tablica, która nie zmienia niczyjej decyzji, to wygaszacz ekranu z metrykami.
Praktyczna kolejność: najpierw ustal, co w ogóle monitorujesz, potem alerty, dopiero na końcu tablice. Odwrotna kolejność kończy się ładnym ekranem, który nikogo nie obudzi.