Głośna strona z błędem jest irytująca. Awaria, która nie zostawia żadnego sygnału, to ta, która kosztuje Cię klienta, bo dowiadujesz się o niej po nim.
Uszereguj swoje najgorsze incydenty produkcyjne według tego, jak się o nich dowiedziałeś, nie według tego, jak bardzo bolały. Spora część okaże się być rzeczami, które wypłynęły ze zgłoszenia od klienta, albo które założyciel zauważył przypadkiem, patrząc na coś zupełnie innego. Wspólnym mianownikiem zwykle nie jest to, że awaria była subtelna. Jest to, że nic w stosie nie pilnowało braku czegoś, tylko obecności błędu.
Zadanie, które przestaje działać bez słowa skargi. Zadanie cron, które działało co noc, po aktualizacji zależności zaczyna po cichu kończyć się bez błędu, bo zmieniła się ścieżka do pliku. Brak wyjątku, brak niezerowego kodu wyjścia; skrypt po prostu nic nie robi i zwraca 0. Alerty oparte na logach nie mają czego grepować, bo nie ma linii błędu do dopasowania. Jedyny sposób, żeby to złapać, to oczekiwać sygnału w określonym harmonogramie i alarmować, gdy się nie pojawi, co jest zasadniczo innym rodzajem checka niż “czy to żądanie się powiodło”.
Certyfikat, który wygasa w spokojną sobotę. Auto-odnawianie działało bez zarzutu przez osiemnaście miesięcy, więc nikt o nim nie myśli, dopóki zmiana w DNS nie zepsuje wyzwania ACME, a odnawianie zaczyna zawodzić na tygodnie przed tym, zanim ktokolwiek to zauważy, bo sama ta awaria też jest cicha, chyba że coś konkretnie pilnuje daty wygaśnięcia, a nie tylko odpytuje endpoint. Strona odpowiada 200 aż do godziny, w której stary certyfikat traci ważność.
Endpoint, który działa, ale źle. Health check trafia w /health i dostaje 200 z powrotem, bo proces żyje. Tymczasem funkcja, na której użytkownikom faktycznie zależy, zwraca błędy, bo health check mówi Ci, że proces się nie wywalił, a nie że produkt działa. To jest luka między “serwer stoi” a “to, co ludzie próbują zrobić, faktycznie się dzieje”, i jest wystarczająco szeroka, żeby przejechał przez nią naprawdę wstydliwy incydent.
Standardowy monitoring logów opiera się na dopasowywaniu wzorców: pilnuj ERROR, pilnuj stack trace’a, pilnuj skoku odpowiedzi 5xx. To działa, gdy awaria produkuje jakiś ślad. Wszystkie trzy powyższe przypadki są awariami właśnie dlatego, że go nie produkują. Alert oparty na grepowaniu może zareagować tylko na to, co zostało zapisane; nie ma sposobu, żeby zauważyć, co powinno zostać zapisane, a nie zostało.
Rozwiązaniem nie jest sprytniejszy grep. Jest nim inny rodzaj checka, który oczekuje sygnału w określonym harmonogramie (ping, data wygaśnięcia certyfikatu, konkretna asercja na treści odpowiedzi) i traktuje brak tego sygnału jako alert, zamiast czekać na błąd, którego te scenariusze awarii nigdy nie produkują.
Dla zaginionego zadania: monitor, który oczekuje pary run/complete w znanym oknie czasowym, z okresem tolerancji dla zadań o zmiennym czasie trwania, i traktuje pominięte okno jako stan awarii samo w sobie.
Dla certyfikatu: check, który odczytuje datę wygaśnięcia z pełnego łańcucha certyfikatów w określonym harmonogramie, nie tylko sprawdza, czy handshake TLS akurat się udaje, z progiem ostrzegawczym na kilka dni przed rzeczywistym terminem, żeby był czas naprawić zepsute odnawianie, zanim stanie się awarią.
Dla endpointu, który technicznie działa: check, który sprawdza samą odpowiedź, kod statusu, ciąg znaków w treści, górny limit czasu odpowiedzi, a nie tylko to, czy połączenie zostało przyjęte.
Żaden z tych trzech checków nie jest sam w sobie skomplikowany. To, co je łączy, to konieczność ustalenia z góry, jak wygląda “nic się nie wydarzyło, choć powinno”, i zbudowania alertu wokół tego braku, zamiast wokół błędu, którego wolałbyś nigdy nie musieć grepować.
Zarejestruj się, skopiuj klucz API i wklej polecenie curl do swojego crontaba. To wszystko, co jest potrzebne.