Každý příběh monitorování má začátek a konec, a dělící čára je vždy stejná: výpadek, který trval příliš dlouho, protože nikdo hlídal. Před monitorováním jsou problémy se serverem objeveny náhodou. Kolega zmíní, že stránka vypadá pomalu. Zákazník pošle rozladěný e-mail. Vývojář se pokusí nasadit aktualizaci a zjistí, že server je nedostupný již několik hodin. Toto schéma se depresi konzistentně opakuje u organizací všech velikostí. Po zavedení monitorování stejný problém se serverem produkuje zásadně jiný zážitek. Server jde dolů. O tři sekundy později dorazí e-mail. Někdo začíná vyšetřovat do minuty. Oprava je nasazena dříve, než si to případně všimne většina uživatelů. Rozdíl mezi těmito dvěma scénáři není otázkou štěstí nebo počtu zaměstnanců. Je to přítomnost nebo nepřítomnost automatizovaného systému, který nepřetržitě hlídá a okamžitě si vezme slovo, když se něco pokazí.
Tradiční přístup ke sledování serveru byl postaven pro týmy operací s vyhrazeným rozpočtem na infrastrukturu. Nástroje jako Nagios, Zabbix a Prometheus jsou výkonné, ale vyžadují značné odborné znalosti k nastavení a údržbě. Běží na vlastních serverech, což vytváří filozofický problém: kdo monitoruje monitor? Pro jednotlivé vývojáře, malé agentury a bootstrapované startupy je režie provozu samoobslužného monitorovacího stacku často větší než režie příležitostného odhalieného výpadku, což znamená, že monitorování se trvale odsouvá na "později" a později nikdy nepřijde. Model cloudového monitorování eliminuje tuto režii zcela. Žádné servery k údržbě. Žádné konfigurační soubory ke správě. Žádná infrastruktura monitorování k opatrování. Přidejte koncový bod, nakonfigurujte předvolby upozornění a systém převezme kontrolu odtud.
Co dělá uptime.yeb.to je prostý v konceptu a pečlivý v provádění. Každý monitorovaný koncový bod je zkontrolován v pravidelných intervalech přes čtyři různé dimenze: základní dosažitelnost sítě pomocí ping, úplné dokončení požadavku HTTPS, platnost certifikátu SSL a časová osa vypršení, a měření doby odezvy. Každá dimenze zachycuje jinou kategorii selhání a dohromady poskytují komplexní obrázek o tom, zda služba není jen online, ale skutečně zdravá a funguje dobře. Server, který reaguje na ping, ale selže HTTPS kontroly, má problém s webovým serverem. Server, který prochází všemi kontrolami, ale vykazuje postupně rostoucí dobu odezvy, se chystá zhroutit. Server s platným certifikátem SSL, který končí za tři dny, se chystá spustit upozornění v prohlížeči, která budou odpuzovat návštěvníky. Každý z těchto scénářů vyžaduje jinou odpověď, a každý z nich je bez aktivního monitorování neviditelný.
📡Monitor dostupnosti
Sledujte dostupnost webových stránek z 10+ globálních regionů. HTTP, SSL, DNS, TCP a ping kontroly s okamžitými upozorněními na výpadky.
✓ Multi-regionální kontroly✓ 5 typů kontrol✓ Okamžitá upozornění✓ SSL monitoring
Co monitor skutečně kontroluje a proč má každá vrstva význam
Monitorování ping je nejzákladnější vrstvou a také nejčastěji nesprávně chápáno. Úspěšná odpověď na ping znamená, že operační systém na serveru běží a síťová cesta mezi sondou monitorování a serverem je čistá. To neznamená, že běží webový server. Neznamená to, že aplikace funguje. Neznamená to, že uživatelé mohou skutečně načíst stránku. Ping je základem, minimálním projevem života a vše ostatní se na tom staví. Když selže kontrola ping, je problém závažný: buď je server zcela offline, nebo existuje základní problém se sítí, který brání jakémukoli provozu, aby se dostal do stroje. Jedná se o výpadky, které ovlivňují vše, nejen webový provoz, ale také přístup SSH, připojení k databázi, doručování e-mailu a každou jinou službu běžící na tom stroji.
Monitorování HTTPS přidává kritickou vrstvu, kterou ping postrádá. Kontrola HTTPS provádí úplný webový požadavek, stejný druh požadavku, který prohlížeč vytváří, když uživatel navštíví webovou stránku. Kontrola ověřuje, že webový server přijímá připojení, že handshake SSL se úspěšně dokončuje, že server vrací platnou odpověď HTTP a že celý proces se dokončí v rozumném časovém rámci. To zachycuje širokou kategorii problémů, které ping nemůže detekovat: zhroucené procesy webového serveru, chybně nakonfigurované certifikáty SSL, chyby aplikace, které vrací stavové kódy HTTP 500, a zhoršení výkonu, které činí stránku prakticky nepoužitelnou, i když je technicky "online". Rozdíl mezi serverem, který je dosažitelný, a webem, který je použitelný, je přesně mezera, kterou monitorování HTTPS vyplňuje.
Monitorování certifikátu SSL řeší problém, který alespoň jednou zasáhl téměř každého operátora webů. Certifikáty vyprší. Bezplatné certifikáty od Let's Encrypt trvají 90 dní. Placené certifikáty obvykle trvají jeden rok. V obou případech datum vypršení přichází s absolutní jistotou, a přesto se obnovy certifikátů stále přehlíží s pozoruhodnou frekvencí. Důvod je jednoduchý: neexistuje integrovaný systém připomínání. Certifikační autority nemusí vždy odesílat upozornění na obnovení. Automatizované skripty obnovy někdy selhávají tiše. A následky vypršeného certifikátu jsou okamžité a tvrdé. Prohlížeče zobrazují celostránková upozornění zabezpečení. Vyhledávače stránku označí. Uživatelé, kteří tato upozornění vidí, jen zřídka pokračují a často se nevracejí ani poté, co je certifikát obnoven. Monitorování data vypršení certifikátu a upozornění dlouho předtím, než lhůta uplyne, eliminuje tuto celou kategorii preventabilních incidentů.
Monitorování doby odezvy je systém počátečního varování pro problémy, které ještě nejsou výpadky, ale směřují tímto směrem. Zdravý webový server reaguje v 100 až 300 milisekundách. Když doba odezvy začíná stoupat na 500, pak 800, pak 1500 milisekund, je něco špatně. Dotazy do databáze by mohly probíhat pomalu kvůli rostoucím velikostem tabulek. Paměť by mohla být spotřebována úniky procesu. Vstupně-výstupní disk by mohly být saturovány protokolováním nebo operacemi zálohování. Tyto problémy neaktivují selhání ping nebo chyby HTTPS, ale degradují uživatelský zážitek způsobem, který přímo ovlivňuje míru odchodů, míru konverzí a pozici ve vyhledávačích. Sledováním doby odezvy v průběhu dnů a týdnů se trendy stávají viditelné dlouho předtím, než se zhoršují v úplné výpadky.
Systém upozornění a proč tři sekundy změní vše
Rychlost detekce je jedinou nejdůležitější proměnnou v minimalizaci dopadů výpadků. Matematika je přímá: celkové škody se rovnají dopadům za minutu vynásobené počtem minut. Snížení doby detekce z pěti hodin na tři sekundy nezmění dopad za minutu, ale dramaticky sníží počet minut. Server, který jde dolů a je opravován během deseti minut, zažívá zhruba 0,002% prostojů za den. Stejný server, který jde dolů a je objeven pět hodin později, zažívá 0,35% prostojů, i když oprava trvá stejných deset minut. V průběhu měsíce se tato čísla složitě zvyšují v rozdíl mezi "čtyřmi devítkami" spolehlivosti a ostudným procentem dostupnosti, které žádný klient nechce vidět na stránce stavu.
Mechanismus doručování upozornění je stejně důležitý jako rychlost detekce. Upozornění, které dorazí na přístrojovou desku, kterou nikdo nesleduje, je ekvivalentní bez upozornění. E-mail zůstává nejspolehlivějším kanálem notifikace pro většinu operátorů, protože e-mail je vždy zapnutý, vždy přístupný z jakéhokoli zařízení a nevyžaduje instalaci další aplikace nebo kontrolu dalšího rozhraní. Když uptime.yeb.to detekuje selhání, e-mailové upozornění je odeslána okamžitě se všemi relevantními kontexty: který koncový bod selhal, jaký typ kontroly problém detekoval, přesné časové razítko a odpověď, která byla obdržena (nebo chyba, která nastala). To znamená, že příjemce může začít diagnostikovat problém z e-mailu samotného, bez nutnosti nejprve se přihlášovat na přístrojovou desku monitorování.
Oznámení o obnově jsou stejně důležitá a často přehlížena. Vědět, kdy se server vrátí online, je právě tak cenné jako vědět, kdy se vypne. Upozornění na obnovení zahrnují celkovou dobu výpadku, která se přímo vztahuje na analýzu po incidentu a hlášení. Také brání zbytečné eskalaci, která se stává, když je přijato upozornění, ale žádné následné není odesláno poté, co se problém sám vyřeší. Bez oznámení o obnovení vytváří každé upozornění otevřenou smyčku, která vyžaduje ruční ověření, která spotřebovává čas a pozornost, které by mohly být věnovány produktivnější práci.
Denní přehledy, týdenní zprávy a dlouhodobý pohled
Upozornění v reálném čase řeší naléhavé problémy. Přehledy řeší vše ostatní. Denní e-mail přehladu přichází každé ráno s úplným souhrnem předchozích 24 hodin: procenta dostupnosti pro každý monitorovaný koncový bod, průměrné a nejvyšší doby odezvy, jakékoli incidenty, které se vyskytly a jejich trvání, a stav vypršení certifikátu SSL pro všechny koncové body HTTPS. Tento e-mail trvá přibližně 30 sekund k skenování a poskytuje okamžitou odpověď na otázku "je vše zdravé?" bez nutnosti přihlášení k jakékoli přístrojové desce nebo ruční kontroly jakéhokoli druhu.
Týdenní přehledy se zoomují dále, odhalují trendy, které jsou neviditelné na denní úrovni. Server, který udržoval 100% dostupnost každý den v týdnu, ale vykazoval doby odezvy rostoucí o 50 milisekund každý den, má vyvíjející se problém, který denní přehled nemusí učinit zřejmým, ale týdenní graf trendů činí neoddiskutovatelný. Podobně server, který zažil dva krátké výpadky v různých dnech v týdnu, může odhalit schéma při zobrazení dohromady: oba výpadky se vyskytly v 3 hodin ráno během automatizovaného okna zálohování, což naznačuje, že proces zálohování spotřebovává příliš mnoho zdrojů a musí být optimalizován nebo přeplánován. Tato schémata se zobrazují pouze když jsou data agregována v čase, a týdenní přehled je navržen tak, aby právě tyto poznatky vynášely.
Historie incidentů poskytuje podrobný záznamy forenzní, který přehledy shrnují. Každý detekovaný výpadek je zaznamenán se svým časem začátku, časem konce, trváním, postiženými kontrolami a daty odpovědi, která naznačovala selhání. Tato historie slouží více účelům. Poskytuje data potřebná pro kontroly po incidentu a analýzu hlavní příčiny. Vytváří odpovědnost při jednání s poskytovateli hostingu o shodě se SLA. Generuje statistiky dostupnosti potřebné pro stránky stavu a zprávy klientů. A vytváří dlouhodobý záznam, který může informovat rozhodnutí o infrastruktuře, jako je to, zda konkrétní poskytovatel hostingu splňuje své sliby na spolehlivost nebo zda je migrace nutná.
Sondy z více regionů a slepé skvrny monitorování z jednoho místa
Server může být dokonale přístupný z Frankfurtu a zcela nedostupný z Tokia ve stejný čas. Směrování sítě není jednotné po celém světě. Poskytovatelé internetových služeb dělají rozhodnutí o směrování, která mohou vytvořit problémy s regionální konektivitou ovlivňující konkrétní geografické koridory, zatímco ostatní zůstávají zcela neovlivněné. Zpoždění propagace DNS mohou znamenat, že migrace serveru je úplná a ověřená z jednoho kontinentu, zatímco uživatelé na jiném kontinentu jsou stále směrováni na starý, případně offline server. Chybné konfigurace CDN mohou služit zastaralé nebo chybné obsahu konkrétním regionům, zatímco jiné regiony obdrží správné, aktuální stránky.
Monitorování z jednoho místa je slepé ke všem těmto scénářům. Pokud je sonda monitorování ve stejné oblasti datového centra jako server, bude hlásit 100% dostupnost, zatímco polovina globálního uživatelské základny nemůže přistoupit na web. Monitorování z více regionů ze šesti geograficky distribuovaných míst zachycuje tyto nesrovnalosti podle návrhu. Když kontrola selže z jedné oblasti, ale projde z ostatních, upozornění zahrnuje geografický kontext, což okamžitě zúží problém na problém regionálního směrování spíše než selhání na straně serveru. Tento rozdíl je pro diagnózu a odezvu obrovský: problém na straně serveru vyžaduje restartování služeb nebo kontaktování poskytovatele hostingu, zatímco problém regionálního směrování vyžaduje vyšetření DNS, konfigurace CDN nebo problemy na úrovni ISP.
Šest monitorovacích míst je vybráno tak, aby pokrývalo hlavní populační a provozní centra globálně. To znamená, že web sloužící zákazníkům v Severní Americe, Evropě a Asii má sondy v nebo blízko každé z těchto oblastí, což poskytuje skutečné pokrytí spíše než iluzi monitorování, kterou vytváří jedna sonda. Pro podniky, které závisejí na globální dostupnosti, není tento přístup z více regionů volitelné vylepšení. Je to minimální životaschopná konfigurace monitorování, která přesně reprezentuje zážitek geograficky distribuované uživatelské základny. Budování uptime.yeb.to s schopností z více regionů od začátku zajišťuje, že monitorování je stejně komplexní jako provoz, který chrání.