Monitorowanie obciążenia serwera
Monitoring serwera HostTracker odczytuje obciążenie CPU, RAM i dysku z Twojego serwera Linux lub Windows przez lekki punkt kolektora lub SNMP, tworzy wykres trendu i alarmuje, gdy ustalony przez Ciebie próg zostanie przekroczony, zanim serwer się przeciąży.
Jak przebiega jedno sprawdzenie obciążenia serwera - od kolektora do alertu
Wybierzcie Państwo jeden; nic nie jest wysyłane do Państwa maszyny.
Gotowy skrypt dla hosta z systemem Linux lub Unix, na którym już działa PHP. Umieść go w katalogu serwowanym przez serwer WWW i skieruj monitor na ten bazowy adres URL. Odczytuje lokalnie własne wartości CPU, pamięci i dysku maszyny i odpowiada podaną liczbą.
Odpowiednik dla Windows, dla hosta z uruchomionym IIS. Ta sama idea, plus dostęp do dowolnego licznika wydajności Windows według kategorii, nazwy i instancji - dzięki czemu wszystko, co lokalnie pokazuje Podgląd wydajności, można monitorować zdalnie.
Skieruj monitor na dowolny adres URL i odpowiadaj niewielkim obiektem JSON. Dziesięć linijek w dowolnym języku, nic na Twoim serwerze, czego sam nie napisałeś, i to Ty decydujesz, które dokładnie liczby są udostępniane. To opcja, którą ostatecznie preferuje większość zespołów inżynierskich.
HostTracker monitoruje wykorzystanie CPU, aby serwery działały wydajnie i stabilnie. Śledzi wykorzystanie procesora Twojego serwera, wykrywając problemy i ostrzegając o nietypowych skokach obciążenia. Monitorowanie obciążenia CPU pomaga administratorom utrzymać płynne działanie serwerów i zapobiegać przestojom.
HostTracker monitoruje zużycie pamięci, aby pomóc utrzymać wydajność serwera. Ta funkcja śledzi zużycie pamięci i wykrywa trendy, które mogą powodować spowolnienia lub awarie. Raporty i alerty pomagają administratorom lepiej zarządzać pamięcią. Dobre monitorowanie RAM oznacza, że aplikacje działają sprawnie i nie ma niespodzianek związanych z problemami pamięci.
Monitorowanie dysku HDD przez HostTracker zapobiega problemom z pamięcią masową wpływającym na wydajność serwera. Usługa śledzi wykorzystanie miejsca na dysku i ostrzega administratorów, aby zapobiec problemom takim jak niewystarczająca ilość miejsca czy awarie dysku. Monitorowanie i raportowanie pomagają na bieżąco kontrolować problemy z miejscem na dysku, dzięki czemu serwer zawsze ma wystarczająco przestrzeni do sprawnego działania. To pomaga utrzymać niezawodność serwerów i zapobiega utracie danych z powodu problemów z pamięcią masową.
Wartość dla każdego sprawdzenia na tle obu progów, dzięki czemu trend jest widoczny na długo przed alertem.
CPU, RAM lub dysk w czasie z naniesionymi liniami ostrzegawczą i krytyczną - zapełniający się dysk to nachylenie krzywej, a nie niespodzianka.
Poziom ostrzegawczy i krytyczny docierają do własnych kontaktów, po osiągnięciu ustawionej przez Państwa liczby nieudanych sprawdzeń.
Strony, serwery, API, certyfikaty. Jeden typ kontroli na stronę, za wszystkimi te same lokalizacje, alerty i raporty.
"Korzystam z tej usługi monitorowania od dawna i moja codzienna rutyna przestała być problemem. Cicho obserwuje wszystkie moje strony i pozwala mi zareagować w chwili, gdy coś pójdzie nie tak."
Zaufały nam zespoły z
Każdy rozdział otwiera się w miejscu, dzięki czemu strona pozostaje krótka.
Większość produktów do monitorowania serwerów wymaga zainstalowania agenta: procesu działającego w tle, z dostępem na poziomie systemu, uruchomionego na stałe na Twojej maszynie i strumieniującego dane na zewnątrz. HostTracker celowo tego nie robi. To zewnętrzna usługa monitorująca, a kontrola obciążenia serwera działa odwrotnie - Twój serwer udostępnia jeden mały endpoint tylko do odczytu, który zwraca pojedynczą liczbę, a HostTracker odpytuje go zgodnie z ustawionym przez Ciebie harmonogramem.
To odwrócenie jest całą istotą projektu. Nie ma demona, który trzeba utrzymywać przy życiu, nie ma uprzywilejowanego oprogramowania, którego sam nie napisałeś, działającego na produkcji, nie ma danych uwierzytelniających przekazywanych stronie trzeciej i nie ma przychodzącego portu administracyjnego. To, co udostępniasz, to adres URL, który nie przyjmuje żadnych poleceń, niczego nie zmienia i zwraca jedną wartość.
Nic nigdy nie jest wypychane na Twoją maszynę. Kolektor wdrażasz Ty, kiedy chcesz, a HostTracker jedynie wysyła do niego żądania. Jeśli go usuniesz, monitorowanie się zatrzymuje - nie ma żadnej innej drogi dostępu.
Każdy monitor obserwuje jedną wartość, więc typowy serwer kończy z trzema lub czterema takimi monitorami - a każdy z nich ma własny próg, własną historię i własny alert. Rodzaje wartości to:
| Metryka | Raportowana jako | Do czego się przydaje |
|---|---|---|
| CPU | Procent wykorzystania | Utrzymujące się nasycenie, procesy wymykające się spod kontroli, zbyt małe instancje, obciążenie dodane przez wdrożenie |
| RAM | Procent wykorzystania | Wycieki pamięci, pełzające zużycie między restartami, presja poprzedzająca zabicie procesu z powodu braku pamięci |
| Dysk | Procent wykorzystania dla wskazanej ścieżki lub dysku | Logi, przesyłane pliki i kopie zapasowe zapełniające wolumen - najwolniejsza i najbardziej przewidywalna awaria, jaka istnieje |
| Port TCP | Czas połączenia w milisekundach | Czy usługa na maszynie nadal przyjmuje połączenia i jak szybko |
| SQL Server | Czas połączenia w milisekundach | Osiągalność bazy danych i uwierzytelnianie z punktu widzenia samego serwera |
| MySQL | Czas połączenia w milisekundach | To samo, dla MySQL |
| Licznik wydajności Windows | To, co raportuje dany licznik | Wszystko, co udostępnia Podgląd wydajności, według kategorii, nazwy licznika i instancji - długości kolejek, uchwyty, wartości dla poszczególnych procesów |
Jeśli potrzebujesz raczej samej bazy danych stojącej za serwerem niż jej czasu połączenia, to inna, głębsza kontrola: monitor zapytań do bazy danych łączy się, uwierzytelnia, uruchamia napisane przez Ciebie zapytanie i porównuje zwróconą wartość z progiem.
Kontrakt jest celowo trywialny, ponieważ chodzi o to, byś mógł go przeczytać za jednym razem i zaimplementować w dowolnym języku, którego Twój zespół już używa. HostTracker wysyła żądanie do Twojego adresu URL; Twój endpoint odpowiada obiektem JSON niosącym wartość:
{ "v": 42.7 }To cała wymagana powierzchnia. Dwa opcjonalne pola czynią wynik bardziej użytecznym: e
niesie ciąg tekstowy błędu, gdy wartości nie udało się tym razem odczytać - to dużo lepszy wynik niż
zgłoszenie mylącego zera - a vs niesie własny ciąg wersji, który pojawia się w wyniku,
dzięki czemu wiesz, która wersja kolektora odpowiedziała.
{ "v": 91.4, "e": "", "vs": "collector-2.1" }Ponieważ sam piszesz odczyt, nie jesteś ograniczony do tego, co potrafi zebrać generyczny agent. Głębokość kolejki, współczynnik trafień pamięci podręcznej, liczba oczekujących zadań, wiek najstarszego nieprzetworzonego rekordu, wolne i-węzły, rozmiar katalogu, który nigdy nie może urosnąć - wszystko, co da się wyrazić liczbą, staje się monitorowaną wartością z dołączonymi do niej progami, historią i alertowaniem.
Zabezpiecz endpoint. Musi być osiągalny dla checkerów, które go wywołują, więc traktuj go jak każdy inny publiczny adres URL: umieść go pod trudną do odgadnięcia ścieżką, zachowaj go tylko do odczytu i udostępniaj wyłącznie te liczby, których odczytanie Ci nie przeszkadza. Nie przyjmuje żadnych parametrów, które cokolwiek zmieniają, dzięki czemu ekspozycja ogranicza się dokładnie do jednej wartości.
Surowa liczba to dane; to próg zamienia je w monitorowanie. Każdy monitor niesie warunek oraz jeden lub dwa limity, dzięki czemu możesz wyrazić kształt „niewłaściwej” wartości, a nie tylko pojedynczy sufit:
Obok progu znajduje się licznik kolejnych przeciążonych kontroli, zanim monitor uzna stan za awarię, regulowany od zera do dwudziestu. To pojedynczo najbardziej wartościowe pokrętło na tej stronie i jednocześnie to, które najczęściej pozostaje nietknięte. Serwer przy 95% CPU w jednym pomiarze podczas nocnego backupu to nie incydent. Serwer przy 95% przez pięć kolejnych kontroli - już tak. Ustaw licznik tak, by odpowiadał temu, jak długo Twoje obciążenie może być zajęte w sposób uzasadniony, a cała kategoria fałszywych alarmów o 3 nad ranem zniknie bez osłabiania Twojego progu.
Ma to tu większe znaczenie niż w przypadku testu webowego, ponieważ metryka serwera jest odczytywana z jednego autorytatywnego źródła - Twojego własnego kolektora - a nie potwierdzana przez kilka niezależnych checkpointów, tak jak dzieje się to w teście dostępności. Nie ma drugiej opinii, która uśredniłaby chwilowy skok, więc rolę tę odgrywa właśnie licznik debounce.
Trzy podstawowe metryki zawodzą w naprawdę różny sposób, a wiedza o tym, na którą z nich patrzysz, mówi Ci, ile masz czasu.
| Metryka | Jak przebiega awaria | Ile masz ostrzeżenia |
|---|---|---|
| CPU | Nic się nie psuje. Wszystko zwalnia - każde żądanie, każde zapytanie, każde zadanie w tle - a witryna degraduje się na długo, zanim ostatecznie padnie. | Zwykle sporo, jeśli obserwujesz. Utrzymujący się wzrost jest widoczny przez godziny lub dni, zanim stanie się zauważalny dla użytkowników. |
| RAM | Nagła i gwałtowna. Aplikacje są zabijane przez system operacyjny w celu odzyskania pamięci, restartują się i są zabijane ponownie - co daje dokładnie tę przerywaną, nie do odtworzenia awarię, którą najtrudniej zdiagnozować. | Niewiele, na koniec. Ale powolny wzrost wycieku pamięci między restartami to jeden z najbardziej czytelnych sygnałów w monitorowaniu, jeśli tylko istnieje jego historia. |
| Dysk | Wszystko naraz. Logi przestają się zapisywać, baza danych odmawia zapisów, sesje zawodzą, nie da się utworzyć plików tymczasowych - a przyczyna jest niewidoczna we własnych komunikatach błędów aplikacji. | Najwięcej ostrzeżenia ze wszystkich i najczęściej przeoczane. Wolumen zapełniający się w stałym tempie jest przewidywalny z wielodniowym wyprzedzeniem. |
| Czas połączenia | Zależność, na której polega serwer, stała się wolna lub nieosiągalna, zanim objawiło się to jako pełna awaria. | Często najwcześniejszy sygnał, że coś dalej w łańcuchu jest nie tak. |
Dysk zasługuje na swoją reputację klasycznej, możliwej do uniknięcia awarii. To ta jedna awaria, którą monitor z progiem i tygodniem historii zawsze wykryje pierwszy, i ta, którą najbardziej wstyd tłumaczyć po fakcie.
Każdy odczyt jest zapisywany, więc każdy monitor serwera ma własny wykres wartości w czasie, ze średnią, minimum i maksimum dla przeglądanego okna. Procenty są nanoszone na wykres jako procenty, a czasy połączenia jako milisekundy, więc monitor CPU i monitor opóźnienia bazy danych czyta się tak, jak można się tego spodziewać.
Alert mówi Ci, że coś przekroczyło linię; wykres mówi Ci dwie rzeczy, których naprawdę potrzebujesz później. Czy to coś nowego? - skok, który w izolacji wygląda alarmująco, często jest tym samym skokiem, który zdarza się co wtorek o 2:00 od roku. Oraz dokąd to zmierza? - wartość pamięci rosnąca stabilnie między restartami to wyciek, niezależnie od jej bieżącej wartości, a dysk rosnący o dwa procent tygodniowo ma przypisaną datę.
To drugie pytanie to zastosowanie monitorowania serwera do planowania pojemności, i to właśnie powód, by zacząć zbierać metrykę, zanim będziesz wiedzieć, jaki próg na niej ustawić. Próg możesz dodać za miesiąc, gdy historia powie Ci już, jak wygląda normalny stan. Historii, której nie zebrałeś, nie da się odzyskać.
Uzupełniają się nawzajem, a nie są dla siebie alternatywą, a podział jest na tyle wyraźny, że warto go jasno przedstawić.
| Monitorowanie dostępności | Monitorowanie serwera | |
|---|---|---|
| Na jakie pytanie odpowiada | Czy odwiedzający może teraz dotrzeć do witryny? | Czy maszyna pod spodem jest wystarczająco zdrowa, by nadal odpowiadać? |
| Skąd patrzy | Z zewnątrz - ponad 300 checkpointów w 158 miastach | Od wewnątrz - wartość odczytana na samej maszynie |
| Typowy moment | Informuje w chwili awarii | Informuje przed awarią, jeśli ustawisz próg poniżej krytycznej granicy |
| Kontrola fałszywych alarmów | Nieudana obserwacja jest ponownie sprawdzana z innych checkpointów i potwierdzana przez kworum | Pojedynczy autorytatywny odczyt, z licznikiem kolejnych przeciążeń jako debounce |
| Wykrywa wyciek pamięci | Nie - dopóki w końcu coś nie ulegnie awarii | Tak - jako trend, tygodnie wcześniej |
| Wykrywa awarię trasy sieciowej między Twoimi użytkownikami a Tobą | Tak | Nie - maszyna czuje się doskonale |
Uruchamianie tylko jednego z nich zostawia realną lukę w obu kierunkach. Połączenie, na którym osiada większość kont, to jednominutowy test dostępności z wielu lokalizacji plus kilka monitorów serwera dla CPU, pamięci i wolumenu, który najprawdopodobniej się zapełni.
Routery, przełączniki, zapory sieciowe, zasilacze UPS i drukarki nie mogą hostować skryptu, ale niemal wszystkie z nich mówią już SNMP. Osobny test SNMP odczytuje wartość liczbową bezpośrednio z urządzenia po OID - liczniki interfejsów, temperaturę, obciążenie, czas działania, poziom naładowania baterii - przez SNMP v1, v2c lub v3, w tym v3 z uwierzytelnianiem i szyfrowaniem, dzięki czemu dane uwierzytelniające nie są wysyłane jawnym tekstem.
Mówiąc wprost, gdzie to dziś stoi: test SNMP odczytuje i zapisuje wartość raportowaną przez urządzenie. Alertowanie oparte na progach dla wartości SNMP nie jest jeszcze dostępne - gdy potrzebujesz, aby liczba faktycznie zgłaszała incydent, użyj monitora obciążenia serwera opartego na kolektorze, który ma pełny model warunków i debounce opisany powyżej.
Monitorowanie serwera to ciągłe śledzenie podstawowego wykorzystania zasobów serwera - obciążenia CPU, zużycia RAM (pamięci) oraz obciążenia dysku HDD - dzięki czemu widzisz, jak faktycznie działa Twoja infrastruktura, a nie tylko czy strona internetowa na niej działająca odpowiada. Monitorowanie serwera HostTracker sprawdza te trzy metryki i raportuje trendy oraz skoki w czasie, co ma znaczenie, ponieważ wyczerpanie zasobów jest jedną z najczęstszych przyczyn wolnego działania, awarii i całkowitych przestojów. Serwer może być technicznie „dostępny” i mimo to o krok od awarii, jeśli wykorzystanie CPU jest na maksimum, pamięć jest niemal wyczerpana lub ilość wolnego miejsca na dysku jest krytycznie niska - a zwykła kontrola dostępności niekoniecznie to wykryje, dopóki problem nie spowoduje widocznej awarii.
Serwer może pozostawać dostępny i technicznie działać online, choć pracuje niebezpiecznie blisko granic swoich zasobów, co oznacza, że wysokie zużycie CPU lub RAM jest często wczesnym sygnałem ostrzegawczym problemu, a nie samym problemem. Utrzymujące się wysokie obciążenie CPU spowalnia obsługę każdego żądania kierowanego do serwera, pogarszając doświadczenie każdego odwiedzającego, mimo że strona nigdy całkowicie nie przestaje działać. Presja na pamięć jest jeszcze groźniejsza - gdy zużycie RAM zbliża się do limitu, aplikacje mogą zacząć się zawieszać, restartować lub być zamykane przez system operacyjny w celu zwolnienia pamięci, co często powoduje przerywane, trudne do zdiagnozowania awarie przypominające przypadkowe usterki, a nie wyraźną awarię. Wychwycenie podwyższonego zużycia CPU lub RAM dzięki monitorowaniu serwera, zanim przerodzi się ono w awarię, daje administratorom czas na zbadanie sytuacji i proaktywne zwiększenie zasobów.
Gdy monitorowanie CPU, RAM lub dysku wykryje nietypową aktywność - utrzymujący się skok, pamięć zbliżającą się do limitu lub kończące się miejsce na dysku - HostTracker wysyła powiadomienie przez wybrany ze skonfigurowanych przez Ciebie 9 kanałów alertów, w tym e-mail, SMS, połączenie głosowe, webhooki, Slack oraz komunikatory takie jak Telegram, Discord i Viber. Oznacza to, że osoba odpowiedzialna za infrastrukturę serwerową dowiaduje się o narastającym problemie z zasobami od razu, a nie dopiero wtedy, gdy spowoduje on już spowolnienie lub awarię zauważoną przez klientów. Ponieważ raporty i alerty są generowane automatycznie na podstawie monitorowanych danych, administratorzy otrzymują udokumentowaną historię trendów zasobów wraz z powiadomieniem w czasie rzeczywistym, co pomaga odróżnić jednorazowy skok od faktycznego problemu z przepustowością wymagającego długoterminowego rozwiązania.
Monitorowanie dostępności (uptime) odpowiada na węższe pytanie: czy strona lub usługa jest teraz osiągalna i odpowiada. Monitorowanie serwera zagląda głębiej, pod tę powierzchnię, do infrastruktury, na której faktycznie działa strona - obciążenia CPU, zużycia pamięci i miejsca na dysku - które często są główną przyczyną awarii dostępności, a nie odrębnym, niepowiązanym problemem. Serwer, któremu kończy się pamięć lub miejsce na dysku, może przez pewien czas nadal przechodzić kontrolę uptime, zanim ostatecznie ulegnie awarii lub drastycznie zwolni, więc poleganie wyłącznie na monitorowaniu dostępności oznacza, że o problemie dowiesz się dopiero wtedy, gdy stanie się on już przestojem. Połączenie obu daje pełniejszy obraz: monitorowanie dostępności potwierdza, że strona jest obecnie osiągalna, a monitorowanie serwera śledzi leżące u podstaw trendy zasobów, które pozwalają przewidzieć, czy tak pozostanie.
Częstotliwość kontroli jest konfigurowalna, tak aby dopasować ją do tego, jak szybko potrzebujesz wiedzieć o narastającym problemie z zasobami. Płatne plany HostTracker obsługują interwały monitorowania nawet co minutę, co jest przydatne dla serwerów obsługujących aplikacje o krytycznym znaczeniu biznesowym, gdzie skok obciążenia trzeba wychwycić i obsłużyć szybko. Mniej krytyczne lub rzadziej odwiedzane serwery mogą korzystać z dłuższego interwału, a bezpłatny plan na stałe pozwala monitorować dwa monitory co 30 minut, co często wystarcza, by wychwycić utrzymujący się trend, taki jak stopniowe zapełnianie się dysku w ciągu kilku dni, nawet jeśli nie wykryje bardzo krótkotrwałego skoku CPU. 30-dniowy pełnofunkcyjny okres próbny bez karty kredytowej pozwala wypróbować szybsze interwały kontroli i zobaczyć, ile szczegółów dają uzyskane dane, zanim wybierzesz plan.
Nie - nie ma żadnego agenta HostTracker do zainstalowania, żadnego demona, który musiałby stale działać, ani żadnych danych uwierzytelniających do przekazania. Kontrola obciążenia serwera działa odwrotnie: Twój serwer udostępnia jeden mały, tylko-do-odczytu endpoint, który zwraca pojedynczą liczbę, a HostTracker odpytuje go zgodnie z ustawionym przez Ciebie harmonogramem. Masz trzy sposoby, by go dostarczyć. Dwa to gotowe skrypty kolektora, które umieszczasz na serwerze, który już prowadzisz - jeden dla PHP na Linuksie lub Unixie, jeden dla ASP.NET na IIS - a trzeci to napisanie endpointu samodzielnie, co zajmuje około dziesięciu linijek w dowolnym języku: odczytaj wartość w dowolny sposób i odpowiedz małym obiektem JSON, który ją zawiera. Ta trzecia opcja jest tą, którą preferuje wiele zespołów, ponieważ oznacza, że na ich maszynie nigdy nie działa nic, czego sami nie napisali, i to oni decydują, które dokładnie liczby są udostępniane. Nic nigdy nie jest automatycznie wypychane na Twój serwer, a HostTracker nigdy nie otwiera na nim sesji administracyjnej.
Endpoint kolektora musi być osiągalny dla checkerów HostTracker, więc serwera za zaporą sieciową bez jakiegokolwiek dostępu przychodzącego nie da się odpytywać bezpośrednio. W praktyce jest to mniejsza przeszkoda, niż się wydaje, ponieważ tym, co trzeba udostępnić, jest pojedynczy adres URL tylko do odczytu, zwracający jedną liczbę - a nie SSH, nie port administracyjny, nie protokół monitorujący. Zwykłe podejścia to opublikowanie endpointu pod trudną do odgadnięcia ścieżką, ograniczenie go do adresów, które go wywołują, albo hostowanie go na maszynie w tej samej sieci, która jest już widoczna z internetu, i zlecenie jej raportowania w imieniu prywatnego hosta. Cokolwiek wybierzesz, zakres ekspozycji jest celowo minimalny: endpoint nie przyjmuje żadnych poleceń, niczego nie zmienia i zwraca pojedynczą liczbę. To zupełnie inna rozmowa o bezpieczeństwie niż instalacja agenta zewnętrznego z dostępem na poziomie systemu, i dokładnie dlatego ta kontrola została tak zaprojektowana.
Monitorowanie obciążenia serwera - kontrola CPU, RAM i dysku HDD - to jeden z 14 typów kontroli dostępnych w produkcie HostTracker, a bezpłatny plan na stałe pozwala monitorować dwa serwery lub strony bez opłat, z kontrolami co 30 minut. HostTracker jako całość nie jest produktem wyłącznie bezpłatnym - to płatna usługa monitorowania z towarzyszącym jej bezpłatnym planem - dlatego plan darmowy dobrze sprawdza się przy wypróbowywaniu monitorowania serwera na kilku maszynach lub jako lekka opcja dla mniejszych projektów, a nie jako główna oferta. Do monitorowania większej liczby serwerów, krótszych interwałów kontroli lub infrastruktury o krytycznym znaczeniu biznesowym, gdzie liczy się szybsze wykrywanie, płatne plany zaczynają się od $5 miesięcznie, a 30-dniowy pełnofunkcyjny okres próbny bez karty kredytowej pozwala przetestować szybsze interwały przed podjęciem decyzji.
Rozpocznij bezpłatny okres próbny i otrzymuj alerty, gdy obciążenie CPU, RAM lub dysku przekroczy ustalone progi.
Część oprogramowania do monitoringu stron www HostTracker.