Przejdź do treści głównej

Poradniki / Przewodniki po monitoringu: każdy typ kontroli krok po kroku

Poradnik konfiguracji monitoringu CPU, RAM i dysku

Sprawdzenie licznika (Counter, oznaczone jako Monitor CPU, RAM, HDD w panelu New Monitor) odczytuje jedną wartość liczbową według harmonogramu i może alarmować, gdy ta wartość przekroczy ustalony przez Ciebie próg. Wartością może być obciążenie CPU, użycie pamięci, użycie dysku, czas połączenia z portem, czas połączenia z bazą danych albo licznik wydajności Windows. Odpowiada na inne pytanie niż sprawdzenie dostępności: nie "czy witryna odpowiada", ale "czy maszynie pod spodem kończy się miejsce".

Zanim zaczniesz

Dla tego typu sprawdzenia nie ma instalowalnego agenta HostTracker ani wyboru Lokalizacji monitorowania per monitor. Odpytywanie prowadzi własna, prywatna infrastruktura sprawdzająca HostTracker, a nie rozproszona sieć publiczna. Sprawdzenie działa odwrotnie: Twój serwer udostępnia jeden mały endpoint, który odpowiada pojedynczą liczbą, a HostTracker odpytuje go według harmonogramu. Są trzy sposoby na dostarczenie tego endpointu, wybierane ustawieniem Dostawca wartości poniżej, i którykolwiek wybierzesz, musi być wdrożony i osiągalny, zanim utworzysz monitor:

  • Napisz endpoint samodzielnie (opcja niestandardowa). Odpowiada małym obiektem JSON, co jest opcją preferowaną przez wiele zespołów, bo na ich serwerze nigdy nie działa nic, czego sami nie napisali.
  • Wdróż gotowy kolektor PHP HostTracker na serwerze webowym Linux/Unix.
  • Wdróż gotowy handler ASP.NET 4.0 HostTracker na serwerze IIS/Windows.

Hosta bez żadnego dostępu przychodzącego nie da się odpytać. To, co musi być udostępnione, to jeden adres URL tylko do odczytu, zwracający liczbę, a nie port administracyjny, ale musi być udostępniony sprawdzającym HostTracker.

Źródło monitorowania

Dla tej sekcji nie ma zrzutu ekranu, ale każda kontrolka w niej wciąż wymaga wyjaśnienia, bo to ona odróżnia ten typ sprawdzenia od reszty panelu.

  • Dostawca wartości - rozwijana lista z trzema opcjami. Dostawca wartości - Twoja własna usługa webowa (niestandardowa): Twój endpoint odpowiada {"v": 12.34, "e": "tekst błędu", "vs": "ciąg wersji"}, i musi być obecna przynajmniej wartość albo ciąg błędu, więc endpoint zwracający po prostu {"v": 42.5} raportuje 42.5 przy każdym sprawdzeniu. Kolektor HostTracker - PHP, dla serwerów webowych *nix: wymaga włączonego shell_exec w php.ini (wywołuje powłokowo top, free i df), a do odczytu czasu połączenia z MySQL potrzebne są rozszerzenia mysql/mysqli. Kolektor HostTracker - ASP.NET 4.0, dla IIS/Windows: tożsamość puli aplikacji potrzebuje uprawnień do odczytu liczników wydajności i rejestru, zwykle wystarcza Network Service. Oba gotowe kolektory można pobrać z tej sekcji i trzeba je wdrożyć na docelowym serwerze ręcznie; HostTracker nigdy nie wypycha niczego na Twój serwer automatycznie.
  • Pole URL monitora tuż poniżej nazywa się Pełny URL monitora dla opcji niestandardowej (dokładny adres endpointu, wybierany dosłownie) albo Bazowy URL monitora dla gotowego kolektora (główny adres witryny, pod którym wdrożono skrypt kolektora; HostTracker dokleja do niego własną nazwę pliku kolektora).
  • Gdy tylko wybrany zostanie gotowy kolektor, pojawia się rozwijana lista Typ licznika: użycie CPU %, użycie RAM %, użycie dysku lub systemu plików %, czas połączenia z portem (ms), czas połączenia z MySQL (ms) oraz, tylko dla ASP.NET, czas połączenia z SQL Server (ms) i licznik wydajności Windows. Każdy niesie swoje własne pole: literę dysku albo ścieżkę *nix, host i port, ciąg połączenia (z linkiem do przykładowego formatu), albo trójkę kategoria/nazwa/instancja dla licznika wydajności (instancja może zostać pusta dla wartości domyślnej, często _Total).

Ustawienia główne

Ustawienia główne dla tego typu nie mają dedykowanego zrzutu ekranu, więc oto każda kontrolka w nich:

  • Interwał - od 1 minuty do 24 godzin, plus alternatywa w postaci harmonogramu cron. Jedna minuta pasuje do maszyny krytycznej biznesowo; 5 albo 10 minut wystarczy dla wolniejszego trendu, jak użycie dysku.
  • Tagi - dowolne etykiety do grupowania i filtrowania monitorów.
  • Pełny dziennik - zapisuje każdą pojedynczą odpytaną wartość zamiast tylko zgrupowanych podsumowań.
  • Otwarte statystyki - sprawia, że statystyki i strona dziennika tego monitora są udostępniane, w tym niezalogowanym.
  • Ponów przy nieudanym połączeniu - przełącznik, domyślnie włączony, który ponawia próbę raz, zanim nieudane pobranie zostanie oznaczone jako wprost błąd.
  • Kontrolki Dostawca wartości, URL monitora i Typ licznika, opisane wyżej pod Źródłem monitorowania, także znajdują się w tej grupie w panelu.

Weryfikacja odpowiedzi

Sekcja weryfikacji odpowiedzi z rozwijaną listą Warunek błędu ustawioną na brak warunku, a podsumowanie grupy pokazuje brak progu

Tu surowy odczyt zamienia się w alert, i tu czytelnicy zwykle mają problem. Próg ustawiony zbyt ciasno uruchamia się przy każdym zwykłym skoku, a ustawiony zbyt luźno nie uruchamia się nigdy, dopóki nie jest już za późno, żeby miało to znaczenie.

  • Warunek błędu - pokazany na zrzucie ekranu na wartości domyślnej, brak warunku, co oznacza, że monitor tylko raportuje wartość, bez werdyktu Down. Wybór równy, różny od, mniejszy niż albo większy niż odsłania jedno pole liczbowe na limit; wybór wewnątrz zakresu albo poza zakresem odsłania dwa, dolny i górny limit.
  • Przeciążenia przed Down - pojawia się, gdy tylko wybrany zostanie jakikolwiek warunek inny niż "brak warunku". To suwak od 0 do 20: liczba kolejnych sprawdzeń, które muszą już naruszać warunek, zanim monitor przełączy się na Down. Przy 0 pojedynczy odczyt naruszający próg liczy się od razu; przy 3, na przykład, potrzebne są trzy kolejne sprawdzenia powyżej limitu. HostTracker ocenia to centralnie, nie obserwowana maszyna, i to decyduje, czy monitor jest przydatny, czy stale krzyczy fałszywy alarm. Serwer, którego obciążenie CPU skacze na kilka sekund kilka razy na godzinę, potrzebuje debouncingu powyżej 0, inaczej każdy zwykły skok staje się alertem.

Wybór samego progu to decyzja zależna od tego, co obserwujesz. Nie ma jednej właściwej liczby, więc poświęć temu prawdziwą uwagę, zamiast zostawiać wartość domyślną. Jedna przydatna właściwość tego sprawdzenia: nieudane pobranie (kolektor jest nieosiągalny, przekracza limit czasu albo zwraca coś niemożliwego do zinterpretowania) jest raportowane jako błąd natychmiast i nigdy nie liczy się do powyższego debouncingu, więc niestabilne połączenie z kolektorem nie może spełnić licznika kolejnych przeciążeń przeznaczonego dla prawdziwego obciążenia zasobów.

Subskrypcje alertów

Sekcja subskrypcji alertów z włączonym przełącznikiem Zasubskrybuj wszystkie kontakty do zdarzeń Up/Down oraz listą kontaktów pokazującą zaznaczone kolumny Down i Up dla jednego kontaktu e-mail

Wybierz, które kontakty dowiedzą się o tym monitorze i przy jakich zdarzeniach: Up, Down i Repeat (powtarzane przypomnienie, dopóki sprawdzenie pozostaje w stanie Down). Jeden przełącznik subskrybuje wszystkie kontakty do Up/Down naraz, albo wybierz pojedyncze kontakty i zdarzenia z tabeli poniżej.

Subskrypcje raportów

Sekcja subskrypcji raportów z włączonym przełącznikiem Zasubskrybuj wszystkie kontakty do raportów tygodniowych/miesięcznych oraz kontaktem pokazującym zaznaczone kolumny Tygodniowo i Miesięcznie

Niezależnie od alertów wybierz, kto otrzymuje okresowe raporty dla tego monitora - Dziennie, Tygodniowo albo Miesięcznie - e-mailem.

Przykład zastosowania

Obserwowanie miejsca na dysku na serwerze Linux, na którym już działa PHP: rozpakuj gotowy kolektor PHP na serwerze i potwierdź, że jest osiągalny pod własnym adresem URL. Ustaw Dostawcę wartości na opcję kolektora PHP, URL monitora na bazowy adres witryny, Typ licznika na użycie dysku lub systemu plików %, a ścieżkę systemu plików na /dev/sda1. Ustaw Warunek błędu na większy niż, z limitem 90 (procent), a Przeciążenia przed Down na 3, więc potrzebne są trzy kolejne odczyty powyżej 90%, zanim uruchomi się alert. Krótki skok od zadania kopii zapasowej go nie uruchomi, ale trwałe zapełnianie się - tak. Interwał to 10 minut, a CPU i RAM dostają własne, osobne monitory na tym samym serwerze z tym samym kolektorem.

Rozwiązywanie problemów

  • Kolektor jest nieosiągalny. Hosta bez żadnego dostępu przychodzącego nie da się odpytać. Potwierdź, że endpoint odpowiada spoza Twojej własnej sieci, pod trudną do odgadnięcia ścieżką, jeśli obawiasz się ekspozycji, bo nie przyjmuje żadnych poleceń i niczego nie zmienia.
  • Monitor alarmuje przy wyraźnie błędnej liczbie. Sprawdzenie raportuje to, co raportuje kolektor. Napraw endpoint i rozważ, żeby zamiast złej liczby raportował opcjonalny ciąg błędu, gdy po jego stronie coś pójdzie nie tak.
  • Alerty uruchamiają się przy każdym drobnym skoku. Podnieś Przeciążenia przed Down, a nie sam próg. Pozostawienie go na 0 sprawia, że liczy się każdy pojedynczy skok.
  • Kolektor PHP raportuje "shell_exec is denied on server." Odczyty CPU, RAM i dysku wszystkie wywołują polecenia systemowe przez powłokę, więc potwierdź, że shell_exec nie jest na liście wyłączonych funkcji w php.ini.
  • Sprawdzenie licznika wydajności Windows kończy się błędem. Tożsamość puli aplikacji potrzebuje uprawnień do odczytu liczników wydajności i rejestru; jeśli to jeszcze nie Network Service, spróbuj ją na to ustawić.

Powiązane

Sprawdź teraz

Uruchom darmowe sprawdzenie na swojej stronie - bez zakładania konta.

Cpu ram disk loads

Monitoruj to na stałe

Otrzymasz powiadomienie w chwili awarii: HostTracker sprawdza z ponad 300 lokalizacji i powiadamia e-mailem, SMS-em, przez Slack, Telegram i nie tylko.

Funkcje HostTracker

Więcej w tej sekcji: Przewodniki po monitoringu: każdy typ kontroli krok po kroku