Zammad i Zabbix: jak zamienić alert w zgłoszenie, które ktoś zamknie

Alert w mailu ma jedną wadę: nie da się na nim sprawdzić, czy ktoś się nim zajął. Leży w skrzynce, każdy zakłada, że zerknął kolega, i po trzech dniach okazuje się, że nie zerknął nikt. Zgłoszenie w systemie ticketowym rozwiązuje to jednym mechanizmem — ma status i ma właściciela.

Spięcie Zabbiksa z Zammadem sprowadza się do dwóch przepływów. Problem w Zabbiksie tworzy zgłoszenie. Ustąpienie problemu domyka je albo przynajmniej dopisuje do niego notatkę. Tyle w teorii. Cała robota siedzi w tym, żeby nie zalać zespołu ticketami.

Mechanika: webhook po jednej stronie, token po drugiej

W Zabbiksie definiuje się typ mediów jako webhook — kawałek kodu, który dostaje dane zdarzenia i wysyła je gdzie trzeba. Gotowego integratora Zammada w standardowym zestawie nie ma, więc pisze się własny: kilkadziesiąt linijek, które składają zapytanie do API Zammada. Ten typ mediów przypisuje się użytkownikowi technicznemu, a użytkownika wskazuje w akcji reagującej na problemy.

Po stronie Zammada są dwie drogi. Prostsza: kanał pocztowy, czyli alert idzie mailem na adres obsługiwany przez Zammada i sam zamienia się w zgłoszenie. Zero kodu, działa od ręki, ale traci się kontrolę nad polami i domykanie robi się kulawe. Druga droga to API z tokenem dostępu — konto techniczne, token o wąskich uprawnieniach, pełna kontrola nad tym, w jakiej grupie, z jakim priorytetem i z jakim klientem ląduje zgłoszenie. Robię drugą. Pierwsza jest dobra na jeden wieczór, żeby zobaczyć, czy pomysł ma sens.

Akcja w Zabbiksie ma trzy rodzaje operacji i wszystkie trzy są tu potrzebne: operacje przy wystąpieniu problemu (tworzenie zgłoszenia), operacje przy ustąpieniu problemu (domknięcie) i operacje przy aktualizacji zdarzenia (dopisanie notatki, gdy ktoś potwierdzi alert w Zabbiksie). Bez tej trzeciej dwa systemy szybko zaczynają opowiadać różne historie.

Jeden wątek zamiast czterech zgłoszeń

To miejsce, w którym większość integracji się sypie. Problem trwa, zmienia ważność, ktoś go potwierdza, potem ustępuje — i każde z tych zdarzeń tworzy nowe zgłoszenie. Po tygodniu kolejka wygląda jak rejestr zdarzeń, a nie lista zadań.

Rozwiązanie jest proste: identyfikator zdarzenia z Zabbiksa musi trafić do zgłoszenia i dać się później odnaleźć. Zabbix udostępnia go w makrze {EVENT.ID}, stabilnym przez całe życie problemu. Wrzucam go w tytuł zgłoszenia albo w dedykowane pole obiektu i przy każdym kolejnym wywołaniu webhooka najpierw pytam Zammada, czy zgłoszenie z tym identyfikatorem już istnieje. Istnieje — dopisuję artykuł do wątku. Nie istnieje — zakładam nowe.

Przy domykaniu ta sama logika, tylko z drobną decyzją do podjęcia: czy ustąpienie problemu ma od razu zamykać zgłoszenie, czy przestawiać je w stan oczekiwania na zamknięcie. U siebie robię to drugie dla incydentów krytycznych. Usługa wróciła, ale nikt jeszcze nie napisał, dlaczego padła — a ta notatka jest warta więcej niż samo zamknięcie.

Nie każdy alert zasługuje na zgłoszenie

Najważniejsza decyzja w całej integracji i jednocześnie najczęściej pomijana. Jeśli wszystko, co Zabbix uzna za problem, wpada do kolejki, zespół po dwóch tygodniach przestaje czytać kolejkę. Skończy się dokładnie tak, jak kończyło się z mailem, tylko w ładniejszym interfejsie.

Filtruję na trzech poziomach.

• Ważność. Zgłoszenia zakładam od poziomu ostrzegawczego wzwyż. Informacje i zdarzenia diagnostyczne zostają w Zabbiksie — są potrzebne przy analizie, nie przy pracy.
• Czy potrzebna jest decyzja człowieka. Alert, który zawsze kończy się tym samym działaniem, powinien to działanie wykonać sam, a nie prosić o nie w formie zgłoszenia. Zabbix potrafi uruchomić zdalne polecenie w ramach akcji.
• Trwałość. Skok obciążenia na trzy minuty nie jest incydentem. Zabbix pozwala odsunąć pierwszy krok akcji w czasie, więc zgłoszenie powstaje dopiero, gdy problem utrzymuje się dłużej niż ustalony próg. Ustąpił wcześniej — zespół nigdy się o nim nie dowiedział i dobrze.

Ten sam mechanizm rozwiązuje problem alertów migoczących: usługa, która co kwadrans odpada i wraca, przy poprawnie ustawionym opóźnieniu generuje jedno zgłoszenie zamiast trzydziestu. Sposób, w jaki Zabbix liczy warunki wystąpienia i ustąpienia problemu, rozbieram szczegółowo w tekście o działaniu alertów w Zabbiksie.

Mapowanie, czyli skąd zgłoszenie wie, czyje jest

Zgłoszenie utworzone automatycznie musi być użyteczne bez otwierania Zabbiksa. To znaczy trzy rzeczy.

Waga alertu na priorytet. Poziomy ważności Zabbiksa mapuję na priorytety Zammada — najwyższe na wysoki, ostrzeżenia na normalny, reszta niżej. Prosta tabela w kodzie webhooka. Bez niej wszystko wpada z priorytetem domyślnym i sortowanie kolejki traci sens.

Host na klienta i organizację. Jeśli obsługujesz kilka firm, to jest punkt, który decyduje o użyteczności całości. Grupy hostów w Zabbiksie odpowiadają organizacjom w Zammadzie, a webhook czyta grupę ze zdarzenia i podstawia właściwą organizację. Nagle działa filtrowanie po kliencie, liczenie incydentów na klienta i rozliczanie czasu.

Treść na sensowny tytuł. „Problem on host-01” to nie tytuł, tylko rezygnacja. Tytuł powinien składać się z nazwy hosta, opisu problemu i wartości, która go wywołała — coś w rodzaju „srv-plik: zajętość dysku 94 procent (próg 90)”. Wszystkie te dane Zabbix ma w makrach zdarzenia. W treści zgłoszenia dorzucam ostatnie wartości metryki i odnośnik do zdarzenia w Zabbiksie, żeby dyżurny nie musiał go szukać.

Lawina, czyli co się dzieje, gdy padnie łącze

Pada przełącznik albo łącze i dwieście hostów jednocześnie przestaje odpowiadać. Bez zabezpieczeń dostajesz dwieście zgłoszeń w minutę, Zammad wysyła dwieście powiadomień, a prawdziwa przyczyna ginie gdzieś między nimi. Widziałem kolejkę, która po takim zdarzeniu wymagała ręcznego czyszczenia przez pół dnia.

Cztery rzeczy, które to powstrzymują:

• Zależności między wyzwalaczami. Niedostępność serwera zależna od niedostępności przełącznika, do którego jest podpięty. Padnie przełącznik — pozostałe alerty są tłumione, powstaje jedno zgłoszenie o właściwej przyczynie. To najskuteczniejsze narzędzie z całej listy i jednocześnie najbardziej pracochłonne, bo wymaga opisania topologii sieci.
• Okna serwisowe. Planowany restart klastra ma być zdefiniowany jako konserwacja z wstrzymaniem operacji. Inaczej każda aktualizacja kończy się falą ticketów.
• Limit tempa po stronie webhooka. Prosty licznik: więcej niż X zgłoszeń w minutę i skrypt przestaje zakładać nowe, a zamiast tego dokłada wpisy do jednego zbiorczego. Zabezpieczenie ostatniej szansy, ale ratowało mi kolejkę.
• Kontrola pętli. Jeśli Zammad odsyła powiadomienia na adres, który monitoruje Zabbix, albo webhook reaguje na własne zdarzenia, dostajesz sprzężenie zwrotne. Konto techniczne integracji musi być wyłączone z reguł powiadamiania w Zammadzie — to jedna z pierwszych rzeczy, które sprawdzam.

Co z tego ma zespół

Sama automatyzacja nie jest celem. Celem jest to, co pojawia się dopiero wtedy, gdy każdy incydent ma swój rekord.

Po pierwsze, czasy. Zammad liczy SLA i pokazuje, ile minęło od utworzenia do pierwszej reakcji i do zamknięcia. Przy alertach mailowych ta liczba nie istnieje — nikt nie wie, kiedy ktoś zauważył problem. Po drugie, historia hosta. Za pół roku widać, że ten sam serwer zgłaszał się jedenaście razy z tym samym objawem, co jest argumentem za wymianą dysku, a nie za kolejnym restartem. Po trzecie, raport miesięczny: ile incydentów, jakiej wagi, jak szybko zamknięte, u którego klienta. To jedyny znany mi sposób, żeby rozmowa o kosztach IT przestała opierać się na wrażeniach.

Dochodzi jeszcze kwestia dostępu. Jeśli Zammad ma już podpięte logowanie przez SSO, konto integracji zostaje kontem lokalnym z tokenem — nie powinno zależeć od dostawcy tożsamości, bo awaria logowania nie może zatrzymać wpadania zgłoszeń.

Alert mówi, że coś się stało. Zgłoszenie mówi, kto się tym zajmuje i od kiedy. Dopiero to drugie da się rozliczyć.

Od czego zacząć

Nie od kodu. Od decyzji, które alerty w ogóle mają stawać się zgłoszeniami — zwykle wychodzi z tego krótsza lista, niż ktokolwiek się spodziewa. Potem konto techniczne i token w Zammadzie, potem webhook dla jednej grupy hostów w trybie próbnym. Tydzień obserwacji, korekta filtrów, dopiero potem reszta infrastruktury.

Jeśli systemu zgłoszeń jeszcze nie ma, integracja jest krokiem drugim, nie pierwszym — od czego zacząć wdrożenie samego Zammada, opisuję w osobnym tekście. A jeśli monitoring dopiero powstaje, warto wiedzieć, że ta integracja jest właśnie odpowiedzią na sytuację, w której o awarii dowiadujesz się ostatni.