Monitoring serwerów Linux z progami i przypisaną reakcją

Monitoring techniczny

Alarm ma prowadzić do decyzji, a nie tylko generować wiadomość

Monitoring pracuje stale, ale jego wartość powstaje dopiero wtedy, gdy wiadomo, co oznacza przekroczenie progu, kto odbiera alarm i jaka jest procedura. Dlatego wdrożenie obejmuje metryki, progi, kanały powiadomień i test alarmu.

Dwa najczęstsze stany zastane są lustrzanym odbiciem tego samego błędu. Pierwszy: obserwacji nie ma wcale, więc o awarii dowiadujesz się od klienta. Drugi: powiadomień jest tyle, że reguła w skrzynce przenosi je do osobnego katalogu, którego nikt nie otwiera. Skutek w obu przypadkach wychodzi identyczny.

Progi, które mają sens

Wartości poniżej to punkt wyjścia dla typowego serwera aplikacyjnego. Przy bazie danych, hoście wirtualizacji albo maszynie z jednym zadaniem wsadowym wyglądają inaczej - i o tym właśnie rozmawiamy przy wdrożeniu.

• Miejsce na dyskuostrzeżenie przy 85%, stan krytyczny przy 93%; osobno kontrola tempa przyrostu, bo z niej wynika, ile realnie zostało czasu
• Obciążenieliczone na rdzeń, nie bezwzględnie; alarmuje dopiero utrzymujące się przekroczenie, a nie pojedynczy skok podczas kopii
• Pamięćistotne jest realnie dostępne miejsce po odliczeniu buforów oraz aktywność przestrzeni wymiany, nie samo zajęcie RAM
• Macierz dyskowastan zdegradowany to zdarzenie krytyczne od pierwszej sekundy - czekanie na drugi nośnik nie jest strategią
• Certyfikatyostrzeżenie 21 dni przed wygaśnięciem, stan krytyczny na 7 dni; test obejmuje pełny łańcuch, nie tylko datę
• Kopia zapasowaalarm, gdy ostatnia udana kopia jest starsza niż doba i pięć godzin - margines mieści jedno nieudane uruchomienie
• Czas odpowiedzimierzony na realnym adresie z oczekiwaną treścią; osobny próg dla logowania i koszyka, bo to one decydują o przychodzie
• Kolejka pocztyrosnąca kolejka wychodząca zwykle znaczy problem z reputacją adresu albo pętlę w aplikacji

Narzędzie dobieramy do środowiska

Nagios pozostaje dobrym rozwiązaniem dla jawnych testów i infrastruktury o stabilnym zakresie. Zabbix upraszcza zbieranie wielu metryk z hostów, a Prometheus sprawdza się w środowiskach aplikacyjnych i dynamicznych. Nie wdrażamy stosu obserwowalności większego niż system, który ma chronić.

Monitoring serwera na Nagiosie w praktyce

Kiedy zapada decyzja o Nagiosie, wdrożenie ma bardzo konkretny kształt. Testy lokalne uruchamiamy przez agenta albo przez sesję SSH z osobnym, ograniczonym kontem - bez wystawiania dodatkowego portu, gdy nie ma takiej potrzeby.

• Testy lokalnezajętość partycji, obciążenie, pamięć, liczba procesów, wiek plików kopii, stan macierzy programowej, odczyt SMART
• Testy zdalneodpowiedź HTTP z oczekiwanym kodem i fragmentem treści, poczta wychodząca i przychodząca, port bazy, ważność certyfikatu, czas z serwera NTP
• Zależnościusługi podpięte pod host - gdy maszyna nie odpowiada, przychodzi jedno powiadomienie zamiast czternastu
• Powtórzeniastan potwierdzany kilkoma kolejnymi sprawdzeniami, żeby chwilowy skok nie budził dyżurnego
• Eskalacjabrak potwierdzenia w ustalonym czasie przenosi zgłoszenie na kolejną osobę lub inny kanał
• Okna serwisoweplanowane wyciszenia z terminem wygaśnięcia, wpisywane przed pracami, a nie po pierwszym fałszywym alarmie

Ten sam zestaw pojęć przenosi się na Zabbiksa i Prometheusa; różnią się nazwy i sposób zapisu reguł. Wybór narzędzia jest wtórny wobec pytania, czy ktoś odbierze telefon o trzeciej w nocy.

Skąd bierze się szum i jak go zdejmujemy

Nadmiar powiadomień nie jest oznaką czujności. To zwykle skutek czterech rzeczy, z których każdą da się usunąć bez rezygnacji z obserwacji.

• Próg ustawiony „na oko”. Alarm na 70% zajętości dysku, który stoi na 72% od pół roku, uczy zespół ignorowania powiadomień.
• Brak zależności. Niedostępny host wysyła osobne zgłoszenie z każdej działającej na nim usługi.
• Migotanie. Usługa na granicy progu przełącza się w kółko między stanem dobrym a złym; pomaga wykrywanie tego wzorca i wymóg kilku zgodnych pomiarów.
• Alarm bez adresata. Powiadomienie, przy którym nikt nie wie, co ma zrobić, jest tylko informacją - i powinno trafiać do raportu, nie na telefon.

Wdrożenie monitoringu krok po kroku

1. 1

   Inwentaryzacja

   Hosty, usługi, zależności, właściciele i aktualne źródła alarmów.

2. 2

   Metryki i progi

   Progi ostrzegawcze i krytyczne, opóźnienia oraz wyciszenia serwisowe.

3. 3

   Powiadomienia

   Adresaci, kanały, eskalacja i godziny odpowiedzialności.

4. 4

   Test

   Kontrolowane wywołanie alarmu oraz potwierdzenie, że komunikat pozwala rozpocząć diagnozę.

5. 5

   Przegląd po dwóch tygodniach

   Które testy okazały się szumem, czego zabrakło, które progi wymagają korekty po zderzeniu z realnym ruchem.