Sdílet prostřednictvím


Pozorovatelnost služeb pro Kubernetes s podporou Azure Arc

Pozorovatelnost je charakteristika aplikace, která odkazuje na to, jak dobře je možné porozumět internímu stavu nebo stavu systému z externích výstupů. Počítačové systémy měříme sledováním času procesoru, paměti, místa na disku, latence, chyb a dalších metrik. Čím je systém pozorovatelnější, tím jednodušší je pochopit, co dělá, když ho sledujeme.

Pozorovatelnost systému má významný vliv na provozní náklady. Pozorovatelné systémy poskytují svým operátorům smysluplná a použitelná data, což jim umožňuje dosáhnout uspokojivých výsledků a mít méně výpadků. Další informace se nemusí nutně překládat do pozorovatelnějšího systému. Ve skutečnosti může množství informací vygenerovaných systémem znesnadnit identifikaci cenných zdravotních signálů z šumu generovaného aplikací.

Pozorovatelnost služeb je důležitá, protože pomáhá pochopit výkon a problémy v distribuovaných a cloudových systémech na základě dynamických architektur.

Implementace řešení pro dosažení pozorovatelnosti služeb vám může pomoct:

  • Ujistěte se, že koncoví uživatelé můžou vaši aplikaci využívat a že jsou splněny vaše obchodní očekávání.
  • Porozumíte celému systému a tomu, jak funguje společně pomocí jediného podokna skla.
  • Vytvořte směrný plán pro váš systém a zjistěte, jak různé okolnosti ovlivňují výkon vašeho systému.
  • Vygenerujte položky akcí z neočekávaných scénářů a chování.

Kubernetes s podporou Azure Arc nabízí dvě integrované možnosti rozšíření, které vám pomůžou dosáhnout pozorovatelnosti služeb: Open Service Mesh a brána služby API Management v místním prostředí. Tyto možnosti jsou podrobně popsány v následujících částech s ohledem na návrh.

Architektura

Následující diagram znázorňuje tři pilíře pozorovatelnosti služeb s dopadem objemu dat.

Diagram znázorňující pilíře pozorovatelnosti služeb

Následující diagram znázorňuje různé komponenty Open Service Mesh spuštěné v clusteru Kubernetes s podporou Arc. Zobrazuje také ukázkovou aplikaci povolenou v síti služeb, která se automaticky konfiguruje s kontejnerem bočního vozu Envoy.

Diagram znázorňující open service mesh běžící v Kubernetes s podporou Azure Arc

Aspekty návrhu

Tři pilíře pozorovatelnosti jsou metriky, protokoly a trasování. Začlení je do strategie pozorovatelnosti, aby byl váš systém pozorovatelný.

  • Metriky jsou číselné hodnoty, které popisují určitý aspekt systému v určitém časovém okamžiku a vždy se shromažďují v pravidelných intervalech.

Následující snímek obrazovky ukazuje vizualizaci ukázkové metriky požadavku HTTP pro službu. Metrika v tomto příkladu se zobrazí jako frekvence požadavků HTTP za minutu v zadaném časovém období.

Snímek obrazovky znázorňující metriku požadavku H T T P pro službu

  • Protokoly můžou ukládat různé datové typy, které mají vlastní struktury. Protokol obsahuje podrobnosti o transakcích,kteréch Protokoly aplikací obvykle zahrnují časová razítka, úrovně protokolů a všechny informace potřebné k pochopení kontextu události. Protokoly se shromažďují a odesílají do služby protokolů pro účely ukládání a analýzy.

  • Distribuované trasování je diagnostická technika, která uživatelům pomáhá lokalizovat chyby a problémy s výkonem v aplikacích, zejména všechny, které jsou distribuovány napříč více počítači nebo procesy. Tato technika sleduje požadavky prostřednictvím aplikace, koreluje práci provedenou různými komponentami aplikace a odděluje ji od jiné práce, kterou může aplikace provádět pro souběžné požadavky.

Následující snímek obrazovky ukazuje vizualizaci komplexní transakce pomocí Application Insights. Tento vizuál umožňuje snadno pochopit dobu odezvy, kódy odpovědí a všechny výjimky, ke kterým dochází mezi požadavky v transakčním řetězu.

Snímek obrazovky znázorňující kompletní trasování transakcí

Tři pilíře metrik, protokolů a distribuovaného trasování jsou propojené. Metriky se ukládají jako číselné hodnoty v databázi časových řad. Jsou také mnohem menší než protokoly, což usnadňuje vyhodnocování a užitečnost pro upozorňování téměř v reálném čase. Protokoly zaznamenávají a sdělují mnohem více informací než metriky, což je užitečné pro hlubší ladění. Trasování je omezené na požadavky a užitečné pro získání přehledu o požadavku při procházení různých komponent distribuovaného systému.

Následující tabulka ukazuje dopad kolekce na tři pilíře.

Charakteristika kolekce Metriky Protokoly Distribuované trasování
Účty pro každou transakci Ano Yes Ne (vzorkováno)
Problémy s kardinalitou imunní vůči kardinalitě No Ano Yes
Náklady Malý zájem Velký zájem Nízká

Existují různé způsoby, jak dosáhnout pozorovatelnosti služeb. Síť služeb můžete použít k tomu, abyste ji udělali ve vrstvě platformy, kde vaše aplikace neví a beze změny. Můžete také instrumentovat aplikaci s knihovnou, která se běžně provádí pomocí nástroje Application Sledování výkonu ing (APM), jako je Application Insights. Brány rozhraní API poskytují pozorovatelnost pro provoz na severu–jih, ale chybí pozorovatelnost podu pro komunikaci podů a snadnou konfiguraci ve velkém měřítku.

Následující části popisují, jak můžete použít síť služeb a bránu rozhraní API v místním prostředí, která je k dispozici pro Azure Arc, abyste dosáhli pozorovatelnosti služeb.

Síť služeb

Síť služeb poskytuje funkce, jako je správa provozu, odolnost, vynucení zásad, zabezpečení přenosu, zabezpečení identit a pozorovatelnost vašich úloh. Vaše aplikace je oddělená od těchto provozních funkcí; síť služeb je přesune mimo aplikační vrstvu a dolů do vrstvy infrastruktury. To se provádí prostřednictvím vysoce výkonného proxy serveru, který zprostředkovává veškerý příchozí a odchozí provoz do vaší služby.

  • Kubernetes s podporou Azure Arc podporuje open service mesh (OSM) – projekt CNCF (Cloud Native Computing Foundation), který je nasazený jako rozšíření. Open Service Mesh je jednoduchá, rozšiřitelná síť nativních cloudových služeb, která umožňuje uživatelům jednotně spravovat, zabezpečit a získávat zastaralé funkce pozorovatelnosti pro vysoce dynamická prostředí mikroslužeb.
  • Mezi další oblíbené služby mesh, které vyžadují podporu dodavatele, patří Istio, Consul Connect a Linkerd.
  • V závislosti na funkcích, které používáte při implementaci sítě služeb, může být na operátorech aplikací kladena další odpovědnost, aby definovali konfiguraci pro každou službu (například pravidla přístupu a služby onboardingu). Operátory clusteru také musí spravovat a uvědomovat kontroler sítě služeb. Vzhledem ke způsobu, jakým síť služeb používá model bočního auta, jsou při ladění výchozího a příchozího přenosu potřeba protokoly z řídicí roviny sítě služby a sajdkáry.

Pozorovatelnost sítě služeb

Pozorovatelnost je důležitou funkcí mezi mnoha službami, které poskytují sítě. Zvolte síť Service Mesh, která splňuje vaše minimální požadavky na pozorovatelnost, abyste snížili složitost a komponenty, se kterými může síť služeb přijít, a je potřeba ji nakonfigurovat. Vyhodnoťte následující běžné funkce a případy použití pozorovatelnosti, které poskytuje síť služeb:

  • Generování metrik, včetně čtyř zlatých signálů: latence, přenos, chyby a sytost
  • Metoda RED (frekvence volání za sekundu, chyby, latence volání doby trvání), což je podmnožina čtyř zlatých signálů a slouží k měření služeb. Vaše síť služeb by měla poskytovat standardizovaný způsob shromažďování metrik RED, trasování atd.
  • Pozorovatelnost se zvyšuje, od zvýšení šířky pokrytí až po všechny služby, které jsou součástí vaší sítě služeb.
  • Funkce, které zvyšují přijetí pozorovatelnosti automatickým instrumentováním všech služeb.
  • Silná integrace s pilíři pozorovatelnosti služeb Vaše síť služeb by měla být schopná zlikvidovat metriky a shromažďovat protokoly, které se zobrazují v řešení monitorování. Ujistěte se, že shromažďování telemetrických dat vaší sítě služeb podporuje vaše obchodní potřeby a integruje se s existujícím řešením monitorování.

Následující diagram znázorňuje příklad funkce proxy služby Service Mesh shromažďování a předávání dat.

Diagram znázorňující příklad pozorovatelnosti pomocí proxy služby Service Mesh

Brána v místním prostředí služby API Management

Díky integraci mezi Azure API Management a Azure Arc v Kubernetes můžete nasadit komponentu brány API Management jako rozšíření v clusteru Kubernetes s podporou Služby Azure Arc. To umožňuje spuštění kontejnerizované verze brány SLUŽBY API Management ve vašem clusteru. Všechny brány v místním prostředí se spravují ze služby API Management, se kterou jsou federované, a poskytují tak přehled a jednotné prostředí pro správu napříč všemi interními a externími rozhraními API.

Konfigurace brány v místním prostředí tak, aby přijímala příchozí provoz, který bude směrovat na vaše služby, vyžaduje vytvoření zásad. Její správa se může stát složitějším s rostoucím škálováním vaší služby.

Další informace najdete v přehledu brány v místním prostředí.

Pozorovatelnost brány služby API Management v místním prostředí

Brána v místním prostředí generuje metriky, protokoly stdout a protokoly stderr. Vygenerované metriky můžou být nakonfigurované objektem ConfigMap ve vašem clusteru. Informace o rozšířeném monitorování pomocí služby API Management najdete v tématu Pokročilé monitorování.

Účty pozorovatelnosti brány v místním prostředí pro externí provoz (sever–jih) přicházející do clusteru, ale neposkytuje žádnou pozorovatelnost provozu mezi pody uvnitř vašeho clusteru (východ– západ).

Cloudové metriky a protokoly: Metriky se ve výchozím nastavení vygenerují do služby Azure Monitor. Log Analytics umožňuje shromažďovat a zobrazovat protokoly kontejnerů v místním prostředí pomocí služby Azure Monitor pro kontejnery. Další informace najdete v tématu Konfigurace místních metrik a protokolů pro bránu v místním prostředí služby Azure API Management.

Místní metriky a protokoly: Metriky a protokoly z brány v místním prostředí je možné integrovat s místními nástroji pro monitorování nebo ho vygenerovat pomocí mapy konfigurace. Metriky je možné nakonfigurovat pro publikování na servery metrik. Protokoly brány se ve výchozím nastavení generují pro stdout a stderr. Další informace najdete v tématu Konfigurace místních metrik a protokolů pro bránu v místním prostředí služby Azure API Management.

Tabulka porovnání technologií

Následující tabulka uvádí rozdíly mezi možnostmi implementace, které vám pomůžou zvolit metodu pro získání pozorovatelnosti služeb.

Schopnost Service Mesh Sledování výkonu aplikace Brána rozhraní API v místním prostředí
Podpora provozu – východ –západ Ano Ano No
Funkce metrik Ano Ano Yes
Funkce protokolování Ano Yes Vlastní implementace
Funkce distribuovaných trasování Ano Ano Yes
Vrstva implementace Síť Aplikace Síť
Podporované protokoly HTTP(S), TCP, gRPC HTTP(S), websockety
Odpovědnost za konfiguraci Operátory clusteru Vývojáři aplikací Operátory aplikací a operátory clusteru
Složitost konfigurace pro pozorovatelnost Malý zájem Vysoká Střední

Doporučení k návrhu

Implementujte Open Service Mesh, abyste získali pozorovatelnost ve stavu a výkonu vašich služeb. Open Service Mesh používá proxy sajdkáře vložené jako samostatný kontejner do stejných podů jako úlohy k získání telemetrických dat. Tyto proxy servery zachycují veškerý příchozí a odchozí provoz HTTP do vašich úloh a hlásí data službě Open Service Mesh. V tomto systému nemusí vývojáři služeb instrumentovat kód ke shromažďování telemetrických dat.

Povolte Open Service Mesh pomocí funkce rozšíření clusteru Kubernetes s podporou Azure Arc, která microsoftu umožňuje spravovat řídicí rovinu za vás. Další informace najdete v tématu Nasazení open service mesh s podporou Služby Azure Arc (Preview).

Pokud chcete maximalizovat dostupnost a výkon aplikací a služeb, povolte službu Azure Monitor Container Insights. Poskytuje komplexní řešení pro shromažďování, analýzu a akce na telemetrii z vašich cloudových a místních prostředí. Open Service Mesh s podporou Služby Azure Arc se integruje hluboko se službou Azure Monitor a poskytuje bezproblémovou metodu zobrazení klíčových ukazatelů výkonu poskytovaných metrikami OSM a protokoly kontejnerů aplikací a reagovat na ně. Metriky OSM můžete povolit pomocí následujícího postupu. Pro distribuované trasování doporučujeme Jaeger, který se dá integrovat s řídicí rovinou OSM.

Open Service Mesh také poskytuje zdokumentované integrace pozorovatelnosti pro metriky s Prometheus a Grafana, trasování pomocí Jaegeru a předávání protokolů pomocí Fluent Bitu. Tyto integrace poskytují alternativní možnosti, pokud nepoužíváte řešení monitorování Azure. Tyto integrace můžete použít k rozšíření dalších interních monitorovacích nástrojů podle potřeby.

Minimálně byste měli definovat následující tři metriky RED a měřit je pro všechny služby:

  • Frekvence požadavků: Počet požadavků, které služba přijímá za sekundu.
  • Chyby: Počet neúspěšných požadavků nebo četnost neúspěšných požadavků za sekundu.
  • Doba trvání: Doba, kterou služba potřebuje ke zpracování žádosti.

Open Service Mesh poskytuje několik předkonfigurovaných sešitů služby ve službě Azure Monitor, takže nemusíte řídicí panely a grafy nastavovat ručně. Tato podrobná telemetrie umožňuje sledovat chování služeb a umožňuje vám řešit potíže, udržovat a optimalizovat aplikace. Pomocí sešitu monitorování OSM ve službě Azure Monitor můžete:

  • Získejte přehled o všech službách ve vaší síti a získejte kritické metriky na úrovni služby pro tři ze čtyř zlatých signálů monitorování: latence, požadavky a chyby.
  • Definujte, zkontrolujte a nastavte upozornění na cíle úrovně služeb (SLO), které shrnují výkon viditelného uživatelem vaší služby.
  • Zobrazte grafy metrik pro jednotlivé služby, abyste je mohli hlouběji analyzovat pomocí filtrování a rozpisů, siftování dat podle kódu odpovědi, protokolu, cílového podu, zdroje provozu a dalších.

Pomocí vizualizací z uživatelského rozhraní Jaegeru můžete:

  • Podívejte se na vizualizaci grafu topologie, která ukazuje, které mikroslužby vzájemně komunikují, kde se požadavky procházejí a jak dlouho trvá.
  • Zkontrolujte konkrétní požadavky a odpovědi, abyste zjistili, jak a kdy k nim dochází při monitorování a řešení potíží s distribuovanými systémy.

Pozorovatelnost služeb je jen jedna disciplína vaší strategie monitorování cloudu. Další informace odisciplínch

Další kroky

Další informace o cestě k hybridnímu a multicloudovém cloudu najdete v následujících článcích: