Monitorowanie instancji

Monitorowanie instancji obejmuje nadzór nad wszystkimi bazami i usługami działającymi w obrębie jednego wystąpienia serwera.

Zakres monitorowania pojedynczej instancji

Monitorowanie instancji oznacza obserwowanie jednego uruchomionego środowiska, w którym pracują określone usługi, procesy, bazy danych oraz mechanizmy komunikacji. Instancja może być rozumiana jako konkretne wystąpienie serwera aplikacyjnego, silnika bazodanowego albo innego systemu działającego pod własną konfiguracją i identyfikatorem. W obrębie tej samej maszyny może funkcjonować kilka instancji, dlatego sam adres hosta nie wystarcza do jednoznacznego określenia monitorowanego zasobu. Znaczenie mają również port nasłuchu, nazwa usługi, identyfikator procesu, używana konfiguracja oraz zależności między komponentami.

Podstawowe monitorowanie obejmuje dostępność instancji, czas odpowiedzi, stan procesów i usług, wykorzystanie procesora, pamięci operacyjnej oraz przestrzeni dyskowej. W przypadku instancji obsługującej żądania sieciowe sprawdza się także liczbę aktywnych połączeń, błędy komunikacji, przepustowość i opóźnienia. Dla instancji wykonującej operacje wejścia-wyjścia istotne są między innymi czasy odczytu i zapisu, długość kolejek urządzeń blokowych oraz liczba operacji na sekundę. Same parametry sprzętowe nie opisują jednak pełnego stanu instancji, ponieważ system może odpowiadać na prosty test kontrolny, a jednocześnie nie realizować poprawnie właściwych zadań.

Metryki, dzienniki i testy stanu

Wiarygodna obserwacja instancji łączy kilka źródeł informacji. Metryki systemowe pokazują zużycie zasobów w czasie, lecz nie wyjaśniają zawsze przyczyny problemu. Dzienniki zdarzeń zawierają komunikaty o błędach uruchamiania, zerwanych połączeniach, przekroczeniu limitów, odrzuceniu żądania lub nieudanej operacji. Warto rejestrować czas wystąpienia, poziom zdarzenia, identyfikator procesu lub usługi oraz kontekst operacji. Ułatwia to zestawienie informacji z kilku komponentów i odróżnienie pojedynczego incydentu od powtarzalnego wzorca.

Test stanu, określany często jako health check, powinien sprawdzać funkcję istotną dla danego zastosowania. Kontrola typu liveness odpowiada na pytanie, czy proces działa i może przyjąć podstawowe żądanie. Kontrola typu readiness sprawdza, czy instancja jest gotowa do obsługi właściwego ruchu, na przykład czy ma dostęp do wymaganych zależności i może wykonać operację testową. Należy rozróżnić test lokalny od testu wykonywanego z innego hosta, ponieważ awaria sieci, reguł zapory albo systemu nazw może być niewidoczna z wnętrza monitorowanej instancji. Wynik testu powinien być interpretowany razem z czasem odpowiedzi i kodem błędu, a nie wyłącznie jako wartość logiczna „działa” lub „nie działa”.

Alerty i analiza zmian w czasie

Alert powinien informować o stanie wymagającym reakcji, a nie o każdym odchyleniu od wartości typowej. Próg dla zajętości procesora może wskazywać przeciążenie, ale krótkotrwały wzrost podczas zaplanowanej operacji nie musi oznaczać awarii. Dlatego stosuje się okres obserwacji, minimalny czas trwania problemu oraz warunki powrotu do stanu prawidłowego. Przydatne są także progi zależne od trendu, na przykład stopniowe zmniejszanie wolnego miejsca albo rosnący czas odpowiedzi. Osobno należy traktować brak odpowiedzi, pogorszenie wydajności i błędy funkcjonalne, ponieważ wymagają one różnych działań diagnostycznych.

Analiza historii pozwala porównać zachowanie instancji z okresem prawidłowej pracy. Powtarzalne skoki opóźnień o określonej porze mogą wskazywać na zadanie cykliczne, kopię zapasową, intensywne przetwarzanie albo konkurencję o zasoby. Nagła zmiana po wdrożeniu nowej konfiguracji może kierować uwagę na limit połączeń, parametry pamięci, ustawienia buforów lub zmianę sposobu logowania. Przy interpretacji danych trzeba zachować jednakowe jednostki i przedziały czasowe. Średnia może ukrywać krótkie, lecz istotne opóźnienia, dlatego przy usługach interaktywnych analizuje się również percentyle, zwłaszcza 95. i 99. percentyl czasu odpowiedzi. Nie należy utożsamiać dostępności procesu z dostępnością całej funkcji, jeśli instancja zależy od innych usług.

Postępowanie przy nieprawidłowościach instancji

Diagnostykę rozpoczyna się od ustalenia zakresu problemu: czy nie odpowiada cała instancja, pojedyncza usługa, określony interfejs, czy tylko wybrane operacje. Następnie porównuje się czas rozpoczęcia awarii z metrykami zasobów, komunikatami w dziennikach i zmianami konfiguracji. Wysokie użycie pamięci połączone z częstym zapisem do pliku wymiany wskazuje inny kierunek niż błędy połączeń przy prawidłowym obciążeniu procesora. Z kolei rosnące opóźnienie wejścia-wyjścia może powodować wtórne zwiększenie liczby oczekujących żądań i sprawiać wrażenie przeciążenia aplikacji.

Przed ponownym uruchomieniem procesu należy zabezpieczyć dostępne informacje diagnostyczne, ponieważ restart może usunąć stan potrzebny do ustalenia przyczyny. Weryfikuje się zależności, porty, uprawnienia procesu, dostępność miejsca na dysku i poprawność plików konfiguracyjnych. Jeżeli problem dotyczy komputera, na którym działa lokalna usługa pomocnicza albo narzędzie monitorujące, potrzebne może być sprawdzenie systemu operacyjnego, pamięci, dysku, temperatur oraz stabilności połączeń. Po usunięciu przyczyny warto ponowić ten sam test funkcjonalny, który wcześniej wykazał nieprawidłowość, oraz sprawdzić, czy alert został prawidłowo zamknięty. Sama zmiana statusu procesu na „uruchomiony” nie potwierdza jeszcze poprawnego działania instancji.