Monitoring instancji

Monitoring instancji to śledzenie kondycji serwera bazodanowego: obciążenia, pamięci, kolejek dyskowych i błędów.

Zakres obserwacji instancji

Monitoring instancji polega na ciągłym zbieraniu informacji o stanie działającego serwera bazodanowego i jego otoczenia. Obserwacja może obejmować obciążenie procesora, zajętość pamięci operacyjnej, aktywność urządzeń blokowych, długość kolejek dyskowych, liczbę aktywnych połączeń oraz błędy rejestrowane przez system operacyjny i silnik bazy danych. Sama obecność procesu serwera nie oznacza jeszcze prawidłowej pracy. Instancja może odpowiadać na część żądań, a jednocześnie mieć narastające opóźnienia, brak wolnej pamięci albo problemy z zapisem.

Ważne jest rozróżnienie pomiędzy pomiarem chwilowym a trendem. Jednorazowy wzrost użycia procesora może wynikać z planowego zadania, natomiast utrzymująca się wysoka wartość wraz ze wzrostem czasu odpowiedzi wskazuje na problem wymagający analizy. Podobnie pojedynczy błąd zapisu nie musi oznaczać awarii, ale powtarzające się komunikaty o błędach wejścia-wyjścia, przerwanych połączeniach lub braku miejsca powinny zostać powiązane z innymi obserwowanymi wskaźnikami.

Metryki systemowe i bazodanowe

Podstawą monitoringu są metryki opisujące zasoby. Dla procesora przydatne są nie tylko procenty zajętości, lecz także czas oczekiwania procesów na procesor i udział czasu systemowego. W przypadku pamięci należy śledzić dostępny obszar, wykorzystanie pamięci przez proces instancji, aktywność stronicowania oraz sytuacje, w których system zaczyna intensywnie korzystać z pamięci wymiany. Nadmierne stronicowanie może powodować opóźnienia nawet wtedy, gdy średnie obciążenie procesora pozostaje umiarkowane.

Dla dysków istotne są przepustowość odczytu i zapisu, liczba operacji wejścia-wyjścia, czas ich obsługi oraz długość kolejki. Wysoka kolejka nie zawsze oznacza błąd, ponieważ zależy od rodzaju urządzenia i obciążenia, ale jej utrzymywanie się razem z rosnącym czasem odpowiedzi jest sygnałem przeciążenia albo problemu sprzętowego. Po stronie bazy analizuje się między innymi liczbę aktywnych sesji, czas trwania zapytań, blokady, oczekiwania na zasoby, nieudane logowania, błędy transakcji i opóźnienia odpowiedzi. Konkretne nazwy liczników zależą od użytego silnika, dlatego nie należy bezpośrednio przenosić poleceń diagnostycznych z PostgreSQL, MySQL, Oracle lub SQL Server do innego produktu.

Alerty, historia i korelacja zdarzeń

Monitoring jest użyteczny wtedy, gdy ustalone są warunki alarmowe oraz sposób ich obsługi. Alert może dotyczyć przekroczenia poziomu zajętości pamięci, długiej kolejki dyskowej, braku miejsca na woluminie, niedostępności portu nasłuchu, zbyt dużej liczby połączeń albo powtarzających się błędów w logu. Próg powinien uwzględniać normalny profil pracy instancji. Stałe alarmowanie przy każdym krótkim skoku obciążenia prowadzi do nadmiaru powiadomień i utrudnia zauważenie rzeczywistej awarii.

Warto przechowywać dane historyczne w rozdzielczości pozwalającej porównać zdarzenie z wcześniejszymi okresami. Historia pokazuje, czy problem występuje wyłącznie w godzinach największego ruchu, pojawił się po zmianie konfiguracji, narasta stopniowo, czy rozpoczął się równocześnie z awarią urządzenia. Najbardziej wiarygodny obraz powstaje przez korelację kilku źródeł: metryk systemowych, statystyk instancji, logów błędów i informacji o dostępności. Jeżeli czas odpowiedzi rośnie przy prawidłowej dostępności usługi, przyczyną może być przeciążenie lub blokowanie. Jeżeli jednocześnie występują błędy odczytu, należy uwzględnić problem ścieżki przechowywania danych.

Od pomiaru do diagnozy problemu

Wynik monitoringu nie jest automatycznie pełną diagnozą. Alarm wskazuje odchylenie od oczekiwanego stanu, ale ustalenie przyczyny wymaga sprawdzenia zależności między procesami, zasobami i czasem wystąpienia zdarzenia. Przy wolnych odpowiedziach należy ustalić, czy opóźnienie dotyczy wszystkich operacji, jednej funkcji, konkretnego typu zapytań czy tylko wybranych klientów. Przy problemach z pamięcią trzeba sprawdzić, czy wzrost wynika z większej liczby sesji, dużych operacji, niewłaściwej konfiguracji, wycieku zasobów lub równoległego obciążenia innych usług.

Podczas analizy należy zachować dane potrzebne do porównania: przedziały czasu, wartości metryk, komunikaty błędów, identyfikator instancji oraz opis czynności wykonanych przed pojawieniem się problemu. Pomocne jest odtworzenie osi zdarzeń, na której zestawia się początek opóźnień, wzrost użycia procesora, zmianę długości kolejki dyskowej i pierwsze błędy. Taka metoda ogranicza ryzyko przypisania winy przypadkowemu wskaźnikowi. W środowisku serwerowym monitoring powinien być również testowany: trzeba sprawdzić, czy alarm powstaje przy niedostępności instancji, czy rejestruje powrót do prawidłowej pracy i czy nie przestaje zbierać danych właśnie podczas awarii.