Monitoruj najpierw endpointy skierowane do klientów
Każdy produkt SaaS ma endpointy, z którymi użytkownicy wchodzą w bezpośrednią interakcję. To Twój najwyższy priorytet monitorowania.
Zacznij od panelu aplikacji. Jeśli użytkownicy logują się na app.twojafirma.pl, monitoruj ten URL. Następnie dodaj endpoint uwierzytelniania. Jeśli użytkownicy nie mogą się zalogować, reszta monitorowania nie ma znaczenia.
Dodaj główne endpointy API. Jeśli Twój produkt ma API REST, które klienci integrują, monitoruj endpointy, które wywołują najczęściej. Endpoint /v1/health jest w porządku, ale może zwracać 200, podczas gdy rzeczywiste endpointy danych wyrzucają błędy 500. Monitoruj endpointy, które faktycznie odwiedzają Twoi użytkownicy.
Dodaj przepływ rozliczeń i płatności. Jeśli webhooki Stripe lub Paddle przestają docierać albo endpoint zarządzania subskrypcjami przestaje działać, tracisz pieniądze. Monitoruj endpointy, które dotykają przychodów.
Sprawdzaj zadania w tle
Twój serwer działa. API zwraca 200. Panel się ładuje. Wszystko wygląda dobrze. Ale nocna kopia zapasowa bazy danych po cichu zawodzi od dwóch tygodni. Twoja kolejka e-mail jest zapchana 8 000 niedostarczonych wiadomości. Potok eksportu danych zatrzymał się trzy dni temu.
To luka monitorowania, która łapie większość zespołów. Monitorowanie dostępności obejmuje ścieżkę żądanie-odpowiedź. Nie obejmuje zaplanowanych zadań, workerów w tle ani potoków asynchronicznych.
Monitorowanie heartbeat wypełnia tę lukę. Każde zaplanowane zadanie otrzymuje unikalny URL. Gdy zadanie wykona się pomyślnie, pinguje ten URL. Jeśli ping nie dotrze w oczekiwanym oknie czasowym, otrzymujesz alert. Konfiguracja to pojedyncze polecenie curl na końcu skryptu cron.
Monitoruj co najmniej te zadania:
- Kopie zapasowe baz danych
- Kolejki dostarczania e-maili
- Rozliczenia i generowanie faktur
- Synchronizacje i eksporty danych
- Rotacja i czyszczenie logów
- Automatyzacja odnowienia certyfikatów
Dowiedz się więcej o monitorowaniu heartbeat i jak wychwytuje to, co sprawdzanie dostępności pomija.
Wybierz odpowiedni interwał sprawdzania
Nie każdy endpoint potrzebuje tej samej częstotliwości sprawdzania. Dopasuj interwały do biznesowego wpływu przestojów.
Sprawdzanie co 30 sekund dla endpointów krytycznych dla przychodów: przepływ płatności, główne API, usługa uwierzytelniania. Jeśli padną, tracisz pieniądze lub blokujesz użytkowników. Musisz wiedzieć tak szybko, jak to możliwe.
Sprawdzanie co minutę działa dla większości usług produkcyjnych. Panel aplikacji, drugorzędne API, endpointy statusu. Wystarczająco szybko, aby wykryć prawdziwe problemy, wystarczająco wolno, aby uniknąć fałszywych alarmów.
Sprawdzanie co 5 minut jest w porządku dla endpointów o niższym priorytecie: strony marketingowe, witryny dokumentacji, narzędzia wewnętrzne. Jeśli strona marketingowa nie działa przez 4 minuty, wpływ biznesowy jest niski.
Im szybsze kontrole, tym szybciej wiesz. Ale szybsze kontrole oznaczają też więcej danych, więcej szumu i potencjalnie wyższe koszty. Dopasuj interwał do wpływu.
Skonfiguruj alerty, które nie wypalają zespołu
Zmęczenie alertami to cichy zabójca monitorowania. Gdy każdy drobny problem wyzwala powiadomienie, zespół przestaje zwracać uwagę. Wyciszają kanał. Ignorują e-maile. Potem zdarza się prawdziwy incydent i nikt nie zauważa.
Używaj progów eskalacji alertów. Wymagaj 2 lub 3 kolejnych niepowodzeń, zanim alert zostanie uruchomiony. To odfiltrowuje przejściowe problemy sieciowe, które same się rozwiązują w kilka sekund. Pojedyncze nieudane sprawdzenie nie jest incydentem. Trzy z rzędu są.
Kieruj alerty według ważności. Krytyczne monitory trafiają do PagerDuty lub na telefony dyżurne. Monitory poziomu ostrzeżenia trafiają na kanał Slack. Monitory informacyjne trafiają na e-mail lub pulpit. Nie wysyłaj wszystkiego w to samo miejsce.
Używaj godzin ciszy dla prac konserwacyjnych. Jeśli wdrażasz co wtorek o 2 w nocy, wycisz alerty na monitorach objętych tym oknem. Zespół wie o wdrożeniu. Nie musi być powiadamiany, ponieważ aplikacja się zrestartowała.
Oddziel kanały alertów od kanałów dyskusyjnych. Kanał #alerty powinien zawierać tylko zautomatyzowane komunikaty alertów. Dyskusje międzyludzkie odbywają się na #ops lub #engineering. To utrzymuje kanał alertów czysty i czytelny.
Zbuduj stronę statusu, którą użytkownicy faktycznie sprawdzą
Twoja strona statusu to nie tylko pole do odhaczenia. To narzędzie komunikacyjne, które zmniejsza obciążenie wsparcia podczas incydentów.
Umieść ją na własnej domenie (status.twojafirma.pl). Dostosuj ją do swojej marki. Linkuj do niej ze stopki aplikacji, dokumentacji wsparcia i stron błędów.
Gdy zdarzy się incydent, publikuj aktualizacje. „Badamy zgłoszenia zwiększonych błędów API” jest lepsze niż milczenie. „Problem został zidentyfikowany jako wyczerpanie puli połączeń bazy danych. Skalujemy w górę.” mówi użytkownikom, że wiesz, co jest nie tak. „Monitorujemy odzyskiwanie. Opóźnienie API wróciło do normy.” zamyka pętlę.
Strona statusu, która aktualizuje się automatycznie na podstawie danych monitorowania, oznacza, że nie musisz ręcznie przełączać przełączników podczas incydentu. Strona odzwierciedla rzeczywistość. Ty skupiasz się na rozwiązaniu problemu. Dowiedz się więcej o stronach statusu PingWatchdog.
Przeglądaj incydenty
Po każdym incydencie poświęć 10 minut na przejrzenie, co się stało. Spójrz na oś czasu. Jak długo trwało wykrycie? Jak długo trwała odpowiedź? Jak długo trwało rozwiązanie?
Te trzy liczby to Twoje podstawowe wskaźniki niezawodności: średni czas wykrycia (MTTD), średni czas odpowiedzi (MTTR) i średni czas rozwiązania (MTTResolve). Śledź je w czasie. Stajesz się szybszy? Wolniejszy?
Wykorzystaj dane o incydentach, aby uzasadnić ulepszenia. Jeśli 40% incydentów jest spowodowanych problemami z połączeniem z bazą danych, to sygnał, aby zainwestować w pule połączeń lub repliki odczytu. Jeśli wygasanie certyfikatów SSL powoduje incydenty co 90 dni, zautomatyzuj odnowienie certyfikatów.
PingWatchdog automatycznie tworzy incydenty, gdy monitory padają, i automatycznie je rozwiązuje, gdy usługi wracają do działania. Otrzymujesz pełną oś czasu bez ręcznej pracy. Dowiedz się więcej o zarządzaniu incydentami.
Warstwuj monitorowanie
Jedno narzędzie nie może pokryć wszystkiego. Używaj PingWatchdog do monitorowania zewnętrznego: dostępność, SSL, heartbeat, strony statusu. Używaj narzędzi monitorowania wydajności aplikacji (APM), takich jak Datadog lub Sentry, do metryk wewnętrznych. Używaj agregacji logów do debugowania.
Widok zewnętrzny mówi Ci, czy użytkownicy mogą dotrzeć do Twojej usługi. Widok wewnętrzny mówi dlaczego. Oba mają znaczenie.
Porównaj narzędzia monitorujące, aby znaleźć odpowiedni stos dla swojego zespołu.