Monitorování a Diagnostika pro Azure Service Fabric

Tento článek poskytuje přehled monitorování a diagnostiky pro Azure Service Fabric. Monitorování a diagnostika jsou zásadní pro vývoj, testování a nasazování úloh v jakémkoli cloudovém prostředí. můžete například sledovat, jak se aplikace používají, akce prováděné Service Fabric platformou, využití prostředků s čítači výkonu a celkový stav clusteru. Pomocí těchto informací můžete diagnostikovat a opravovat problémy a zabránit jejich výskytu v budoucnu. další části stručně vysvětlují každou oblast Service Fabric monitorování, které je potřeba vzít v úvahu pro produkční úlohy.

Poznámka

Tento článek byl nedávno aktualizován, aby používal Azure Monitor protokoly místo Log Analytics. Data protokolu se pořád ukládají do Log Analyticsho pracovního prostoru a pořád se shromažďují a analyzují pomocí stejné služby Log Analytics. Aktualizujeme terminologii, aby lépe odrážela roli protokolů v Azure monitor. Podrobnosti najdete v tématu Azure monitor změny terminologie .

Monitorování aplikace

Monitorování aplikací sleduje, jak se používají funkce a komponenty vaší aplikace. Chcete monitorovat své aplikace, abyste měli jistotu, že jsou zachyceny problémy, které mají vliv na uživatele. Zodpovědnost za monitorování aplikací je na uživatelích, kteří vyvíjí aplikaci a její služby, protože je jedinečná pro obchodní logiku vaší aplikace. Monitorování aplikací může být užitečné v následujících scénářích:

  • Kolik provozu má aplikace? – Potřebujete škálovat vaše služby tak, aby splňovaly požadavky uživatelů, nebo řešit potenciální kritická místa ve vaší aplikaci?
  • Je moje služba pro volání úspěšná a sledovaná?
  • Jaké akce jsou přijímány uživateli mé aplikace? – Shromažďování telemetrie může sloužit pro budoucí vývoj funkcí a lepší diagnostiku pro chyby aplikací.
  • Vyvolává moje aplikace neošetřené výjimky?
  • Co se děje v rámci služeb spuštěných uvnitř kontejnerů?

Důležité informace o monitorování aplikací je, že vývojáři můžou používat libovolné nástroje a architektury, které by chtěli, protože jsou v kontextu vaší aplikace. další informace o řešení Azure pro monitorování aplikací najdete v Azure Monitor Application Insights při analýze událostí pomocí Application Insights. K dispozici je také kurz s nastavením pro aplikace .NET. V tomto kurzu se naučíte, jak nainstalovat správné nástroje, příklad pro psaní vlastní telemetrie ve vaší aplikaci a zobrazení diagnostiky aplikace a telemetrie v Azure Portal.

Monitorování platformy (clusteru)

uživatel má kontrolu nad tím, co telemetrie pochází ze své aplikace, protože uživatel zapisuje samotný kód, ale co se týče diagnostiky od Service Fabric platformy? jedním z cílů Service Fabric je zajištění odolnosti aplikací proti selhání hardwaru. Tento cíl se dosahuje prostřednictvím schopnosti systémových služeb platformy zjistit problémy infrastruktury a rychlé úlohy převzetí služeb při selhání na jiné uzly v clusteru. V tomto konkrétním případě se ale v takovém případě k tomu, co kdyby vlastní systémové služby, neproblémují? Nebo pokud při pokusu o nasazení nebo přesunutí úlohy dojde k porušení pravidel pro umístění služeb? Service Fabric poskytuje diagnostiku pro tyto a další informace, abyste měli jistotu, že se v clusteru probíhají aktivity. Mezi příklady scénářů pro monitorování clusteru patří:

Service Fabric poskytuje ucelenou sadu událostí z boxu. k těmto událostem Service Fabric se dá dostat prostřednictvím eventstoru nebo provozního kanálu (kanál událostí vystavený platformou).

  • Service Fabric kanálů událostí – v Windows jsou Service Fabric události k dispozici od jednoho poskytovatele ETW se sadou relevantních, která se logLevelKeywordFilters používá k výběru mezi provozními a & datovými kanály pro zasílání zpráv. to je způsob, jakým oddělíme odchozí Service Fabric události, které se podle potřeby mají filtrovat. v systému Linux Service Fabric události pocházejí prostřednictvím LTTng a jsou vloženy do jedné Storage tabulky, ze které je lze podle potřeby filtrovat. Tyto kanály obsahují uspořádané strukturované události, které je možné použít k lepšímu pochopení stavu clusteru. v době vytváření clusteru jsou diagnostiky standardně povolené, takže se vytvoří tabulka Azure Storage, kde se události z těchto kanálů odesílají do budoucna k dotazování v budoucnosti.

  • eventstoru – eventstoru je funkce nabízená platformou, která poskytuje Service Fabric události platformy dostupné v Service Fabric Explorer a REST API. Pro každou entitu, např. Node, službu, aplikace a dotaz na základě času události, se můžete podívat na to, co se ve vašem clusteru chystá. Další informace o Eventstoru najdete v tématu Přehled eventstoru.

Snímek obrazovky se zobrazí na kartě události v podokně uzly několik událostí, včetně události NodeDown.

Poskytnuté diagnostiky jsou ve formě komplexní sady událostí mimo pole. tyto události Service Fabric ilustrují akce prováděné platformou na různých entitách, jako jsou uzly, aplikace, služby, oddíly atd. Pokud by byl uzel v posledním výše uvedeném případě mimo provoz, platforma by vygenerovala NodeDown událost a můžete ji okamžitě upozornit vámi zvoleným monitorovacím nástrojem. Mezi další běžné příklady patří ApplicationUpgradeRollbackStarted nebo PartitionReconfigured během převzetí služeb při selhání. stejné události jsou k dispozici v clusterech Windows i Linux.

události se odesílají přes standardní kanály na Windows i Linux a dají se číst libovolným monitorovacím nástrojem, který je podporuje. Řešení Azure Monitor je Azure Monitor protokolů. Můžete si přečíst další informace o integraci protokolů Azure monitor , které zahrnují vlastní operační řídicí panel pro váš cluster a některé ukázkové dotazy, ze kterých můžete vytvářet výstrahy. Další koncepty monitorování clusteru jsou k dispozici na úrovni platforem a generování protokolů.

Monitorování stavu

platforma Service Fabric zahrnuje model stavu, který poskytuje rozšiřitelné vytváření sestav o stavu pro stav entit v clusteru. Každý uzel, aplikace, služba, oddíl, replika nebo instance má nepřetržitě aktualizovatelný stav. Stav může být buď "OK", "Warning" nebo "Error". můžete si představit Service Fabric události jako operace prováděné clusterem do různých entit a stavu jako u každé entity jako přídavného jména. Pokaždé, když se změní stav konkrétní entity, vygeneruje se taky událost. Tímto způsobem můžete nastavit dotazy a výstrahy pro události stavu v monitorovacím nástroji zvoleném podobně jako u jakékoli jiné události.

Kromě toho i tak umožníme uživatelům přepsat stav entit. pokud vaše aplikace projde upgradem a testy ověření selžou, můžete zapisovat do Service Fabric stavu pomocí rozhraní API stavu, abyste označili, že aplikace už není v pořádku, a Service Fabric bude upgrade automaticky vrátit! další informace o modelu stavu najdete v úvodu ke Service Fabric sledování stavu .

Řídicí panel stavu SFX

Sledovací zařízení

Standardně se jedná o samostatnou službu, která sleduje stav a zatížení napříč službami, příkazy příkazového řádku otestuje a hlásí neočekávané události stavu v clusteru. To může přispět k tomu, aby nedocházelo k chybám, které se nemusí detekovat na základě výkonu jedné služby. Sledovací zařízení jsou také dobrým místem pro hostování kódu, který provádí nápravné akce, které nevyžadují zásah uživatele, jako je například čištění souborů protokolu v úložišti v určitých časových intervalech. pokud chcete plně implementovanou, open source službu pro sledovací prostředí pro SF, která zahrnuje snadno použitelný model rozšiřitelnosti sledovacího zařízení a který běží v obou clusterech Windows i Linux, přečtěte si téma projekt FabricObserver . FabricObserver je software připravený pro produkční prostředí. Doporučujeme, abyste nasadili FabricObserver do svých testovacích a produkčních clusterů a rozšířili je tak, aby vyhovovaly vašim potřebám, a to buď prostřednictvím modelu modulů plug-in, nebo rozvětvení a psaním vlastních předdefinovaných pozorovatelů. Předchozí přístup je doporučený (moduly plug-in).

Monitorování infrastruktury (výkonu)

Teď, když jsme pokryli diagnostiku ve vaší aplikaci a platformě, jak ví, že hardware funguje podle očekávání? Monitorování základní infrastruktury je klíčovou součástí porozumění stavu vašeho clusteru a využití prostředků. Měření výkonu systému závisí na mnoha faktorech, které mohou být v souladu s vašimi úlohami. Tyto faktory jsou obvykle měřeny prostřednictvím čítačů výkonu. tyto čítače výkonu můžou pocházet z nejrůznějších zdrojů, včetně operačního systému, rozhraní .net framework nebo samotné platformy Service Fabric. Některé scénáře, ve kterých by byly užitečné, jsou

  • Využívám svůj hardware efektivně? Chcete použít svůj hardware na procesorech 90% CPU nebo 10% CPU. To je užitečné při škálování clusteru nebo optimalizaci procesů aplikace.
  • Můžu aktivně předpovědět problémy infrastruktury? – mnoho problémů předchází náhlé změny (pokles) ve výkonu, takže můžete použít čítače výkonu, jako jsou síťové vstupně-výstupní operace a využití CPU, a předpovědět a diagnostikovat problémy interaktivně.

Seznam čítačů výkonu, které by měly být shromážděny na úrovni infrastruktury, najdete v části metriky výkonu.

Service Fabric také poskytuje sadu čítačů výkonu pro programové modely Reliable Services a actors. Pokud používáte některý z těchto modelů, můžou tyto čítače výkonu získat informace, aby se zajistilo, že se vaše aktéri správně otáčí a dolů nebo že vaše požadavky na spolehlivé služby jsou zpracovávány dostatečně rychle. Další informace najdete v tématu monitorování spolehlivé vzdálené komunikace služby a sledování výkonu pro Reliable Actors.

Azure Monitor řešení, které se má shromáždit, je Azure Monitor protokolů stejně jako monitorování na úrovni platformy. Log Analytics agenta byste měli použít ke shromáždění odpovídajících čítačů výkonu a jejich zobrazení v protokolech Azure monitor.

Teď, když jsme přešli na jednotlivé oblasti monitorování a ukázkových scénářů, tady je souhrn nástrojů pro monitorování Azure a potřebný pro monitorování všech oblastí výše.

K automatizaci nasazení všech nezbytných prostředků a agentů můžete také použít a upravit ukázkovou šablonu ARM, která se nachází zde .

Další řešení protokolování

i když jsou tato dvě řešení, která jsme doporučili, Azure Monitor protokoly a Application Insights vytvořili integraci s Service Fabric, mnoho událostí se zapisuje prostřednictvím poskytovatelů ETW a dají se rozšířit dalšími řešeními protokolování. Měli byste se také podívat do elastického zásobníku (obzvláště Pokud zvažujete spuštění clusteru v offline prostředí), dynaTracenebo jakékoli jiné platformy. Tady je seznam integrovaných partnerů, které jsou k dispozici zde.

Klíčové body pro libovolnou platformu, kterou si zvolíte, by měly zahrnovat to, jak vám vyhovuje uživatelské rozhraní, možnosti dotazování, vlastní vizualizace a řídicí panely a další nástroje, které poskytují, aby se vylepšily vaše možnosti monitorování.

Další kroky