Monitoring serwera Linux ma sens wtedy, gdy sprawdzane są elementy istotne dla konkretnej usługi: odpowiedź strony lub sklepu, działanie bazy danych, miejsce na dysku, certyfikat, procesy oraz kopie zapasowe. Sam komunikat o przekroczonym progu nie przywraca działania strony. Jest sygnałem, od którego zaczyna się ocena sytuacji.

Co dzieje się po alercie

  1. Potwierdzenie zdarzenia. Sprawdzamy, czy alert dotyczy rzeczywistej niedostępności, chwilowego wahania czy zaplanowanej zmiany.
  2. Ocena wpływu. Ustalamy, czy nie działa cała usługa, konkretny adres, baza danych, kolejka lub inny element środowiska.
  3. Diagnoza po stronie serwera. Analizujemy dostępne dane techniczne, stan usług i zasobów, aby wybrać rozsądny następny krok.
  4. Uzgodnione działanie. Zakres reakcji, osoby kontaktowe i godziny obsługi ustalamy przed rozpoczęciem stałej współpracy.
  5. Wniosek po zdarzeniu. Po usunięciu problemu wskazujemy, co warto obserwować, zmienić albo zabezpieczyć, aby ograniczyć powtórkę.

Powiadomienie a monitoring z reakcją

W podstawowym wariancie właściciel dostaje wiadomość i sam decyduje, co zrobić dalej. Monitoring z reakcją obejmuje weryfikację alarmu oraz ustalenie dalszego działania zgodnie z wcześniej uzgodnionym zakresem. To różnica ważna zwłaszcza wtedy, gdy strona lub sklep zarabiają również poza godzinami pracy zespołu.

Co można objąć kontrolą

Dobór punktów zależy od środowiska. Dla aplikacji PHP z MySQL przydatne bywają testy odpowiedzi HTTP, dostępności bazy, wykorzystania dysku i pamięci oraz ważności certyfikatu. W innych usługach istotniejsze będą procesy, kolejki, integracje albo harmonogram kopii. Nie kopiujemy mechanicznie jednego zestawu do każdego serwera.

Gdzie kończy się monitoring serwera

Monitoring może wykryć, że aplikacja nie odpowiada lub baza odrzuca połączenia. Nie ocenia za jej twórcę poprawności kodu i logiki biznesowej. Jeżeli diagnostyka wskaże aplikację, przekazujemy czytelne informacje potrzebne do dalszej pracy i pomagamy ustalić kolejność działań.