Żeby ograniczyć fałszywe alerty w monitorowaniu dostępności, potwierdzaj każdą awarię drugim testem przed wysłaniem alertu, ustaw limity czasu zgodne z tym, jak Twoja strona zwykle się zachowuje, sprawdzaj oczekiwany kod statusu i treść pod adresem URL, który naprawdę odzwierciedla działanie usługi, kieruj alerty każdego monitora tylko do osób, które mogą coś z nimi zrobić, planowane prace umieszczaj w oknie serwisowym i zapowiadaj je, a co miesiąc przeglądaj najbardziej hałaśliwe monitory. Większość fałszywych alertów pochodzi z kilku monitorów, w których jedno z tych ustawień jest błędne, więc poprawka zwykle zajmuje chwilę.
Ten poradnik wyjaśnia, dlaczego fałszywe alerty są groźne, skąd się biorą i co zmienić – ustawienie po ustawieniu.
Dlaczego fałszywe alerty są gorsze, niż się wydaje
Jeden fałszywy alert to drobna irytacja. Ciągły strumień takich alertów to zmęczenie alertami (alert fatigue): ludzie wyciszają kanał, filtrują e-maile do folderu albo zerkają na telefon i śpią dalej. Monitoring nadal działa, ale nikt go nie słucha. Pierwszą prawdziwą awarię po tym momencie wykrywa się po staremu – zgłasza ją klient.
Jest też mniej widoczny koszt. Każdy fałszywy alert odrywa kogoś od pracy, żeby sprawdził stronę, która działa bez zarzutu. W skali miesiąca to godziny straconego skupienia i zespół, który mniej ufa swoim narzędziom. Celem nie jest mniej alertów samo w sobie, tylko alerty, które za każdym razem warto przeczytać.
Skąd biorą się fałszywe alerty
Chwilowe problemy z siecią między lokalizacją testującą a Twoim serwerem: zgubiony pakiet, wolna trasa, krótka czkawka DNS.
Zbyt krótkie limity czasu dla strony, która bywa wolna, ale działa.
Złe oczekiwania: test, który oczekuje statusu 200 od adresu URL z przekierowaniem albo szuka tekstu zmienionego przy redesignie.
Zły adres URL: strona za limitem żądań, ochroną przed botami albo logowaniem, czy serwer stagingowy wyłączany na noc.
Planowane prace: wdrożenia i prace serwisowe, które celowo wyłączają stronę.
Złe kierowanie: alert technicznie poprawny, ale wysłany do kogoś, kto nic nie może z nim zrobić. Dla tej osoby to szum.
Potwierdzaj każdą awarię drugim testem
To najskuteczniejsza pojedyncza poprawka. Gdy test się nie powiedzie, sprawdź ponownie, zanim zrobisz cokolwiek innego. Zgubiony pakiet czy krótka czkawka przechodzą drugi test, a prawdziwa awaria nie. Incydent otwiera tylko potwierdzona awaria. Eliminuje to większość chwilowych zakłóceń, a prawdziwe alerty opóźnia najwyżej o kilka sekund.
Usługi, które testują z kilku lokalizacji, mogą wykonać drugi test z innego miejsca, co daje też cenną wskazówkę, gdy lokalizacje dłużej się ze sobą nie zgadzają. Jeśli strona nie działa z jednego kontynentu, a działa z innego, problem leży raczej w routingu albo w węźle CDN niż w Twoim serwerze. Uptimecheck testuje ze Sztokholmu, Londynu i Nowego Jorku i potwierdza każdą awarię z drugiej lokalizacji, zanim otworzy incydent, więc pojedyncze zakłócenie nikogo nie budzi. Strona monitorowania dostępności wyjaśnia, jak to działa. Podstawy tego, jak testy zamieniają się w alerty, znajdziesz w artykule czym jest monitorowanie dostępności.
Ustaw realistyczne limity czasu
Limit czasu (timeout) to czas, przez jaki test czeka, zanim uzna stronę za niedostępną. Ustawiony zbyt krótko zamienia normalne wahania w awarię. Ustawiony zbyt długo sprawia, że strona, która odpowiada po 40 sekundach, liczy się jako działająca.
Przejrzyj historię czasów odpowiedzi z kilku tygodni. Zanotuj normalny zakres i najwolniejsze normalne odpowiedzi.
Ustaw limit wyraźnie powyżej najwolniejszej normalnej odpowiedzi, ale poniżej punktu, w którym odwiedzający rezygnują.
Traktuj spowolnienie jako osobny sygnał. Strona, która zwolniła z 300 ms do 4 sekund, wymaga uwagi, ale w godzinach pracy, a nie jako nocny alert o awarii.
Jeśli strona regularnie zbliża się do limitu czasu, problemem nie jest monitor, tylko strona.
Oczekuj właściwego kodu statusu i treści
Wiele fałszywych alertów pochodzi z testów, które oczekują czegoś innego, niż powinny:
Przekierowania. Monitorowanie http://northwind.shop, gdy strona przekierowuje na https://www.northwind.shop/, dodaje krok, który może zawieść sam z siebie. Monitoruj bezpośrednio docelowy adres URL, a jeśli chcesz sprawdzać przekierowanie, daj mu osobny monitor.
Kruche testy treści. Sprawdzanie marketingowego nagłówka przestanie działać przy następnej zmianie tekstu. Wybierz coś stałego, co pojawia się tylko wtedy, gdy strona działa, np. nazwę firmy w stopce, element siatki produktów albo „status”:”ok” z endpointu health check.
Zbyt szeroko. Akceptowanie dowolnego kodu 2xx lub 3xx ukrywa prawdziwe awarie. Akceptowanie wyłącznie 200 od endpointu, który prawidłowo zwraca 204, tworzy fałszywe. Dopasuj się do tego, co endpoint faktycznie zwraca.
Weryfikacja treści ogranicza jednocześnie fałszywe i przeoczone alerty: strona błędu proxy, która zwraca 200, nie przejdzie testu, a kosmetyczna zmiana nie wywoła alertu.
Monitoruj właściwy adres URL
Niektóre adresy URL z natury słabo nadają się do monitorowania. Strony za ochroną przed botami albo zaporą aplikacji webowej (WAF) mogą od czasu do czasu blokować ruch monitoringu, co wygląda jak przestój. Strony z mocnym limitem żądań mogą zwracać 429 po serii testów. Strony chronione logowaniem zwracają przekierowanie do formularza logowania. A strona główna jest często tak mocno cache’owana, że działa, nawet gdy wszystko za nią leży.
Dedykowany endpoint health check pozwala uniknąć tego wszystkiego. Nie jest cache’owany, jest tani w obsłudze, zwraca przewidywalną treść i zawodzi tylko wtedy, gdy zawodzi któraś zależność. Zobacz, jak zbudować endpoint health check. Jeśli musisz monitorować stronę za ochroną, przepuść ruch usługi monitorującej i wysyłaj rozpoznawalny nagłówek user agent, żeby łatwo było go zidentyfikować.
Kieruj alerty osobno dla każdego monitora
Alert przydaje się tylko komuś, kto może na niego zareagować. Wysyłanie każdego monitora do wszystkich zamienia prawdziwe alerty w szum dla większości odbiorców. Zamiast tego kieruj je według wpływu i odpowiedzialności:
Monitor (przykład)KanałKtoKoszyk i callback płatnościPowiadomienie push i czat zespołuOsoba dyżurnaEndpoint health check publicznego APICzat zespołu i webhookZespół platformyStrona marketingowa i blogE-mailZespół webowy, w godzinach pracyStaging i narzędzia wewnętrzneOsobny kanał na czacieIch właściciel
W Uptimecheck kanały alertów wybierasz dla każdego monitora. Alerty trafiają na e-mail, do Slacka, Microsoft Teams, Discorda, Google Chat, Mattermost, Telegrama, PagerDuty, ntfy, Pushovera, na webhooki i jako powiadomienia push na telefon, w każdym planie. Zobacz alerty i powiadomienia. Dzięki grafikom dyżurów alerty push trafiają do osoby, która ma dyżur w danej chwili, a eskalacja może wstrzymać kanał na 5 do 60 minut i wysłać alert tylko wtedy, gdy nikt nie potwierdził incydentu. Agencje mogą grupować monitory w projekty klientów i wybierać kanały dla każdego monitora, dzięki czemu alerty każdego klienta trafiają do zespołu, który się nim opiekuje.
Planowane prace serwisowe
Planowany przestój nigdy nie powinien nikogo budzić. Przed migracją albo długim wdrożeniem umieść monitory, których to dotyczy, w oknie serwisowym. Jeśli Twoje narzędzie go nie ma, wstrzymaj je albo na ten czas przenieś ich alerty na cichy kanał, a wznowienie monitoringu wpisz jako punkt listy kontrolnej wdrożenia.
W Uptimecheck okna serwisowe mogą być jednorazowe albo cykliczne. W trakcie okna nie ma alertów, incydentów ani utraty dostępności, a okno jest widoczne na stronie statusu i może zostać wysłane e-mailem do subskrybentów.
Poinformuj też klientów. Notka na stronie statusu przed pracami, z przedziałem czasu i zakresem zmian, sprawia, że nikt nie jest zaskoczony, a support nie dostaje zgłoszeń o czymś, co zaplanowałeś. Wdrożenia, które za każdym razem powodują kilka sekund błędów, to osobny problem: rozwiąż go wdrożeniami stopniowymi (rolling) albo bez przestoju (zero-downtime), a nie ignorowaniem alertów.
Korzystaj z powiadomień o przywróceniu
Powiadomienie o przywróceniu to alert, który mówi, że jest już po wszystkim, i podaje łączny czas przestoju. Nie zmniejsza liczby alertów, ale zmniejsza pracę, jaką każdy z nich generuje. Bez niego ktoś musi sprawdzać, czy krótka awaria już minęła. Z nim dwuminutowe zakłócenie w nocy to jeden alert i jedno „wszystko w porządku”, które może poczekać do rana. Uptimecheck wysyła powiadomienie o przywróceniu po każdym incydencie.
Przeglądaj najbardziej hałaśliwe monitory
Raz w miesiącu spisz monitory, które wysłały najwięcej alertów, i zadaj o każdym te pytania:
Czy każdy alert był prawdziwy? Jeśli nie, które ustawienie go spowodowało: lokalizacja, limit czasu, oczekiwanie czy adres URL?
Czy ktoś zareagował? Jeśli nigdy nikt nie reaguje, zmień kierowanie albo usuń monitor.
Czy sama strona jest niestabilna? Częste, krótkie, prawdziwe awarie to nie fałszywe alerty. Wskazują na przeciążony serwer albo słabą zależność, a progi alertów serwera pomogą Ci znaleźć przyczynę.
Czy monitor jest jeszcze potrzebny? Wycofane strony i stare serwery stagingowe to częste źródło szumu.
Cotygodniowe i comiesięczne raporty e-mail z podsumowaniem dostępności i incydentów sprawiają, że taki przegląd zajmuje chwilę.
Lista kontrolna: fałszywe alerty
Potwierdzaj każdą awarię drugim testem przed wysłaniem alertu.
Ustawiaj limity czasu na podstawie rzeczywistej historii czasów odpowiedzi.
Monitoruj docelowe adresy URL, a nie przekierowania, i weryfikuj stałą treść.
Wybieraj endpointy health check zamiast stron cache’owanych lub chronionych.
Kieruj każdy monitor do osób, które mogą zareagować.
Planowane prace umieszczaj w oknie serwisowym i je zapowiadaj.
Co miesiąc przeglądaj najbardziej hałaśliwe monitory.
Podsumowanie
Fałszywe alerty to problem konfiguracji i większość z nich da się naprawić w jedno popołudnie. Potwierdzaj każdą awarię drugim testem, sprawdzaj właściwy adres URL pod kątem właściwych rzeczy, wysyłaj alerty tylko tam, gdzie ktoś może na nie zareagować, i regularnie wszystko przeglądaj. Nagrodą jest zespół, który czyta każdy alert, bo każdy alert ma znaczenie.
Uptimecheck sprawdza każdą awarię ponownie, zanim wyśle alert, i pozwala kierować alerty osobno dla każdego monitora. Rozpocznij 14-dniowy darmowy okres próbny, bez karty kredytowej.