Monitorování clusteru

Je důležité monitorovat na úrovni clusteru, abyste zjistili, jestli se váš hardware a cluster chovají podle očekávání. Service Fabric sice může udržovat aplikace spuštěné během selhání hardwaru, ale přesto je potřeba diagnostikovat, jestli v aplikaci nebo v základní infrastruktuře dochází k chybě. Clustery byste také měli monitorovat, abyste lépe plánovali kapacitu a pomohli při rozhodování o přidávání nebo odebírání hardwaru.

Service Fabric zpřístupňuje několik strukturovaných událostí platformy, jako události Service Fabric, prostřednictvím eventstoru a různých kanálů protokolů.

Ve Windows jsou události Service Fabric k dispozici od jednoho zprostředkovatele Trasování událostí pro Windows se sadou relevantních logLevelKeywordFilters pro výběr mezi kanály Provozní a Data &Messaging . Je to způsob, jakým oddělujeme odchozí události Service Fabric, na které se mají podle potřeby filtrovat.

  • Provozní operace vysoké úrovně prováděné Service Fabric a clusterem, včetně událostí pro nadcházející uzel, nasazení nové aplikace nebo vrácení upgradu atd. Tady najdete úplný seznam událostí.

  • Provozní – podrobný
    Rozhodnutí o stavu a vyrovnávání zatížení

K kanálu operací je možné přistupovat různými způsoby, včetně protokolů událostí pro Windows nebo Událostí Windows, EventStore (k dispozici ve Windows ve verzích 6.2 a novějších pro clustery s Windows). EventStore poskytuje přístup k událostem clusteru na základě entity (entity včetně clusteru, uzlů, aplikací, služeb, oddílů, replik a kontejnerů) a zveřejňuje je prostřednictvím rozhraní REST API a klientské knihovny Service Fabric. EventStore slouží k monitorování vývojových/testovacích clusterů a k pochopení stavu produkčních clusterů k určitému bodu v čase.

  • Data a zasílání zpráv
    Kritické protokoly a události generované v zasílání zpráv (aktuálně pouze ReverseProxy) a cestu k datům (modely spolehlivých služeb).

  • Data & Messaging – podrobné informace
    Podrobný kanál, který obsahuje všechny nekritické protokoly z dat a zasílání zpráv v clusteru (tento kanál má velký objem událostí).

Kromě toho jsou k dispozici dva strukturované kanály EventSource a také protokoly, které shromažďujeme pro účely podpory.

  • Události Reliable Services
    Události specifické pro programovací model

  • Události Reliable Actors
    Programovací model specifické události a čítače výkonu

  • Protokoly podpory
    Systémové protokoly vygenerované Službou Service Fabric, které nás používají pouze při poskytování podpory.

Tyto různé kanály pokrývají většinu protokolování na úrovni platformy, které se doporučuje. Pokud chcete zlepšit protokolování na úrovni platformy, zvažte investice do lepšího porozumění modelu stavu a přidání vlastních sestav o stavu a přidání vlastních čítačů výkonu, abyste v reálném čase pochopili dopad služeb a aplikací na cluster.

Pokud chcete tyto protokoly využít, důrazně doporučujeme nechat při vytváření clusteru na webu Azure Portal povolenou diagnostiku. Zapnutím diagnostiky po nasazení clusteru dokáže Diagnostika Azure potvrdit kanály Operational, Reliable Services a Reliable Actors a ukládat data, jak je vysvětleno dále v agregačních událostech pomocí diagnostiky Azure.

Generování sestav stavu a zatížení Azure Service Fabric

Service Fabric má vlastní model stavu, který je podrobně popsaný v těchto článcích:

Monitorování stavu je důležité pro různé aspekty provozu služby, zejména při upgradu aplikace. Po upgradu každé upgradované domény služby musí doména upgradu před přechodem na další doménu upgradu předat kontroly stavu. Pokud se stav OK nedá dosáhnout, nasazení se vrátí zpět, aby aplikace zůstala ve známém stavu OK. I když některé zákazníky můžou být ovlivněné dříve, než se služby vrátí zpět, většina zákazníků nebude mít problém. Řešení se také vyskytuje poměrně rychle, aniž byste museli čekat na akci od lidského operátora. Čím více kontrol stavu, které jsou součástí vašeho kódu, tím odolnější vaše služba je problémy s nasazením.

Dalším aspektem stavu služby je generování metrik ze služby. Metriky jsou v Service Fabric důležité, protože se používají k vyrovnávání využití prostředků. Metriky můžou být také indikátorem stavu systému. Můžete mít například aplikaci, která má mnoho služeb a každá instance hlásí metriku požadavků za sekundu (RPS). Pokud jedna služba používá více prostředků než jiná služba, Service Fabric přesune instance služby kolem clusteru, aby se pokusila zachovat i využití prostředků. Podrobnější vysvětlení fungování využití prostředků najdete v tématu Správa spotřeby prostředků a načítání v Service Fabric s využitím metrik.

Metriky vám také můžou pomoct získat přehled o výkonu vaší služby. V průběhu času můžete pomocí metrik zkontrolovat, jestli služba funguje v rámci očekávaných parametrů. Pokud například trendy ukazují, že v pondělí ráno je průměrná hodnota RPS 1 000, můžete nastavit zprávu o stavu, která vás upozorní, pokud je rps nižší než 500 nebo vyšší než 1 500. Všechno může být naprosto v pořádku, ale možná stojí za to, abyste měli jistotu, že vaši zákazníci mají skvělý zážitek. Vaše služba může definovat sadu metrik, které se dají hlásit pro účely kontroly stavu, ale nemají vliv na vyrovnávání prostředků clusteru. Uděláte to tak, že nastavíte váhu metriky na nulu. Doporučujeme spustit všechny metriky s váhu nulou a nezvyšovat váhu, dokud si nejste jisti, že víte, jak vážené metriky ovlivňují vyrovnávání prostředků pro váš cluster.

Tip

Nepoužívejte příliš mnoho vážených metrik. Může být obtížné pochopit, proč se instance služeb přesouvají kvůli vyrovnávání. Několik metrik může trvat dlouho!

Všechny informace, které můžou znamenat stav a výkon vaší aplikace, jsou kandidátem na metriky a sestavy stavu. Čítač výkonu procesoru vám může říct, jak se uzel využívá, ale neřekne vám, jestli je konkrétní služba v pořádku, protože na jednom uzlu může běžet více služeb. Metriky, jako jsou RPS, zpracovávané položky a latence požadavků, ale můžou znamenat stav konkrétní služby.

Protokoly podpory Service Fabric

Pokud potřebujete kontaktovat podporu Microsoftu a požádat o pomoc s clusterem Azure Service Fabric, protokoly podpory se téměř vždy vyžadují. Pokud je váš cluster hostovaný v Azure, protokoly podpory se automaticky nakonfigurují a shromažďují jako součást vytváření clusteru. Protokoly se ukládají do vyhrazeného účtu úložiště ve skupině prostředků vašeho clusteru. Účet úložiště nemá pevný název, ale v účtu uvidíte kontejnery objektů blob a tabulky s názvy, které začínají prostředky infrastruktury. Informace o nastavení kolekcí protokolů pro samostatný cluster najdete v tématu Vytvoření a správa samostatného clusteru Azure Service Fabric a nastavení konfigurace pro samostatný cluster s Windows. V případě samostatných instancí Service Fabric by se protokoly měly odesílat do místní sdílené složky. Tyto protokoly musíte mít pro podporu, ale nemají být použitelné kýmkoli, kdo není členem týmu zákaznické podpory Microsoftu.

Měření výkonu

Změřte výkon clusteru, abyste pochopili, jak dokáže zvládnout zatížení a řídit rozhodování ohledně škálování clusteru (další informace o škálování clusteru v Azure nebo místním prostředí). Data o výkonu jsou užitečná také v porovnání s akcemi, které jste vy nebo vaše aplikace a služby provedli při analýze protokolů v budoucnu.

Seznam čítačů výkonu, které se mají shromažďovat při použití Service Fabric, najdete v tématu Metriky výkonu.

Tady jsou dva běžné způsoby, jak můžete nastavit shromažďování dat o výkonu clusteru:

  • Použití agenta
    Toto je upřednostňovaný způsob shromažďování výkonu z počítače, protože agenti obvykle mají seznam možných metrik výkonu, které je možné shromažďovat, a jedná se o relativně snadný proces výběru metrik, které chcete shromažďovat nebo měnit. Přečtěte si informace o službě Azure Monitor nabízející protokoly Azure Monitoru v integraci protokolů Služby Azure Monitor a nastavení agenta Log Analytics, abyste se dozvěděli více o agentovi Log Analytics, což je jeden takový agent monitorování, který dokáže vyzvednout data o výkonu pro virtuální počítače clusteru a nasazené kontejnery.

  • Čítače výkonu ve službě Azure Table Storage
    Metriky výkonu můžete také odesílat do stejného úložiště tabulek jako události. To vyžaduje změnu konfigurace diagnostiky Azure, aby se z virtuálních počítačů ve vašem clusteru získaly odpovídající čítače výkonu a aby bylo možné vyzvednout statistiky Dockeru, pokud nasadíte nějaké kontejnery. Přečtěte si o konfiguraci čítačů výkonu v WAD v Service Fabric pro nastavení shromažďování čítačů výkonu.

Další kroky