Model Monitorování stavu pomocí koncových bodů

  • Článek
  • 9 min ke čtení

Implementuje v aplikaci funkční kontroly, ke kterým mají externí nástroje v pravidelných intervalech přístup prostřednictvím zveřejněných koncových bodů. To může pomáhat při ověřování, jestli aplikace a služby správně fungují.

Kontext a problém

Je vhodné a často jde i o obchodní požadavek, abyste monitorovali webové aplikace a back-endové služby, jestli jsou dostupné a správně fungují. Někdy je ale obtížné monitorovat služby běžící v cloudu, než je můžete monitorovat v místních službách. Například nemáte úplnou kontrolu nad hostitelským prostředím a služby obvykle závisejí na jiných službách poskytovaných dodavateli platformy a dalšími stranami.

Aplikace hostované v cloudu ovlivňuje mnoho faktorů, třeba latence sítě, výkon a dostupnost základních výpočetních a úložných systémů a šířka pásma sítě mezi nimi. Kvůli kterémukoli z těchto faktorů může služba úplně nebo částečně selhat. Proto musíte v pravidelných intervalech ověřovat, jestli služba správně funguje, aby se zaručila požadovaná úroveň dostupnosti. Může to být součástí vaší smlouvy o úrovni služeb (SLA).

Řešení

Implementujte monitorování stavu pomocí zasílání požadavků na koncový bod v aplikaci. Aplikace by měla provést nezbytné kontroly a vrátit údaj o svém stavu.

Kontrola v rámci monitorování stavu obvykle kombinuje dva faktory:

  • Kontroly (pokud k nim dochází) prováděné aplikací nebo službou v reakci na požadavek na koncový bod ověření stavu
  • Analýza výsledků nástrojem nebo architekturou, která provádí kontrolu ověření stavu

Kód odpovědi ukazuje stav aplikace a volitelně všech součástí nebo služeb, které používá. Kontrola latence nebo doby odezvy se provádí pomocí monitorovacího nástroje nebo architektury. Přehled modelu je znázorněný na obrázku.

Přehled modelu

K dalším kontrolám, které by mohl kód monitorování stavu v aplikaci provádět, patří:

  • Kontrola dostupnosti a doby odezvy cloudového úložiště nebo databáze
  • Kontrola dalších prostředků nebo služeb nacházejících se v aplikaci nebo jinde, ale aplikací používaných

K dispozici jsou služby a nástroje, které monitorují aplikace odesláním požadavku do konfigurovatelné sady koncových bodů a vyhodnocením výsledků na základě sady konfigurovatelných pravidel. Vytvořit koncový bod služby, jehož jediným účelem je provádět některé funkční testy systému, je poměrně snadné.

K typickým kontrolám, které můžou monitorovací nástroje provádět, patří:

  • Ověřování kódu odpovědi. Odpověď HTTP s hodnotou 200 (OK) třeba udává, že aplikace odpověděla bez chyby. Monitorovací systém může také zkontrolovat další kódy odpovědí a poskytnout komplexnější výsledky.
  • Kontrola obsahu odpovědi kvůli zjištění chyb, i když se vrátí stavový kód 200 (OK). Můžou se tak rozpoznat chyby, které ovlivňují jenom část vrácené webové stránky nebo odpovědi služby. Příkladem je kontrola názvu stránky nebo vyhledání konkrétního slovního spojení, které značí, že byla vrácena správná stránka.
  • Měření doby odezvy, která udává kombinaci latence sítě a doby, kterou aplikaci trvalo provedení požadavku. Zvětšující se hodnota může znamenat vznikající problém s aplikací nebo sítí.
  • Kontrola prostředků nebo služeb nacházejících se mimo aplikaci, jako je síť pro doručování obsahu používaná aplikací k doručování obsahu z globálních mezipamětí
  • Kontrola vypršení platnosti certifikátů protokolu SSL
  • Měření doby odezvy vyhledání DNS pro adresu URL aplikace kvůli měření latence DNS a počtu selhání DNS
  • Ověření adresy URL vrácené vyhledáním DNS kvůli zajištění správných položek. To může pomoct vyhnout se škodlivému přesměrování požadavků při úspěšném útoku na server DNS.

Kde je to možné, je také vhodné tyto kontroly provádět z různých místních nebo hostovaných umístění kvůli měření a porovnání doby odezvy. V ideálním případě byste měli aplikace monitorovat z umístění, která jsou blízko zákazníkům, abyste z každého umístění získali přesné informace o výkonu. Kromě toho, že získáte robustnější mechanismus kontroly, můžou vám výsledky pomoct rozhodnout, kde nasazení pro aplikaci umístit — a jestli se má aplikace nasadit ve více než jednom datacentru.

Testy je také potřeba provést u všech instancí služby, které zákazníci používají, aby bylo jisté, že aplikace správně funguje pro všechny zákazníky. Pokud je třeba zákaznické úložiště rozdělené mezi více než jeden účet úložiště, proces monitorování by je měl zkontrolovat všechny.

Problémy a důležité informace

Když se budete rozhodovat, jak tento model implementovat, měli byste vzít v úvahu následující skutečnosti:

Jak odpověď ověřit. Dostačuje třeba jediný stavový kód 200 (OK) k ověření, že aplikace funguje správně? Sice to poskytuje nejzákladnější míru dostupnosti aplikace a jde o minimální implementaci tohoto modelu, ale získá se jen málo informací o operacích, trendech a možných nadcházejících problémech v aplikaci.

Počet koncových bodů ke zveřejnění pro aplikaci. Jeden z přístupů je zveřejnit aspoň jeden koncový bod pro základní služby, které aplikace používá, a další pro služby nižší priority. To umožní, aby se každému výsledku monitorování přiřadila různá úroveň důležitosti. Zvažte také zveřejnění dalších koncových bodů, třeba jednoho pro každou základní službu, kvůli podrobnějšímu monitorování. Kontrola ověření stavu může třeba zkontrolovat databázi, úložiště a externí službu geokódování, které aplikace používá, přičemž každý kontrolovaný prvek vyžaduje jinou úroveň provozu a dobu odezvy. Aplikace může být v pořádku, i když služba geokódování nebo některá jiná úloha na pozadí není několik minut dostupná.

Zda se má použít stejný koncový bod pro monitorování, který se používá pro obecný přístup, ale na konkrétní cestu navrženou pro kontroly ověření stavu, například/Health na koncovém bodu obecného přístupu. To umožňuje provádět některé funkční testy v aplikaci monitorovacími nástroji, třeba přidání nové registrace uživatele, přihlášení a objednání testu, a současně ověřovat, že je koncový bod obecného přístupu dostupný.

Typ informací, které se mají ve službě shromažďovat v reakci na požadavky na monitorování a jak tyto informace vracet Většina existujících nástrojů a architektur se dívá jenom na stavový kód protokolu HTTP, který koncový bod vrátí. Pokud chcete vrátit a ověřit další informace, možná budete muset vytvořit vlastní monitorovací nástroj nebo službu.

Kolik informací se má získávat. Provádění nadměrného zpracování během kontroly může aplikaci přetěžovat a mít vliv na ostatní uživatele. Potřebná doba může překročit časový limit monitorovacího systému, takže aplikaci označí jako nedostupnou. Většina aplikací zahrnuje instrumentaci jako obslužné rutiny chyb a čítače výkonu, které protokolují výkon a podrobné informace o chybách. To může dostatečně nahrazovat vracení dalších informací z kontroly ověřování stavu.

Ukládání stavu koncového bodu do mezipaměti. Příliš časté kontroly stavu můžou být nákladné. Pokud se stav zobrazuje prostřednictvím řídicího panelu, například nechcete, aby každý požadavek na řídicí panel aktivoval kontrolu stavu. Místo toho pravidelně kontrolujte stav systému a stav ukládejte do mezipaměti. Zveřejněte koncový bod, který vrací stav uložený v mezipaměti.

Jak nakonfigurovat zabezpečení pro koncové body monitorování , aby byly chráněny před veřejným přístupem, což může vystavit aplikaci škodlivým útokům, riziko vystavení citlivých informací nebo přilákat útoky DoS (Denial of Service). Obvykle by se to mělo provádět v konfiguraci aplikace, aby byla možná snadná aktualizace bez restartování aplikace. Zvažte použití jednoho nebo více z těchto postupů:

  • Zabezpečte koncový bod vyžadováním ověření. Můžete to provést pomocí bezpečnostního klíče ověřování v hlavičce požadavku nebo předáním přihlašovacích údajů s požadavkem za předpokladu, že monitorovací služba nebo nástroj ověřování podporuje.

    • Použijte skrytý koncový bod. Například zveřejněte koncový bod na jiné IP adrese, než kterou používá výchozí adresa URL aplikace, nakonfigurujte koncový bod na nestandardním portu HTTP nebo použijte komplexní cestu k testovací stránce. Další adresy a porty koncových bodů obvykle můžete zadat v konfiguraci aplikace a záznamy pro tyto koncové body přidat do serveru DNS, pokud je to nutné, aby se IP adresa nemusela zadávat přímo.

    • Zveřejněte na koncový bod metodu, která přijímá parametr, jako je hodnota klíče nebo hodnota režimu operace. V závislosti na hodnotě zadané pro tento parametr může kód při přijetí požadavku provést konkrétní test nebo sadu testů, nebo vrátit chybu 404 (Nenalezeno), pokud hodnota parametru není rozpoznána. Rozpoznávané hodnoty parametru se dají nastavit v konfiguraci aplikace.

      Na samostatný koncový bod, který provádí základní funkční testy, budou mít útoky DoS pravděpodobně menší dopad, aniž by se narušil provoz aplikace. V ideálním případě nepoužívejte test, který může zveřejnit citlivé informace. Pokud musíte vracet informace, které se můžou útočníkovi hodit, zvažte, jak budete koncový bod a data chránit před neoprávněným přístupem. V takovém případě nestačí spoléhat na skrytí koncového bodu. Měli byste také zvážit použití připojení HTTPS a šifrování citlivých dat, i když se tím zvýší zátěž serveru.

  • Přístup ke koncovému bodu, který je zabezpečený pomocí ověřování, je bod, který je potřeba vzít v úvahu při vyhodnocování koncových bodů kontroly stavu a těch, které ho využívají. Jako příklad App Service integrovanou kontrolu stavu , která se integruje s funkcemi ověřování a autorizace App Service.

Jak zajistit, aby monitorovací agent fungoval správně. Jedním z přístupů je zveřejnit koncový bod, který jednoduše vrací hodnotu z konfigurace aplikace nebo náhodnou hodnotu, která se může použít k testování agenta.

Ujistěte se také, že monitorovací systém provádí kontroly sebe sama, třeba samočinný test a integrovaný test, aby se zamezilo tomu, že bude vydávat falešně pozitivní výsledky.

Kdy se má tento model použít

Tento model je vhodný pro:

  • Monitorování webů a webových aplikací k ověření dostupnosti
  • Monitorování webů a webových aplikací ke kontrole správného fungování
  • Monitorování služeb střední vrstvy nebo sdílených služeb ke zjištění a izolaci selhání, které by mohlo narušit jiné aplikace
  • Doplnění stávající instrumentace v aplikaci, jako jsou čítače výkonu a obslužné rutiny chyb. Kontrola stavu ověřování nenahrazuje požadavek na protokolování a auditování v aplikaci. Instrumentace může poskytnout cenné informace pro existující architekturu, která monitoruje čítače a protokoly chyb, aby se zjistila selhání nebo jiné problémy. Pokud ale aplikace není dostupná, nemůže informace poskytovat.

Příklad

kontroly stavu pro ASP.NET jsou middlewarem a sadou knihoven pro vytváření sestav stavu součástí infrastruktury aplikací. Poskytuje rozhraní pro vytváření sestav o kontrolách stavu konzistentním způsobem, který implementuje mnohé z výše zmíněných postupů. To zahrnuje externí kontroly, jako je připojení k databázi, a specifické koncepty, jako je například živý přehled a testy připravenosti.

logo GitHub : na GitHubmůžete najít několik ukázkových implementací pomocí ASP.NET kontroly stavu.

Monitorování koncových bodů v aplikacích hostovaných pomocí Azure

Tady jsou některé možnosti monitorování koncových bodů v aplikacích Azure:

  • Použijte integrované funkce monitorování Azure.

  • Použijte službu nebo architekturu třetí strany, jako je Microsoft System Center Operations Manager.

  • Vytvořte vlastní nástroj nebo službu, která běží na vašem vlastním serveru nebo hostovaném serveru.

    I když Azure poskytuje poměrně komplexní sadu možností monitorování, můžete použít další služby a nástroje k poskytnutí dalších informací. Application Insights funkce Azure Monitor je zaměřená na vývojový tým, který vám pomůže pochopit, jak vaše aplikace funguje a jak se používá. Monitoruje míry požadavků, doby odezvy, míry selhání, míry závislosti a frekvence selhání a může vám zjistit, jestli se vám vaše externí služby zpomalují.

Podmínky, které je možné sledovat, se liší v závislosti na mechanismu hostování, který zvolíte pro vaši aplikaci, ale všechny z nich zahrnují možnost vytvořit pravidlo upozornění, které používá webový koncový bod, který zadáte v nastavení služby. Tento koncový bod by měl včas reagovat, aby systém upozornění mohl zjistit, jestli aplikace správně funguje.

Přečtěte si další informace o vytváření oznámení o upozorněních.

V případě závažného výpadku by měl být provoz klienta směrovatelný do nasazení aplikace, které zůstává dostupné v jiných oblastech nebo zónách. V závislosti na tom, jestli je aplikace interní a/nebo externí, by se měla použít připojení mezi místními sítěmi a globální vyrovnávání zatížení. služby, jako jsou například přední dveře Azure, Azure Traffic Manager nebo sítě cdn, mohou směrovat provoz napříč oblastmi na základě stavu aplikace poskytnutého prostřednictvím sond stavu.

Azure Traffic Manager je služba směrování a vyrovnávání zatížení, která může distribuovat požadavky na konkrétní instance aplikace na základě rozsahu pravidel a nastavení. Kromě požadavků směrování Traffic Manager pravidelně odesílá příkaz ping na adresu URL, port a relativní cestu, které zadáte, aby se zjistilo, které instance aplikace definované v jeho pravidlech jsou aktivní a reagují na požadavky. Pokud zjistí stavový kód 200 (OK), označí aplikaci jako dostupnou. Každý jiný stavový kód způsobí, že Traffic Manager aplikaci označí jako offline. V konzole Traffic Managera můžete stav zobrazit a nakonfigurovat pravidlo pro přesměrování požadavků na jiné instance aplikace, které odpovídají.

Traffic Manager ale budou čekat na určitou dobu , než přijde odpověď z adresy URL pro monitorování. Proto se ujistěte, že se váš ověřovací kód stavu za tuto dobu spustí s přihlédnutím k latenci sítě pro cestu z Traffic Managera do vaší aplikace a zpět.

Při implementaci tohoto modelu se můžou hodit tyto pokyny: