Přejít na hlavní obsah

Monitoring zátěže serveru

Software pro monitoring serverů: kontroly CPU, RAM, disku a SNMP

Monitoring serveru od HostTracker čte zátěž CPU, RAM a disku z vašeho serveru Linux nebo Windows přes malý kolektor nebo SNMP, zobrazuje trend v grafu a upozorní vás, jakmile je překročen vámi nastavený práh, dřív, než se server zhroutí.

  • Důvěryhodní od roku 2004
  • 500 000+ sledovaných webů
  • 300+ kontrolních bodů po celém světě

Jak probíhá jeden test zátěže serveru, od sběrače po alert

Žádný agent na vašem serveruVáš server vystaví jeden koncový bod jen pro čtení, který vrátí číslo. HostTracker se na něj dotazuje podle vašeho plánu.
CPU, RAM, disk a dalšíZátěž, paměť, místo na disku, doba připojení portu, doba odezvy databáze nebo jakýkoli výkonnostní čítač Windows.
Dva prahy, jeden alertVarovná úroveň a kritická úroveň, kontrolované každou 1 minutu až 24 hodin, s prodlevou proti kolísání, aby jeden výkyv nikoho nevzbudil.

Tři způsoby, jak zpřístupnit číslo

Vyberte jeden; na váš stroj se nic neodesílá.

Možnost 1

PHP kolektor

Hotový skript pro Linux nebo Unix host, na kterém už běží PHP. Vložte ho do adresáře obsluhovaného webem a monitor namiřte na tuto základní URL. Lokálně přečte vlastní čísla CPU, paměti a disku stroje a odpoví hodnotou.

Možnost 2

ASP.NET kolektor

Windows ekvivalent, pro host s IIS. Stejná myšlenka, navíc s přístupem k libovolnému výkonnostnímu čítači Windows podle kategorie, jména a instance - takže cokoli vám lokálně ukáže Performance Monitor, lze sledovat vzdáleně.

Možnost 3

Vlastní endpoint

Namiřte monitor na libovolnou URL a odpovězte drobným JSON objektem. Deset řádků v jakémkoli jazyce, na vašem serveru nic, co jste sami nenapsali, a přesně vy rozhodujete, jaká čísla jsou vystavená. Tuto možnost nakonec preferuje většina vývojářských týmů.

Monitoring serveru

Místo na disku, CPU a paměť: odhalte problémy se zdroji dřív, než způsobí výpadek

CPU

Sledování zátěže CPU

HostTracker sleduje vytížení CPU, aby servery zůstaly efektivní a stabilní. Sleduje vytížení procesoru vašeho serveru, odhaluje problémy a upozorňuje vás na neobvyklé výkyvy. Monitoring zátěže CPU pomáhá administrátorům udržet servery v hladkém chodu a předcházet výpadkům.

Paměť

Trendy využití paměti

HostTracker sleduje využití paměti, aby pomohl udržet výkon serveru. Tato funkce sleduje využití paměti a odhaluje trendy, které by mohly způsobit zpomalení nebo pády. Reporty a upozornění pomáhají administrátorům zlepšit využití paměti. Dobrý monitoring RAM znamená, že aplikace fungují dobře a nedochází k překvapením kvůli problémům s pamětí.

Disk

Upozornění na místo na disku

Monitoring HDD od HostTracker předchází problémům s úložištěm, které ovlivňují výkon serveru. Tato služba sleduje využití místa na disku a upozorňuje administrátory, aby předešli problémům, jako je nedostatek úložiště nebo selhání disku. Monitoring a reporty vám pomáhají mít přehled o místě na disku, takže váš server má vždy dost prostoru pro plynulý chod. To pomáhá udržet servery spolehlivé a předchází ztrátě dat kvůli problémům s úložištěm.

Co zaznamenává monitor serveru

Hodnota u každého testu vůči oběma prahům, takže trend je vidět dlouho před alertem.

Graf hodnoty

CPU, RAM nebo disk v čase s vykreslenými čarami varovné a kritické úrovně - zaplňující se disk je sklon, ne překvapení.

Alerty podle zvolené úrovně

Varovná a kritická úroveň mají vlastní kontakty, po dosažení počtu neúspěšných testů, který nastavíte.

Statistiky monitoru zátěže serveru HostTracker: hodnota čítače v čase vůči jeho prahům

Každá vrstva vašeho stacku pod dohledem

Weby, servery, API, certifikáty. Jeden typ kontroly na stránku, za všemi stejné lokality, upozornění a reporty.

"S touto monitorovací službou pracuji už dlouho a moje každodenní rutina už není problém. Tiše hlídá všechny moje weby a umožňuje mi zareagovat ve chvíli, kdy se něco pokazí."
Caleb Levy - Webmaster - CA - Trustpilot

Důvěřují nám týmy z

Microsoft Panasonic OTP Bank OneProvider Worldmate
Kompletní průvodce

Monitorování serveru vysvětleno

Každá kapitola se otevře na místě, takže stránka zůstává krátká.

Jak se čísla dostanou k HostTracker - bez agenta na vašem serveru

Většina produktů pro monitoring serverů po vás chce nainstalovat agenta: proces na pozadí s přístupem na úrovni systému, který běží na vašem stroji trvale a odesílá data ven. HostTracker to záměrně nedělá. Jde o externí monitorovací službu a kontrola zátěže serveru funguje opačně - váš server vystaví jeden malý endpoint jen pro čtení, který hlásí jedno číslo, a HostTracker si ho vyžádá v intervalu, který nastavíte.

Toto obrácení je celý návrh. Nemusíte udržovat v chodu žádného démona, na produkci vám neběží žádný privilegovaný software, který jste sami nenapsali, žádné přihlašovací údaje nikomu nepředáváte a žádný příchozí správní port neexistuje. Vystavujete URL, která nepřijímá žádné příkazy, nic neměnící a vrací jednu hodnotu.

Na váš stroj se nikdy nic nepushuje. Kolektor nasazujete vy, kdy sami chcete, a HostTracker na něj jen posílá požadavky. Pokud ho odstraníte, monitoring se zastaví - jinou cestu dovnitř nemá.

Monitoring stavu serveru: co monitor serveru dokáže měřit

Každý monitor sleduje jednu hodnotu, takže typický server nakonec má tři nebo čtyři z nich - a každá má vlastní práh, vlastní historii a vlastní upozornění. Typy hodnot jsou:

MetrikaHlásí se jakoK čemu je dobrá
CPUProcento vytíženíTrvalé nasycení, ujeté procesy, poddimenzované instance, zátěž přidaná nasazením
RAMProcento vytíženíÚnik paměti, plíživá spotřeba mezi restarty, tlak, který předchází ukončení kvůli nedostatku paměti
DiskProcento vytížení pro vámi pojmenovanou cestu nebo jednotkuLogy, uploady a zálohy zaplňující svazek - nejpomalejší a nejpředvídatelnější výpadek, jaký existuje
TCP portČas připojení v milisekundáchZda služba na stroji stále přijímá spojení a jak rychle
SQL ServerČas připojení v milisekundáchDostupnost databáze a autentizace z pohledu samotného serveru
MySQLČas připojení v milisekundáchTotéž, pro MySQL
Výkonnostní čítač WindowsCokoli, co čítač hlásíCokoli, co vystavuje Performance Monitor, podle kategorie, jména čítače a instance - délky front, handly, čísla po jednotlivých procesech

Pokud potřebujete spíš databázi za serverem než jeho čas připojení, jde o jinou a hlubší kontrolu: monitor databázových dotazů se připojí, ověří, spustí dotaz, který sami napíšete, a porovná vrácenou hodnotu s prahem.

Napsání vlastního kolektoru

Kontrakt je záměrně triviální, protože smyslem je, abyste ho přečetli na posezení a implementovali v jakémkoli jazyce, který váš tým už používá. HostTracker si vyžádá vaši URL; váš endpoint odpoví JSON objektem nesoucím hodnotu:

{ "v": 42.7 }

To je celý povinný povrch. Dva volitelné členy dělají výsledek užitečnějším: e nese chybový řetězec, když se hodnotu tentokrát nepodařilo přečíst - mnohem lepší výsledek než nahlásit zavádějící nulu - a vs nese vaši vlastní verzi, která se objeví ve výsledku, takže poznáte, který build kolektoru odpověděl.

{ "v": 91.4, "e": "", "vs": "collector-2.1" }

Protože si čtečku píšete sami, nejste omezeni na to, co umí sbírat obecný agent. Hloubka fronty, poměr zásahů do cache, počet čekajících úloh, stáří nejstaršího nezpracovaného záznamu, volné inody, velikost adresáře, který nikdy nesmí narůst - cokoli, co dokážete vyjádřit číslem, se stane sledovanou hodnotou s prahy, historií a upozorněním.

Endpoint chraňte. Musí být dosažitelný pro kontrolní body, které ho volají, takže s ním zacházejte jako s jakoukoli jinou veřejnou URL: umístěte ho na neuhodnutelnou cestu, udržujte ho jen pro čtení a vystavujte jen čísla, u kterých vám nevadí, že jsou čitelná. Nepřijímá žádné parametry, které by cokoli měnily, takže expozice je omezená přesně na jednu hodnotu.

Nastavení prahu, který něco znamená

Syrové číslo jsou data; práh je to, co je promění v monitoring. Každý monitor nese podmínku a jeden nebo dva limity, takže dokážete vyjádřit tvar toho, co je „špatně“, ne jen strop:

  • větší než nebo menší než limit - běžná podoba. CPU nad 90. Volný disk pod 10.
  • rovná se nebo nerovná se limitu - pro hodnotu, která je vlastně stavem: počet workerů, který musí zůstat na 4, příznak, který musí zůstat na 0.
  • uvnitř rozsahu nebo mimo rozsah, se dvěma limity - správný tvar pro cokoli, co má zdravé pásmo místo zdravého maxima. Fronta, která je normálně mezi 10 a 500, vám něco říká, když ukazuje 0, a něco jiného, když ukazuje 5 000.
  • vůbec žádná podmínka - sbírejte a vykreslujte hodnotu, aniž by kontrola kdy selhala. Užitečné pro metriku, u které chcete nejdřív historii, než poznáte, jak vypadá „špatně“.

Debounce je nastavení, které zastaví šum

Vedle prahu stojí počet po sobě jdoucích přetížených kontrol, než monitor přejde do stavu Down, nastavitelný od nuly do dvaceti. Je to jednotlivě nejcennější přepínač na stránce a zároveň ten nejčastěji ponechaný beze změny. Server na 95 % CPU po dobu jednoho vzorku během noční zálohy není incident. Server na 95 % po pět kontrol za sebou ano. Nastavte počet podle toho, jak dlouho smí být vaše pracovní zátěž legitimně vytížená, a celá kategorie falešných poplachů ve tři ráno zmizí, aniž by váš práh byl o něco méně přísný.

Zde na tom záleží víc než u webové kontroly, protože metrika serveru se čte z jediného autoritativního zdroje - vašeho vlastního kolektoru - místo aby se potvrzovala napříč několika nezávislými kontrolními body, jako je tomu u kontroly dostupnosti. Neexistuje druhý názor, který by zprůměroval chvilkový výkyv, takže tuto roli hraje právě počet debounce.

Před čím vás jednotlivé metriky varují

Tři klíčové metriky selhávají opravdu odlišnými způsoby a vědět, na kterou se díváte, vám řekne, kolik máte času.

MetrikaJak selhání přicházíKolik varování dostanete
CPUNic se nerozbije. Vše se jen zpomaluje - každý požadavek, každý dotaz, každá úloha na pozadí - a web upadá dlouho předtím, než úplně spadne.Obvykle dost, pokud sledujete. Trvalý nárůst je vidět hodiny nebo dny předtím, než si ho všimnou uživatelé.
RAMNáhlé a prudké. Operační systém aplikace ukončuje, aby uvolnil paměť, ty se restartují a jsou znovu ukončeny - což vytváří přesně ten přerušovaný, těžko reprodukovatelný výpadek, který se nejhůř diagnostikuje.Málo, na konci. Ale pomalý nárůst úniku paměti mezi restarty je jeden z nejčitelnějších signálů v monitoringu, pokud existuje historie.
DiskVšechno naráz. Logy přestanou zapisovat, databáze odmítá zápisy, relace selhávají, dočasné soubory nelze vytvořit - a příčina je z vlastních chybových zpráv aplikace neviditelná.Nejvíc varování ze všech, a nejčastěji přehlédnuté. Svazek plnící se konstantní rychlostí je předvídatelný celé dny dopředu.
Čas připojeníZávislost, na které server stojí, zpomalila nebo je nedostupná, ještě předtím, než se to projeví jako plný výpadek.Často nejranější signál, že je něco níže v řetězci špatně.

Disk si svou pověst klasického předejitelného výpadku zaslouží. Je to jediné selhání, které monitor s prahem a týdnem historie vždy zachytí jako první, a zároveň to, co je nejtrapnější zpětně vysvětlovat.

Čtěte trend, ne jen upozornění

Každé čtení se ukládá, takže má každý monitor serveru vlastní graf své hodnoty v čase s průměrem, minimem a maximem pro okno, na které se díváte. Procenta se vykreslují jako procenta a časy připojení v milisekundách, takže monitor CPU i monitor latence databáze čtete přesně tak, jak byste čekali.

Upozornění vám řekne, že něco překročilo hranici; graf vám řekne dvě věci, které skutečně potřebujete vědět dál. Je to nové? - výkyv, který vypadá izolovaně alarmující, je často stejný výkyv, který se opakuje každé úterý ve 02:00 celý rok. A kam to směřuje? - hodnota paměti, která mezi restarty plynule roste, je únik, ať je její aktuální hodnota jakákoli, a disk rostoucí o dvě procenta týdně má u sebe přilepené konkrétní datum.

Ta druhá otázka je využití monitoringu serveru pro plánování kapacit, a je to důvod, proč začít sbírat metriku ještě předtím, než víte, jaký na ni nastavit práh. Práh můžete přidat za měsíc, jakmile vám historie řekne, jak vypadá normál. Historie, kterou jste nesbírali, je ta, kterou už nezískáte zpět.

Monitoring serveru a monitoring dostupnosti odpovídají na jiné otázky

Doplňují se, nejsou alternativou, a rozdělení je dost čisté na to, aby stálo za to ho jasně vyslovit.

Monitoring dostupnostiMonitoring serveru
Na jakou otázku odpovídáDostane se návštěvník na web právě teď?Je stroj pod ním dostatečně zdravý, aby pořád odpovídal?
Odkud se díváZvenčí - z více než 300 kontrolních bodů ve 158 městechZevnitř - hodnota přečtená přímo na stroji
Typické načasováníŘekne vám to v okamžiku selháníŘekne vám to předtím, než k selhání dojde, pokud nastavíte práh pod hranu
Kontrola falešných poplachůSelhavší pozorování se znovu ověří z dalších kontrolních bodů a potvrdí kvóremJediné autoritativní čtení, s počtem po sobě jdoucích přetížení jako debounce
Odhalí únik pamětiNe - dokud konečně něco nespadneAno - jako trend, o týdny dřív
Odhalí selhání síťové trasy mezi vašimi uživateli a vámiAnoNe - stroj je naprosto v pořádku

Provozovat jen jeden z nich zanechává skutečnou mezeru v každém směru. Kombinace, na které se ustálí většina účtů, je jednominutová kontrola dostupnosti z více lokalit plus hrstka monitorů serveru na CPU, paměť a svazek s nejvyšší pravděpodobností zaplnění.

Monitoring SNMP pro hardware, který nikdy nebude provozovat kolektor

Routery, přepínače, firewally, UPS jednotky a tiskárny nemohou hostit skript, ale téměř všechny už umí SNMP. Samostatná kontrola SNMP přečte číselnou hodnotu přímo ze zařízení podle OID - čítače rozhraní, teplota, zátěž, doba běhu, stav baterie - přes SNMP v1, v2c nebo v3, včetně v3 s autentizací a šifrováním, takže se přihlašovací údaje neposílají otevřeně.

Poctivě k tomu, kde to dnes stojí: kontrola SNMP hodnotu, kterou zařízení hlásí, čte a zaznamenává. Prahové upozorňování na hodnotu SNMP zatím není k dispozici - když potřebujete, aby číslo skutečně vyvolalo incident, použijte monitor zátěže serveru proti kolektoru, který má celý model podmínky a debounce popsaný výše.

Nastavení monitoringu serveru

  1. Rozhodněte, co vystavit. Pokud na vašem serveru už běží PHP nebo IIS, odpovídající hotový kolektor je nejrychlejší cesta; jinak si endpoint napište sami - vrací jedno číslo.
  2. Nasaďte ho na server, který chcete sledovat, a ověřte, že si ho dokážete vyžádat sami. Umístěte ho na neuhodnutelnou cestu. Pokud je stroj nový, bezplatná kontrola TCP portu a bezplatný ping test jsou rychlý způsob, jak ještě předtím ověřit, že je dosažitelný zvenčí - bez přihlášení.
  3. Přidejte monitor typu Monitorování CPU, RAM, HDD, vyberte, kterou hodnotu čte, a zadejte mu URL kolektoru. U monitoru disku pojmenujte cestu nebo jednotku; u monitoru času připojení k databázi zadejte údaje o spojení, které má kolektor navázat.
  4. Nastavte podmínku a limity - a záměrně nastavte i počet přetížení před Down, místo abyste ho nechali na výchozí hodnotě. Právě toto nastavení rozhoduje, jestli je monitor užitečný, nebo ignorovaný.
  5. Vyberte interval, kdekoli od jedné minuty do 24 hodin. Jedna minuta se hodí pro stroj, na kterém běží něco byznys-kritického; 5 nebo 10 minut bohatě stačí na trend, jako je využití disku.
  6. Zopakujte pro každou hodnotu, na které na daném hostu záleží - CPU, paměť a svazek s nejvyšší pravděpodobností zaplnění je rozumná výchozí sada - a poté přidejte kontakty, které se o tom mají dozvědět.
  7. Než cokoli doladíte, nechte to týden běžet. První týden historie je to, co vám řekne, zda je váš práh správný, a je to mnohem lepší důkaz než odhad z prvního dne.

Limity, které stojí za to znát

  • Kolektor musí být dosažitelný. Host bez jakéhokoli příchozího přístupu nelze dotazovat. Co je potřeba vystavit, je jedna URL jen pro čtení, ne správní port - ale vystavená být musí.
  • Jeden monitor sleduje jednu hodnotu. CPU, paměť a disk jsou tři monitory, každý s vlastním prahem a vlastní historií. Právě to dělá upozorňování přesným, a znamená to, že vytížený server zabere několik monitorovacích slotů.
  • Výkonnostní čítače Windows potřebují ASP.NET kolektor. Trojici kategorie / jméno / instance čte lokálně právě tento kolektor; PHP host místo toho hlásí CPU, paměť, disk a časy připojení.
  • Neexistuje potvrzení z více lokalit. Na rozdíl od kontroly dostupnosti pochází metrika serveru z jediného autoritativního zdroje, takže jediné odchylné čtení je čtení skutečné. Nástrojem na to je počet po sobě jdoucích přetížení a stojí za to ho nastavit.
  • Hlásí to, co hlásí kolektor. Pokud má váš vlastní endpoint chybu, monitor věrně upozorní na špatné číslo - proto záleží na volitelném členu chyby v odpovědi: nahlaste chybu, ne nulu.
  • Žádný čítač síťové propustnosti. Dostupné hodnoty jsou CPU, paměť, využití disku, časy připojení a výkonnostní čítače Windows; propustnost mezi nimi není. Pro zařízení, které hlásí propustnost přes SNMP, dokáže tento čítač přečíst a vykreslit kontrola SNMP.

Často kladené otázky

Monitoring serveru je průběžné sledování klíčového využití zdrojů vašeho serveru – zátěže CPU, využití RAM (paměti) a zátěže HDD (disku) – abyste viděli, jak vaše infrastruktura skutečně funguje, a ne jen jestli web nad ní odpovídá. Monitoring serveru od HostTracker kontroluje tyto tři metriky a hlásí trendy a výkyvy v čase, což je důležité, protože vyčerpání zdrojů je jednou z nejčastějších hlavních příčin pomalého výkonu, pádů a přímých výpadků. Server může být technicky „dostupný“ a přesto být okamžik od selhání, pokud je vytížení CPU na maximu, paměť je téměř vyčerpaná nebo je kriticky málo místa na disku – nic z toho běžná kontrola dostupnosti nemusí odhalit, dokud problém skutečně nezpůsobí viditelný výpadek.

Server může zůstat dostupný a technicky online, i když běží nebezpečně blízko svých limitů zdrojů, takže vysoké vytížení CPU nebo RAM je často včasným varovným signálem problému spíš než problémem samotným. Trvale vysoká zátěž CPU zpomaluje každý požadavek, který server zpracovává, a zhoršuje zážitek pro každého návštěvníka, i když web nikdy úplně nespadne. Tlak na paměť je ještě nebezpečnější – jak se využití RAM blíží kapacitě, aplikace mohou začít padat, restartovat se nebo je operační systém ukončí, aby uvolnil paměť, což často způsobuje přerušované, těžko diagnostikovatelné výpadky, které vypadají jako náhodné závady spíš než jasné selhání. Zachycení zvýšeného vytížení CPU nebo RAM pomocí monitoringu serveru dřív, než přeroste v pád, dává administrátorům čas problém prošetřit a proaktivně navýšit kapacitu.

Když monitoring zátěže CPU, RAM nebo disku detekuje neobvyklou aktivitu – trvalý výkyv, paměť blížící se kapacitě nebo docházející místo na disku – HostTracker odešle upozornění přes libovolný z 9 alertovacích kanálů, které máte nastavené, včetně e-mailu, SMS, hlasového hovoru, webhooků, Slacku a messengerů jako Telegram, Discord a Viber. To znamená, že osoba zodpovědná za infrastrukturu serveru se o vznikajícím problému se zdroji dozví přímo, místo aby ho objevila až poté, co už způsobil zpomalení nebo pád, kterého si všimnou zákazníci. Protože jsou hlášení a upozornění generovány automaticky z monitorovaných dat, mají administrátoři zdokumentovanou historii trendů zdrojů společně s upozorněním v reálném čase, což pomáhá odlišit jednorázový výkyv od skutečného problému s kapacitou, který vyžaduje dlouhodobější řešení.

Monitoring dostupnosti odpovídá na užší otázku: je web nebo služba právě teď dostupná a odpovídá. Monitoring serveru se dívá pod tento povrch na infrastrukturu, která web skutečně pohání – zátěž CPU, využití paměti a místo na disku – což bývá hlavní příčinou výpadku dostupnosti, a ne samostatný, nesouvisející problém. Server, kterému dochází paměť nebo místo na disku, může ještě chvíli projít kontrolou dostupnosti, než nakonec spadne nebo se zpomalí do plazivého tempa, takže spoléhat se jen na monitoring dostupnosti znamená, že se o problému dozvíte až ve chvíli, kdy se z něj už stal výpadek. Kombinace obojího dává ucelenější obraz: monitoring dostupnosti potvrzuje, že web je právě dostupný, zatímco monitoring serveru sleduje trendy zdrojů, které předpovídají, jestli tomu tak zůstane i nadále.

Frekvence kontrol je nastavitelná podle toho, jak rychle potřebujete vědět o vznikajícím problému se zdroji. Placené tarify HostTracker podporují monitorovací intervaly až jednou za minutu, což se hodí pro servery s byznys-kritickými aplikacemi, kde je potřeba výkyv zdrojů rychle zachytit a řešit. Méně kritické nebo méně vytížené servery mohou používat delší interval a trvale bezplatný tarif kontroluje dva monitory každých 30 minut, což často stačí na zachycení trvalého trendu, jako je postupně se plnící místo na disku během několika dní, i když by nezachytil velmi krátký výkyv CPU. 30denní zkušební verze se všemi funkcemi bez nutnosti platební karty vám umožní vyzkoušet rychlejší kontrolní intervaly a zjistit, kolik podrobností vám výsledná data poskytnou, než se rozhodnete pro tarif.

Ne – žádného agenta HostTracker instalovat nemusíte, žádný démon udržovat v chodu a žádné přihlašovací údaje nikomu předávat. Kontrola zátěže serveru funguje opačně: váš server vystaví jeden malý endpoint jen pro čtení, který hlásí jedno číslo, a HostTracker si ho vyžádá v intervalu, který nastavíte. Máte tři možnosti, jak ho zajistit. Dvě jsou hotové skripty kolektoru, které vložíte na server, který už provozujete – jeden pro PHP na Linuxu nebo Unixu, druhý pro ASP.NET na IIS – a třetí je napsat si endpoint sám, což zabere zhruba deset řádků v jakémkoli jazyce: hodnotu přečtete, jak chcete, a odpovíte malým JSON objektem, který ji obsahuje. Tuto třetí možnost preferuje řada týmů, protože znamená, že na jejich stroji nikdy neběží nic, co sami nenapsali, a přesně rozhodují, jaká čísla jsou vystavená. Na váš server se nikdy nic automaticky nepushuje a HostTracker na něm nikdy neotevírá žádnou správní relaci.

Endpoint kolektoru musí být dosažitelný pro kontrolní body HostTracker, takže server za firewallem bez jakéhokoli příchozího přístupu nelze dotazovat přímo. V praxi je to menší překážka, než se zdá, protože to, co je potřeba vystavit, je jediná URL jen pro čtení, která vrací jedno číslo – ne SSH, ne správní port, ne monitorovací protokol. Obvyklé přístupy jsou publikovat endpoint na neuhodnutelné cestě, omezit ho na adresy, které z něj čtou, nebo ho umístit na stroj ve stejné síti, který už je přístupný z internetu, a nechat ho hlásit hodnoty za privátní host. Ať zvolíte cokoli, expozice je záměrně minimální: endpoint nepřijímá žádné příkazy, nic neměnící, a vrací jediné číslo. To je úplně jiná bezpečnostní úvaha než instalace agenta třetí strany s přístupem na úrovni systému, a přesně proto je kontrola navržená tímto způsobem.

Monitoring zátěže serveru – kontroly CPU, RAM a HDD – je jeden z 13 typů kontrol dostupných v rámci produktu HostTracker a trvale bezplatný tarif vám umožňuje sledovat dva servery nebo weby zdarma, s kontrolami každých 30 minut. HostTracker jako celek není čistě bezplatný produkt – jde o placenou monitorovací službu s bezplatným tarifem navíc – takže bezplatný tarif se dobře hodí na vyzkoušení monitoringu serveru na několika strojích nebo jako odlehčená možnost pro menší projekty, ne jako hlavní nabídka. Pro monitoring více serverů, kratší kontrolní intervaly nebo byznys-kritickou infrastrukturu, kde záleží na rychlejší detekci, začínají placené tarify zhruba na 5 USD měsíčně a 30denní zkušební verze se všemi funkcemi bez nutnosti platební karty vám umožní rychlejší intervaly vyzkoušet ještě před rozhodnutím.

30denní zkušební verze zdarma - bez platební karty

Odhalte přetížení serveru dřív, než vás položí

Spusťte zkušební verzi zdarma a nechte se upozornit, když zátěž CPU, RAM nebo disku překročí vaše prahové hodnoty.

30denní bezplatná zkušební verze - 100 monitorů - bez platební karty
  • Důvěryhodní od roku 2004
  • 500 000+ sledovaných webů
  • 300+ kontrolních bodů po celém světě

Součást softwaru pro monitorování webu HostTracker.