Monitorowanie serwera: kontrola obciążenia CPU, RAM i dysku
Monitorowanie serwera HostTracker śledzi obciążenie CPU, RAM i dysku HDD w czasie rzeczywistym. Monitoruje obciążenie procesora, zużycie pamięci i obciążenie dysku, pomagając zoptymalizować wydajność serwera i komfort użytkowników.
Wykrywaj problemy z zasobami, zanim spowodują przestój
Śledzenie obciążenia CPU
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.
Trendy zużycia pamięci
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.
Alerty o miejscu na dysku
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ą.
Jak liczby trafiają do HostTracker - bez żadnego agenta na Twoim serwerze
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ść.
Kolektor PHP
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ą.
Kolektor ASP.NET
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.
Twój własny endpoint
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.
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.
Co może mierzyć monitor serwera
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.
Pisanie własnego kolektora
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.
Ustawianie progu, który coś znaczy
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:
- większe niż lub mniejsze niż limit - forma stosowana na co dzień. CPU powyżej 90. Wolne miejsce na dysku poniżej 10.
- równe lub różne od limitu - dla wartości, która w rzeczywistości jest stanem: liczba workerów, która musi pozostać na poziomie 4, flaga, która musi pozostać na 0.
- wewnątrz zakresu lub poza zakresem, z dwoma limitami - właściwy kształt dla wszystkiego, co ma zdrowy przedział, a nie tylko zdrowe maksimum. Kolejka, która normalnie mieści się między 10 a 500, mówi Ci coś, gdy pokazuje 0, i coś innego, gdy pokazuje 5000.
- brak warunku - zbieraj i nanoś wartość na wykres, nigdy nie kończąc testu niepowodzeniem. Przydatne dla metryki, dla której chcesz mieć historię, zanim będziesz wiedzieć, jak wygląda „źle”.
Debounce to ustawienie, które wycisza szum
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.
Przed czym ostrzega każda metryka
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.
Czytaj trend, a nie tylko alert
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ć.
Monitorowanie serwera i monitorowanie dostępności odpowiadają na różne pytania
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.
SNMP, dla sprzętu, który nigdy nie uruchomi kolektora
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.
Konfiguracja monitorowania serwera
- Zdecyduj, co udostępnić. Jeśli Twój serwer już uruchamia PHP lub IIS, pasujący gotowy kolektor to najszybsza droga; w przeciwnym razie napisz endpoint samodzielnie - zwraca on jedną liczbę.
- Wdróż go na serwerze, który chcesz obserwować, i potwierdź, że sam możesz wysłać do niego żądanie. Umieść go pod trudną do odgadnięcia ścieżką. Jeśli maszyna jest nowa, bezpłatny test portu TCP i bezpłatny test ping to szybki sposób, by potwierdzić, że jest osiągalna ze świata zewnętrznego, zanim pójdziesz dalej - logowanie nie jest wymagane.
- Dodaj monitor typu Monitorowanie CPU, RAM, HDD, wybierz, którą wartość ma odczytywać, i podaj mu adres URL kolektora. Dla monitora dysku podaj ścieżkę lub napęd; dla monitora czasu połączenia z bazą danych podaj dane połączenia, które kolektor ma wybrać.
- Ustaw warunek i limity - a licznik przeciążeń przed awarią ustaw świadomie, zamiast zostawiać go na wartości domyślnej. To ustawienie decyduje o tym, czy monitor jest użyteczny, czy ignorowany.
- Wybierz interwał, od jednej minuty do 24 godzin. Jedna minuta pasuje do maszyny obsługującej coś o krytycznym znaczeniu biznesowym; 5 lub 10 minut w zupełności wystarcza dla trendu takiego jak wykorzystanie dysku.
- Powtórz to dla każdej wartości, która ma znaczenie na tym hoście - CPU, pamięć i wolumen, który najprawdopodobniej się zapełni, to sensowny zestaw początkowy - a następnie dodaj kontakty, które powinny się o tym dowiedzieć.
- Odczekaj tydzień, zanim cokolwiek dostroisz. Pierwszy tydzień historii mówi Ci, czy Twój próg jest właściwy, i jest znacznie lepszym dowodem niż domysł z pierwszego dnia.
Ograniczenia, które warto znać
- Kolektor musi być osiągalny. Hosta bez jakiegokolwiek dostępu przychodzącego nie da się odpytywać. Tym, co trzeba udostępnić, jest jeden adres URL tylko do odczytu, a nie port administracyjny - ale musi on być udostępniony.
- Jeden monitor obserwuje jedną wartość. CPU, pamięć i dysk to trzy monitory, każdy z własnym progiem i własną historią. To właśnie sprawia, że alertowanie jest precyzyjne, ale oznacza też, że zajęty serwer zużywa kilka miejsc na monitory.
- Liczniki wydajności Windows wymagają kolektora ASP.NET. Trójka kategoria / nazwa / instancja jest odczytywana lokalnie przez ten kolektor; host PHP zamiast tego raportuje CPU, pamięć, dysk i czasy połączenia.
- Nie ma potwierdzenia z wielu lokalizacji. W przeciwieństwie do testu dostępności, metryka serwera pochodzi z jednego autorytatywnego źródła, więc pojedynczy nietypowy odczyt jest odczytem prawdziwym. Narzędziem na tę okoliczność jest licznik kolejnych przeciążeń i warto go ustawić.
- Raportuje to, co raportuje kolektor. Jeśli Twój niestandardowy endpoint ma błąd, monitor wiernie alarmuje na podstawie błędnej liczby - dlatego właśnie ma znaczenie opcjonalne pole błędu w odpowiedzi: zgłoś błąd, zamiast zgłaszać zero.
- Brak licznika przepustowości sieci. Dostępne wartości to CPU, pamięć, wykorzystanie dysku, czasy połączenia i liczniki wydajności Windows; przepustowość nie znajduje się wśród nich. Dla urządzenia, które raportuje przepustowość przez SNMP, test SNMP może odczytać i nanieść na wykres ten licznik.
Najczęściej zadawane pytania
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 13 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.
Odkryj więcej monitoringu HostTracker
Monitoruj połączenia z bazą danych i wyniki zapytań
Uruchamiaj okresowe kontrole połączenia i waliduj wyniki zapytań w MySQL, PostgreSQL, SQL Server i innych, dzięki czemu cichy problem z bazą danych nigdy nie pozostanie niezauważony.
Poznaj wszystkie funkcje monitorowania HostTracker
Porównaj wszystkie 8 typów monitorowania obok siebie i dobierz kontrole pasujące do Twojej strony.
Wykryj przeciążenie serwera, zanim spowoduje awarię
Rozpocznij bezpłatny okres próbny i otrzymuj alerty, gdy obciążenie CPU, RAM lub dysku przekroczy ustalone progi.
Część usługi monitorowania stron internetowych HostTracker.