Dobry próg alertu dla serwera uruchamia się wtedy, gdy ktoś musi zareagować, a poza tym milczy. W praktyce oznacza to alertowanie na podstawie utrzymujących się wartości, a nie pojedynczych skoków, mierzenie obciążenia na rdzeń CPU zamiast surowej liczby, obserwowanie dostępnej pamięci i swapu zamiast „zajętej pamięci RAM”, wczesne alerty o miejscu na dysku i tempie jego przyrostu oraz traktowanie każdego nieplanowanego restartu jako czegoś, o czym warto wiedzieć. Podziel alerty na poziom ostrzegawczy na godziny pracy i poziom krytyczny, który może kogoś obudzić, a po każdym incydencie przejrzyj progi.
Ten poradnik omawia kolejno każdą metrykę, wyjaśnia, jak wygląda sensowny próg, i kończy się tabelą wartości startowych. To punkty wyjścia, a nie sztywne reguły: każdy serwer ma własną normę, a właściwy próg to ten, który do niej pasuje.
Do czego służy próg
Każdy alert kosztuje uwagę. Alert, który się uruchamia i nie wymaga żadnego działania, uczy ludzi ignorować następny, a następny może być prawdziwy. Zanim ustawisz próg, odpowiedz na trzy pytania:
Co się zepsuje, jeśli ta wartość będzie dalej rosła, i jak szybko?
Co faktycznie zrobiłaby osoba, która otrzyma alert?
Czy to może poczekać do rana?
Jeśli nic się nie psuje i nikt by nie zareagował, to jest wykres, a nie alert. Jeśli może poczekać do rana, to jest ostrzeżenie. Na telefon w nocy powinno trafiać tylko to, co nie może czekać.
Poziom ostrzegawczy i krytyczny
Dwa poziomy na metrykę sprawdzają się w większości zespołów:
Ostrzeżenie: coś zmierza w złym kierunku. Wyślij je e-mailem lub na kanał czatu zespołu i zajmij się nim w godzinach pracy.
Krytyczny: awaria jest blisko lub już trwa. Wyślij go jako powiadomienie push do osoby dyżurnej, w dzień i w nocy.
Jeśli Twoje narzędzie do monitorowania ma jeden próg na metrykę, ten sam efekt osiągniesz routingiem: ustaw próg tam, gdzie potrzebne jest działanie, i wybierz kanał dla każdego serwera. Alert o dysku na serwerze stagingowym może trafić na e-mail, a ten sam alert dla produkcyjnej bazy danych na czat zespołu dyżurnego. Powiadomienia w Uptimecheck wybiera się dla każdego monitora, więc taki podział jest prosty. Dzięki grafikom dyżurów alerty push trafiają do osoby, która ma akurat dyżur, a eskalacja może wstrzymać kanał na 5 do 60 minut i wysłać alert tylko wtedy, gdy problem nadal trwa i nikt go nie potwierdził.
Czas trwania ważniejszy niż skoki
Najczęstszym źródłem szumu są alerty na podstawie pojedynczego odczytu. CPU na 100 procent przez dziesięć sekund podczas wdrożenia, kopii zapasowej czy przebudowy cache to norma. CPU na 100 procent przez dwadzieścia minut już nie. Wszędzie, gdzie narzędzie na to pozwala, dodaj czas trwania: „powyżej 90 procent przez 10 minut” zamiast „powyżej 90 procent”.
Tam, gdzie nie pozwala, korzystaj z metryk, które same wygładzają się w czasie. Dobrym przykładem jest 15-minutowe średnie obciążenie (load average): krótki skok ledwo je rusza, a utrzymujące się przeciążenie podnosi je i trzyma wysoko.
CPU
Wysokie użycie CPU samo w sobie rzadko jest problemem. Zajęty serwer to serwer, który na siebie zarabia. CPU staje się problemem, gdy jest wysycony na tyle długo, że żądania ustawiają się w kolejce, a czasy odpowiedzi rosną. Alertuj na utrzymujące się użycie i patrz na nie razem z czasami odpowiedzi z kontroli dostępności. Jeśli CPU jest na 95 procentach, a czasy odpowiedzi się nie zmieniają, serwer jest zajęty, a nie w awarii.
Load average na rdzeń
W Linuksie load average to w przybliżeniu liczba procesów, które działają lub czekają na CPU, a w Linuksie także tych czekających na operacje wejścia-wyjścia dysku, uśredniona z 1, 5 i 15 minut. Surowe obciążenie 4 samo nic nie mówi: na serwerze z 16 rdzeniami to niewiele, na serwerze z 2 rdzeniami to dwa razy więcej, niż maszyna jest w stanie obsłużyć. Przed porównaniem podziel je przez liczbę rdzeni, którą podaje nproc.
Wartość 1-minutowa reaguje szybko i jest zaszumiona. Używaj jej do diagnozy, nie do alertów.
Alertuj na wartość 15-minutową. Powyżej 1 na rdzeń oznacza, że praca ustawia się w kolejce; znacznie powyżej przez dłuższy czas oznacza, że odczuwają to użytkownicy.
Wysokie obciążenie przy niskim użyciu CPU zwykle oznacza procesy czekające na dysk lub pamięć sieciową. Szukaj w I/O, nie w kodzie.
RAM i swap
„Zajęty RAM” to w Linuksie myląca metryka. Jądro wykorzystuje wolną pamięć na cache plików i oddaje ją, gdy potrzebują jej aplikacje, więc zdrowy serwer często pokazuje prawie pełną pamięć. Zamiast tego patrz na pamięć dostępną, czyli kolumnę „available” w free -m, która uwzględnia cache możliwy do odzyskania.
Swap mówi więcej. Serwer, który normalnie nie korzysta ze swapu, a zaczyna to robić, jest pod presją pamięci, a wydajność gwałtownie spada, gdy aktywna pamięć trafia na dysk. Dwa przydatne sygnały:
Pojawienie się lub wzrost użycia swapu na serwerze, który zwykle go nie używa.
Dostępna pamięć systematycznie spadająca przez kolejne dni, co często wskazuje na wyciek w długo działającym procesie.
Serwery baz danych to szczególny przypadek: są celowo skonfigurowane tak, by wykorzystywać większość pamięci. Ustaw ich progi na podstawie tego, co widzisz w zwykłym tygodniu.
Miejsce na dysku i jego przyrost
Pełny dysk to jedna z najczęstszych przyczyn awarii, których dało się uniknąć. Bazy danych przestają zapisywać, logi przestają się rotować, sesji nie da się zapisać, a kopie zapasowe się nie udają. Dysk to też metryka, którą najłatwiej dobrze ustawić, bo rzadko zmienia się szybko, więc przy wczesnym alercie zostaje czas na reakcję.
Ustaw próg procentowy dla ostrzeżenia i poziomu krytycznego, ale dopasuj go do rozmiaru. Na wolumenie 2 TB 10 procent wolnego miejsca to wciąż 200 GB; na wolumenie 20 GB to 2 GB, które jeden wadliwy log może zjeść w jedno popołudnie.
Obserwuj nie tylko poziom, ale i przyrost. Dysk zajęty w 70 procentach, który w tym tygodniu urósł o 10 punktów, jest pilniejszy niż taki, który od roku stoi na 85 procentach.
Wiedz, co go zapełnia: logi, kopie zapasowe trzymane lokalnie, przesłane pliki, obrazy Dockera, pliki bazy danych. Każde z nich wymaga innego rozwiązania.
Sieć
Dla ruchu sieciowego trudno ustawić stały próg, bo norma zmienia się z porą dnia i sezonem. Dwa wzorce zasługują na alert. Ruch znacznie powyżej zwykłego poziomu, bliski przepustowości łącza, może oznaczać nagły skok ruchu, scraper albo atak. Ruch spadający niemal do zera na serwerze, który normalnie jest zajęty, może oznaczać, że wypadł z load balancera albo stracił sieć, nawet jeśli sama maszyna wygląda dobrze. Zanim ustawisz liczby, poznaj normalny zakres z kilku tygodni historii.
Restarty
O nieplanowanym restarcie zawsze warto wiedzieć. Może to być aktualizacja jądra, prace serwisowe dostawcy hostingu, awaria albo brak pamięci (out-of-memory). Nawet jeśli wszystko wraca, usługi nieustawione do startu przy uruchomieniu, zaplanowane zadania, które przypadały na czas restartu, i zamontowane wolumeny mogą zostać w złym stanie. Alertuj o każdym restarcie poza oknem serwisowym, na poziomie ostrzegawczym, jeśli serwer podniósł się sam.
Wartości startowe
Poniższe wartości to przykładowe punkty wyjścia dla typowego serwera WWW lub aplikacyjnego. Używaj ich przez pierwsze tygodnie, a potem dopasuj do tego, co zaobserwujesz.
MetrykaOstrzeżenie (przykład)Krytyczny (przykład)CPUPowyżej 85% przez 15 minutPowyżej 95% przez 15 minut, przy rosnących czasach odpowiedziLoad average (15 min)Powyżej 1 na rdzeńPowyżej 2 na rdzeńDostępna pamięćPoniżej 15%Poniżej 5%SwapJakiekolwiek użycie na serwerze, który normalnie go nie używaPowyżej 50% swapu w użyciuDyskPowyżej 80% lub zapełnienie w ciągu tygodnia przy obecnym tempiePowyżej 90% lub zapełnienie w ciągu dobySiećZnacznie poza normalnym zakresem dla danej pory dniaBlisko przepustowości łącza lub blisko zera na zajętym serwerzeRestartKażdy restart poza oknem serwisowymUsługi nie wróciły po restarcie
Monitorowanie serwerów w Uptimecheck raportuje CPU, pamięć, dysk i sieć co minutę na Linuksie, macOS i Windows. Progi dla CPU, pamięci i dysku ustawiasz dla każdego serwera, z czasem trwania, np. 5 lub 15 minut, a alert dostajesz też przy restartach i gdy serwer przestaje się odzywać, więc maszyny, która przestała raportować, nigdy nie weźmiesz za spokojną. Dlaczego te liczby są ważne, przeczytasz w artykule o utrzymaniu strony w działaniu dzięki monitorowaniu stanu serwera.
Obserwuj też objawy
Metryki serwera opisują przyczyny. Twoi użytkownicy doświadczają objawów: wolnych stron, błędów i nieudanych zadań. Monitoruj jedno i drugie. Kontrola dostępności z walidacją odpowiedzi powie Ci, kiedy strona przestaje działać, a heartbeat, kiedy kopia zapasowa się nie zakończyła. Gdy alert o objawie i alert o zasobach uruchamiają się razem, przyczyna jest zwykle oczywista. Gdy uruchamia się tylko alert o zasobach, często masz czas, by to naprawić, zanim ktokolwiek zauważy.
Dzięki temu możesz też śmiało podnieść progi serwera. Jeśli strona jest sprawdzana co minutę, alert o CPU nie musi być tym, co wyłapie awarię. Można go dostroić do wczesnego ostrzegania zamiast ostatniej deski ratunku. To samo podejście dotyczy kontroli stron; zobacz, jak ograniczyć fałszywe alerty w monitorowaniu dostępności.
Przeglądaj progi po incydentach
Progi nigdy nie są gotowe raz na zawsze. Po każdym incydencie, a w przypadku hałaśliwych serwerów raz w miesiącu, zapytaj:
Czy alert uruchomił się, zanim zauważyli to użytkownicy? Jeśli nie, która metryka drgnęła pierwsza i czy niższy próg by to wyłapał?
Które alerty się uruchomiły, a nikt na nie nie zareagował? Podnieś je, dodaj czas trwania albo przenieś je na kanał dzienny.
Czy alert dotarł do kogoś, kto mógł zareagować? Jeśli nie, zmień routing.
Czy norma serwera zmieniła się po aktualizacji, migracji albo wzroście ruchu?
Zapisz odpowiedzi w raporcie z incydentu, żeby każda zmiana miała uzasadnienie. Szablon postmortemu incydentu ma na to osobną sekcję.
Podsumowanie
Alertuj o tym, co wymaga człowieka, z taką pilnością, jaką to naprawdę ma. Korzystaj z utrzymujących się wartości, obciążenia na rdzeń, dostępnej pamięci i swapu, poziomu i przyrostu zajętości dysku oraz każdego nieplanowanego restartu. Zacznij od przykładowych wartości, poznaj normę każdego serwera i dostrajaj progi po każdym incydencie.
Uptimecheck łączy monitorowanie serwerów z kontrolami dostępności, heartbeatami i stronami statusu na jednym koncie. Rozpocznij 14-dniowy bezpłatny okres próbny, bez karty kredytowej.