Přidání vlastních sestav stavu Service Fabric

  • Článek

Azure Service Fabric zavádí model stavu navržený tak, aby označoval stav clusteru a aplikace, které nejsou v pořádku, u konkrétních entit. Model stavu používá reportéry stavu (systémové komponenty a hlídací zařízení). Cílem je snadná a rychlá diagnostika a oprava. Autoři služeb musí předem přemýšlet o stavu. Všechny podmínky, které mohou mít vliv na stav, by měly být hlášeny, zejména pokud to může pomoct označit problémy blízko kořenovému adresáři. Informace o stavu můžou ušetřit čas a úsilí při ladění a vyšetřování. Užitečnost je jasná zejména tehdy, když je služba zprovozněná ve velkém měřítku v cloudu (privátním nebo Azure).

Zpravodajé Service Fabric monitorují zjištěné podmínky zájmu. Tyto podmínky hlásí na základě svého místního zobrazení. Úložiště stavů agreguje data o stavu odesílaná všemi zpravodaji a určuje, jestli jsou entity globálně v pořádku. Model má být bohatý, flexibilní a snadno použitelný. Kvalita zpráv o stavu určuje přesnost zobrazení stavu clusteru. Falešně pozitivní výsledky, které nesprávně ukazují problémy, které nejsou v pořádku, můžou negativně ovlivnit upgrady nebo jiné služby, které používají data o stavu. Příkladem takových služeb jsou opravné služby a mechanismy upozorňování. Proto je potřeba uvažovat o poskytování sestav, které co nejlépe zachycují podmínky zájmu.

Při návrhu a implementaci generování sestav stavu musí hlídací zařízení a systémové komponenty:

  • Definujte podmínku, která je zajímá, způsob monitorování a dopad na funkce clusteru nebo aplikace. Na základě těchto informací rozhodněte o vlastnosti a stavu sestavy stavu.
  • Určete entitu , na kterou se sestava vztahuje.
  • Určete, kde se hlášení provádí, ať už v rámci služby nebo z interního či externího sledovacího zařízení.
  • Definujte zdroj sloužící k identifikaci zpravodaje.
  • Zvolte strategii generování sestav, a to buď pravidelně, nebo pro přechody. Doporučený způsob je pravidelně, protože vyžaduje jednodušší kód a je méně náchylný k chybám.
  • Určete, jak dlouho by měla sestava pro stav, který není v pořádku, zůstat v úložišti stavu a jak se má vymazat. Na základě těchto informací můžete určit dobu života sestavy a chování odebrání při vypršení platnosti.

Jak už bylo zmíněno, vytváření sestav lze provádět z:

  • Monitorovaná replika služby Service Fabric.
  • Interní sledovací zařízení nasazená jako služba Service Fabric (například bezstavová služba Service Fabric, která monitoruje podmínky a vydává sestavy). Watchdogs je možné nasadit na všechny uzly nebo spřažení s monitorovanou službou.
  • Interní sledovací zařízení, která běží na uzlech Service Fabric, ale nejsou implementovaná jako služby Service Fabric.
  • Externí sledovací centra, která testuje prostředek mimo cluster Service Fabric (například monitorovací služba, jako je Gomez).

Poznámka

Cluster se automaticky naplní zprávami o stavu, které odesílají systémové komponenty. Další informace najdete v tématu Použití sestav stavu systému k řešení potíží. Uživatelské sestavy se musí odesílat u entit stavu , které už systém vytvořil.

Jakmile je návrh sestav o stavu jasný, můžete snadno odesílat zprávy o stavu. Pokud cluster není zabezpečený nebo pokud má klient prostředků infrastruktury oprávnění správce, můžete k hlášení stavu použít FabricClient. Generování sestav je možné provádět prostřednictvím rozhraní API pomocí FabricClient.HealthManager.ReportHealth, powershellu nebo rest. Sestavy dávek konfiguračních uzlů pro zvýšení výkonu

Poznámka

Stav sestavy je synchronní a představuje pouze ověřovací práci na straně klienta. Skutečnost, že je sestava přijata klientem stavu nebo Partition objekty nebo CodePackageActivationContext , neznamená, že je použita v úložišti. Odesílá se asynchronně a případně v dávce s jinými sestavami. Zpracování na serveru stále může selhat: pořadové číslo může být zastaralé, entita, na kterou se sestava musí použít, byla odstraněna atd.

Klient stavu

Zprávy o stavu se odesílají správci stavu prostřednictvím klienta stavu, který se nachází uvnitř klienta prostředků infrastruktury. Správce stavu ukládá sestavy do úložiště stavů. Klienta stavu je možné nakonfigurovat s následujícími nastaveními:

  • HealthReportSendInterval: Prodleva mezi okamžikem, kdy je sestava přidána do klienta, a časem odeslání do správce stavu. Používá se k dávce sestav do jedné zprávy, nikoli k odesílání jedné zprávy pro každou sestavu. Dávkování zvyšuje výkon. Výchozí hodnota: 30 sekund.
  • HealthReportRetrySendInterval: Interval, ve kterém klient stavu znovu odesílá kumulované zprávy o stavu správci stavů. Výchozí hodnota: 30 sekund, minimum: 1 sekunda.
  • HealthOperationTimeout: Časový limit zprávy sestavy odeslané správci stavu. Pokud dojde k vypršení časového limitu zprávy, klient stavu ji opakuje, dokud správce stavu nepotvrdí, že sestava byla zpracována. Výchozí hodnota: dvě minuty.

Poznámka

Když jsou sestavy rozdělené do dávek, musí být klient prostředků infrastruktury aktivní alespoň po dobu HealthReportSendInterval, aby se zajistilo, že se odesílají. Pokud dojde ke ztrátě zprávy nebo pokud ji správce stavu nemůže použít kvůli přechodným chybám, musí být klient prostředků infrastruktury aktivní déle, aby měl možnost to zkusit znovu.

Ukládání do vyrovnávací paměti v klientovi bere v úvahu jedinečnost sestav. Pokud například konkrétní špatný zpravodaj hlásí 100 sestav za sekundu ve stejné vlastnosti stejné entity, nahradí se sestavy poslední verzí. Ve frontě klienta existuje nejvýše jedna taková sestava. Pokud je nakonfigurované dávkování, je počet sestav odeslaných správci stavu pouze jeden za interval odesílání. Tato sestava je poslední přidanou sestavou, která odráží nejaktuálnější stav entity. Zadejte parametry konfigurace při FabricClient vytvoření předáním FabricClientSettings s požadovanými hodnotami pro položky související se stavem.

Následující příklad vytvoří klienta prostředků infrastruktury a určí, že se sestavy mají při jejich přidání odeslat. Při vypršení časových limitů a chybách, které je možné opakovat, k opakování dochází každých 40 sekund.

var clientSettings = new FabricClientSettings()
{
    HealthOperationTimeout = TimeSpan.FromSeconds(120),
    HealthReportSendInterval = TimeSpan.FromSeconds(0),
    HealthReportRetrySendInterval = TimeSpan.FromSeconds(40),
};
var fabricClient = new FabricClient(clientSettings);

Doporučujeme ponechat výchozí nastavení klienta prostředků infrastruktury, které je nastavené HealthReportSendInterval na 30 sekund. Toto nastavení zajišťuje optimální výkon díky dávkování. V případě kritických sestav, které je potřeba odeslat co nejdříve, použijte s možností HealthReportSendOptions Immediate true v rozhraní FabricClient.HealthClient.ReportHealth API. Okamžité sestavy obejdou interval dávkování. Používejte tento příznak opatrně; Chceme využít dávkování klienta stavu, kdykoli je to možné. Okamžité odeslání je užitečné také v případě, že se klient prostředků infrastruktury zavírá (například proces určil neplatný stav a musí se vypnout, aby se zabránilo vedlejším účinkům). Zajišťuje odeslání nahromaděných sestav s maximálním úsilím. Když se přidá jedna sestava s příznakem Immediate, klient stavu přidá všechny sestavy shromážděné od posledního odeslání do dávek.

Stejné parametry je možné zadat při vytvoření připojení ke clusteru prostřednictvím PowerShellu. Následující příklad spustí připojení k místnímu clusteru:

PS C:\> Connect-ServiceFabricCluster -HealthOperationTimeoutInSec 120 -HealthReportSendIntervalInSec 0 -HealthReportRetrySendIntervalInSec 40
True

ConnectionEndpoint   :
FabricClientSettings : {
                       ClientFriendlyName                   : PowerShell-1944858a-4c6d-465f-89c7-9021c12ac0bb
                       PartitionLocationCacheLimit          : 100000
                       PartitionLocationCacheBucketCount    : 1024
                       ServiceChangePollInterval            : 00:02:00
                       ConnectionInitializationTimeout      : 00:00:02
                       KeepAliveInterval                    : 00:00:20
                       HealthOperationTimeout               : 00:02:00
                       HealthReportSendInterval             : 00:00:00
                       HealthReportRetrySendInterval        : 00:00:40
                       NotificationGatewayConnectionTimeout : 00:00:00
                       NotificationCacheUpdateTimeout       : 00:00:00
                       }
GatewayInformation   : {
                       NodeAddress                          : localhost:19000
                       NodeId                               : 1880ec88a3187766a6da323399721f53
                       NodeInstanceId                       : 130729063464981219
                       NodeName                             : Node.1
                       }

Podobně jako rozhraní API je možné sestavy odesílat pomocí -Immediate přepínače a odesílat je okamžitě bez ohledu na HealthReportSendInterval hodnotu.

V případě REST se sestavy odesílají do brány Service Fabric, která má interního klienta prostředků infrastruktury. Ve výchozím nastavení je tento klient nakonfigurovaný tak, aby odesílal sestavy v dávkách každých 30 sekund. Interval dávky můžete změnit pomocí nastavení HttpGatewayHealthReportSendInterval konfigurace clusteru na HttpGateway. Jak už bylo zmíněno, lepší možností je odeslat sestavy s Immediate hodnotou true.

Poznámka

Pokud chcete zajistit, aby neautorizované služby nemohly hlásit stav entit v clusteru, nakonfigurujte server tak, aby přijímal pouze požadavky od zabezpečených klientů. Objekt FabricClient používaný pro generování sestav musí mít povolené zabezpečení, aby bylo možné komunikovat s clusterem (například s protokolem Kerberos nebo ověřováním certifikátu). Přečtěte si další informace o zabezpečení clusteru.

Sestavy ze služeb s nízkými oprávněními

Pokud služby Service Fabric nemají přístup správce ke clusteru, můžete hlásit stav entit z aktuálního kontextu prostřednictvím nebo PartitionCodePackageActivationContext.

Poznámka

Interně je Partition klient stavu a CodePackageActivationContext blokování nakonfigurovaný s výchozím nastavením. Jak je vysvětleno pro klienta stavu, sestavy se dávkují a odesílají časovačem. Objekty by měly být udržovány naživu, aby měly možnost odeslat sestavu.

Můžete určit HealthReportSendOptions , kdy se sestavy odesílají prostřednictvím Partition rozhraní API pro stav a CodePackageActivationContext . Pokud máte kritické sestavy, které je potřeba odeslat co nejdříve, použijte s okamžitým truepoužitím HealthReportSendOptions . Okamžité sestavy obcházejí interval dávkování klienta interního stavu. Jak již bylo zmíněno dříve, používejte tento příznak opatrně; chceme využít dávkování klienta stavu, kdykoli je to možné.

Vytváření sestav o stavu návrhu

Prvním krokem při generování vysoce kvalitních sestav je identifikace podmínek, které můžou ovlivnit stav služby. Jakákoli podmínka, která může pomoct označit problémy ve službě nebo clusteru při spuštění – nebo ještě lépe, než k problému dojde – může potenciálně ušetřit miliardy dolarů. Mezi výhody patří kratší doba výpadku, méně nočních hodin strávených zkoumáním a opravou problémů a vyšší spokojenost zákazníků.

Jakmile jsou podmínky identifikovány, musí autoři sledovacích zařízení přijít na nejlepší způsob, jak je monitorovat z hlediska rovnováhy mezi režií a užitečností. Představte si například službu, která dělá složité výpočty, které používají některé dočasné soubory ve sdílené složce. Sledovací zařízení může sdílenou složku monitorovat, aby se zajistilo, že je k dispozici dostatek místa. Může naslouchat oznámením o změnách souborů nebo adresářů. V případě dosažení prahové hodnoty předem může hlásit upozornění, a pokud je sdílená složka plná, může hlásit chybu. V případě upozornění může systém opravy spustit čištění starších souborů ve sdílené složce. V případě chyby může systém opravy přesunout repliku služby do jiného uzlu. Všimněte si, jak jsou stavy podmínky popsány z hlediska stavu: stav podmínky, kterou lze považovat za stav v pořádku (ok) nebo stav, který není v pořádku (upozornění nebo chyba).

Jakmile jsou podrobnosti monitorování nastaveny, musí autor sledovacího zařízení zjistit, jak hlídacího psa implementovat. Pokud je možné podmínky určit přímo ve službě, může být sledovací zařízení součástí samotné monitorované služby. Kód služby může například zkontrolovat využití sdílené složky a pak hlásit pokaždé, když se pokusí napsat soubor. Výhodou tohoto přístupu je, že vytváření sestav je jednoduché. Je třeba věnovat pozornost tomu, aby chyby watchdog ovlivnily funkčnost služby.

Generování sestav z monitorované služby není vždy možné. Sledovací pes v rámci služby nemusí být schopen zjistit podmínky. Nemusí mít logiku nebo data k určení. Režie související s monitorováním podmínek může být vysoká. Podmínky také nemusí být specifické pro službu, ale místo toho ovlivňují interakce mezi službami. Další možností je mít v clusteru watchdogs jako samostatné procesy. Hlídací čudové monitorují podmínky a hlásí je, aniž by to jakkoli ovlivnilo hlavní služby. Například tyto hlídací hlídací zařízení lze implementovat jako bezstavové služby ve stejné aplikaci, nasazené na všech uzlech nebo na stejných uzlech jako služba.

V některých případech není možné použít sledovacího zařízení běžícího v clusteru. Pokud je monitorovanou podmínkou dostupnost nebo funkčnost služby tak, jak ji vidí uživatelé, je nejlepší mít sledovací zařízení na stejném místě jako klienti uživatelů. Tam můžou operace testovat stejným způsobem, jakým je uživatelé volají. Můžete mít například sledovacího zařízení, které žije mimo cluster, vydává požadavky na službu a kontroluje latenci a správnost výsledku. (Například pro službu kalkulačky vrátí 2+2 za rozumnou dobu hodnotu 4?)

Po dokončení podrobností watchdogu byste se měli rozhodnout pro id zdroje, které ho jednoznačně identifikuje. Pokud v clusteru žije více sledovacích čudů stejného typu, musí hlásit různé entity, nebo pokud hlásí stejnou entitu, musí použít jiné ID zdroje nebo vlastnost. Tímto způsobem můžou jejich sestavy existovat společně. Vlastnost sestavy o stavu by měla zachytit monitorovanou podmínku. (Ve výše uvedeném příkladu může být vlastnost ShareSize.) Pokud se na stejnou podmínku vztahuje více sestav, měla by vlastnost obsahovat některé dynamické informace, které umožňují, aby sestavy spoluexistily. Pokud je například potřeba monitorovat více sdílených složek, může být název vlastnosti ShareSize-sharename.

Poznámka

Nepoužívejte úložiště stavu k uchovávání informací o stavu. Jako stav by se měly hlásit pouze informace související se stavem, protože tyto informace mají vliv na vyhodnocení stavu entity. Úložiště stavu nebylo navržené jako úložiště pro obecné účely. Používá logiku vyhodnocení stavu k agregaci všech dat do stavu. Odeslání informací nesouvisejících se stavem (například stav hlášení se stavem OK) nemá vliv na agregovaný stav, ale může negativně ovlivnit výkon úložiště stavu.

Dalším rozhodovacím bodem je entita, která se má hlásit. Ve většině případů podmínka jasně identifikuje entitu. Vyberte entitu s nejlepší možnou členitostí. Pokud se podmínka týká všech replik v oddílu, vytvořte sestavu pro oddíl, ne pro službu. Existují však případy, kdy je potřeba více myslet. Pokud má podmínka vliv na entitu, například repliku, ale chcete, aby se podmínka označovala příznakem déle, než je doba životnosti repliky, měla by se hlásit v oddílu. V opačném případě po odstranění repliky úložiště stavu vyčistí všechny své sestavy. Autoři sledovacích zařízení musí přemýšlet o životnosti entity a sestavy. Musí být jasné, kdy se má sestava vyčistit z úložiště (například když už neplatí chyba hlášená u entity).

Pojďme se podívat na příklad, který spojuje body, které jsem popsal. Představte si aplikaci Service Fabric, která se skládá z hlavní stavové trvalé služby a sekundárních bezstavových služeb nasazených na všech uzlech (jeden sekundární typ služby pro každý typ úlohy). Hlavní server má frontu zpracování, která obsahuje příkazy, které mají být provedeny sekundárními. Sekundárníci spouštějí příchozí požadavky a odesílají zpět signály potvrzení. Jednou z podmínek, kterou je možné monitorovat, je délka fronty hlavního zpracování. Pokud délka hlavní fronty dosáhne prahové hodnoty, zobrazí se upozornění. Upozornění indikuje, že sekundární počítače nezvládnou zatížení. Pokud fronta dosáhne maximální délky a příkazy se vyřadí, nahlásí se chyba, protože služba se nemůže obnovit. Sestavy mohou být ve vlastnosti QueueStatus. Sledovací zařízení žije ve službě a pravidelně se odesílá na hlavní primární repliku. Doba života je dvě minuty a odesílá se pravidelně každých 30 sekund. Pokud primární server přestane fungovat, sestava se automaticky vyčistí z úložiště. Pokud je replika služby spuštěná, ale je zablokovaná nebo má jiné problémy, platnost sestavy v úložišti stavů vyprší. V tomto případě se entita vyhodnotí jako chyba.

Další podmínkou, kterou je možné monitorovat, je doba provádění úlohy. Hlavní server distribuuje úkoly do sekundárních databází na základě typu úkolu. V závislosti na návrhu může hlavní server dotazovat sekundární uživatele na stav úkolu. Může také počkat, až sekundárním uživatelům po dokončení odešlou zpět potvrzovací signály. Ve druhém případě je třeba věnovat pozornost detekci situací, kdy sekundáři zemřou nebo dojde ke ztrátě zpráv. Jednou z možností je, že hlavní server odešle požadavek ping do stejného sekundárního serveru, který odešle zpět jeho stav. Pokud není přijat žádný stav, hlavní server ho považuje za selhání a úkol přeplánuje. Toto chování předpokládá, že úlohy jsou idempotentní.

Monitorovanou podmínku lze přeložit jako upozornění, pokud úkol není hotový v určité době (t1, například 10 minut). Pokud se úkol nedokončí včas (t2, například 20 minut), dá se monitorovaná podmínka přeložit jako Chyba. Toto vytváření sestav je možné provést několika způsoby:

  • Hlavní primární replika se pravidelně hlásí. Pro všechny čekající úkoly ve frontě můžete mít jednu vlastnost. Pokud alespoň jeden úkol trvá déle, stav sestavy ve vlastnosti PendingTasks je upozornění nebo chyba podle potřeby. Pokud neexistují žádné čekající úkoly nebo se spustily všechny úkoly, je stav sestavy v pořádku. Úkoly jsou trvalé. Pokud primární hodnota přestane fungovat, může se nově povýšená primární hodnota dál správně hlásit.
  • Jiný proces hlídacího zařízení (v cloudu nebo externím prostředí) kontroluje úkoly (z vnějšku, na základě požadovaného výsledku úkolu), aby zjistil, jestli jsou dokončené. Pokud tyto prahové hodnoty nerespektují, odešle se do hlavní služby sestava. Pro každý úkol se také odešle sestava, která obsahuje identifikátor úkolu, například PendingTask+taskId. Sestavy by se měly posílat jenom ve stavu, který není v pořádku. Nastavte hodnotu Time to Live na několik minut a označte sestavy, které se mají odebrat, když vyprší jejich platnost, abyste zajistili vyčištění.
  • Sekundární, který spouští úlohu, hlásí, když spuštění úlohy trvá déle, než se čekalo. Hlásí instanci služby ve vlastnosti PendingTasks. Sestava přesně označuje instanci služby, u které dochází k problémům, ale nezachycuje situaci, kdy instance zemře. Sestavy se pak vyčistí. Může hlásit sekundární službu. Pokud sekundární úkol dokončí, sekundární instance vymaže sestavu z úložiště. Sestava nezachytí situaci, kdy dojde ke ztrátě potvrzované zprávy a úkol není dokončen z pohledu hlavního procesu.

Ve výše popsaných případech se však sestavy zaznamenají do stavu aplikace při vyhodnocování stavu.

Pravidelné sestavy vs. při přechodu

Pomocí modelu generování sestav stavu můžou hlídací vývojáři posílat sestavy pravidelně nebo při přechodech. Doporučeným způsobem generování sestav sledovacích zařízení je pravidelné hlášení, protože kód je mnohem jednodušší a méně náchylný k chybám. Watchdogs se musí snažit být co nejjednodušší, aby se zabránilo chybám, které aktivují nesprávné sestavy. Nesprávné sestavy, které nejsou v pořádku , mají vliv na vyhodnocení stavu a scénáře na základě stavu, včetně upgradů. Nesprávné sestavy , které jsou v pořádku , skrývají problémy v clusteru, což není žádoucí.

Pro pravidelné hlášení může být hlídací zařízení implementováno s časovačem. Při zpětném volání časovače může sledovací zařízení zkontrolovat stav a odeslat sestavu na základě aktuálního stavu. Není potřeba vidět, která sestava byla odeslána dříve, ani provádět optimalizace z hlediska zasílání zpráv. Klient stavu má logiku dávkování, která pomáhá s výkonem. Zatímco je klient stavu aktivní, interně se opakuje, dokud se sestava nepotvrdí v úložišti stavů nebo sledovací zařízení negeneruje novější sestavu se stejnou entitou, vlastností a zdrojem.

Vytváření sestav přechodů vyžaduje pečlivé zpracování stavu. Sledovací pes monitoruje některé podmínky a hlásí pouze v případech, kdy se podmínky změní. Nevýhodou tohoto přístupu je, že je potřeba méně sestav. Nevýhodou je, že logika hlídacího psa je složitá. Hlídací pes musí udržovat podmínky nebo sestavy, aby je bylo možné zkontrolovat a určit změny stavu. Při převzetí služeb při selhání je potřeba dbát na to, aby se sestavy přidaly, ale ještě se neodesílaly do úložiště stavů. Pořadové číslo se musí neustále zvyšovat. Pokud ne, sestavy se zamítnou jako zastaralé. Ve výjimečných případech, kdy dojde ke ztrátě dat, může být nutná synchronizace mezi stavem zpravodaje a stavem úložiště stavů.

Generování sestav o přechodech má smysl pro služby, které se hlásí samy, prostřednictvím nebo PartitionCodePackageActivationContext. Při odebrání místního objektu (repliky nebo nasazeného balíčku služby / nasazené aplikace) se odeberou také všechny jeho sestavy. Toto automatické čištění uvolní potřebu synchronizace mezi reportérem a úložištěm stavů. Pokud je sestava určená pro nadřazený oddíl nebo nadřazenou aplikaci, je potřeba věnovat pozornost převzetí služeb při selhání, aby se zabránilo zastaralým sestavám v úložišti stavů. Pokud chcete zachovat správný stav a vymazat sestavu z úložiště, když už ji nepotřebujete, musíte přidat logiku.

Implementace generování sestav stavu

Jakmile jsou podrobnosti entity a sestavy jasné, můžete odesílat sestavy stavu prostřednictvím rozhraní API, PowerShellu nebo REST.

rozhraní API

Pokud chcete vytvářet sestavy prostřednictvím rozhraní API, musíte vytvořit sestavu stavu specifickou pro typ entity, o které chcete hlásit. Předáte sestavu klientovi se stavem. Případně můžete vytvořit informace o stavu a předat je správným metodám Partition generování sestav na aktuálních entitách nebo CodePackageActivationContext k jejich hlášení.

Následující příklad ukazuje pravidelné hlášení ze sledovacího zařízení v rámci clusteru. Sledovací služba kontroluje, jestli je možné z uzlu přistupovat k externímu prostředku. Prostředek je potřebný manifestem služby v rámci aplikace. Pokud je prostředek nedostupný, ostatní služby v rámci aplikace stále můžou správně fungovat. Proto se sestava odesílá na nasazenou entitu balíčku služby každých 30 sekund.

private static Uri ApplicationName = new Uri("fabric:/WordCount");
private static string ServiceManifestName = "WordCount.Service";
private static string NodeName = FabricRuntime.GetNodeContext().NodeName;
private static Timer ReportTimer = new Timer(new TimerCallback(SendReport), null, 30 * 1000, 30 * 1000);
private static FabricClient Client = new FabricClient(new FabricClientSettings() { HealthReportSendInterval = TimeSpan.FromSeconds(0) });

public static void SendReport(object obj)
{
    // Test whether the resource can be accessed from the node
    HealthState healthState = this.TestConnectivityToExternalResource();

    // Send report on deployed service package, as the connectivity is needed by the specific service manifest
    // and can be different on different nodes
    var deployedServicePackageHealthReport = new DeployedServicePackageHealthReport(
        ApplicationName,
        ServiceManifestName,
        NodeName,
        new HealthInformation("ExternalSourceWatcher", "Connectivity", healthState));

    // TODO: handle exception. Code omitted for snippet brevity.
    // Possible exceptions: FabricException with error codes
    // FabricHealthStaleReport (non-retryable, the report is already queued on the health client),
    // FabricHealthMaxReportsReached (retryable; user should retry with exponential delay until the report is accepted).
    Client.HealthManager.ReportHealth(deployedServicePackageHealthReport);
}

PowerShell

Odesílat zprávy o stavu pomocí funkce Send-ServiceFabricEntityTypeHealthReport.

Následující příklad ukazuje pravidelné generování sestav o hodnotách procesoru na uzlu. Sestavy by se měly posílat každých 30 sekund a jejich doba trvání je dvě minuty. Pokud vyprší jejich platnost, má zpravodaj problémy, takže se uzel vyhodnotí jako chybný. Pokud je procesor vyšší než prahová hodnota, sestava má stav upozornění. Pokud procesor zůstane nad prahovou hodnotou déle, než je nakonfigurovaný čas, ohlásí se to jako chyba. V opačném případě zpravodaj odešle stav OK.

PS C:\> Send-ServiceFabricNodeHealthReport -NodeName Node.1 -HealthState Warning -SourceId PowershellWatcher -HealthProperty CPU -Description "CPU is above 80% threshold" -TimeToLiveSec 120

PS C:\> Get-ServiceFabricNodeHealth -NodeName Node.1
NodeName              : Node.1
AggregatedHealthState : Warning
UnhealthyEvaluations  :
                        Unhealthy event: SourceId='PowershellWatcher', Property='CPU', HealthState='Warning', ConsiderWarningAsError=false.

HealthEvents          :
                        SourceId              : System.FM
                        Property              : State
                        HealthState           : Ok
                        SequenceNumber        : 5
                        SentAt                : 4/21/2015 8:01:17 AM
                        ReceivedAt            : 4/21/2015 8:02:12 AM
                        TTL                   : Infinite
                        Description           : Fabric node is up.
                        RemoveWhenExpired     : False
                        IsExpired             : False
                        Transitions           : ->Ok = 4/21/2015 8:02:12 AM

                        SourceId              : PowershellWatcher
                        Property              : CPU
                        HealthState           : Warning
                        SequenceNumber        : 130741236814913394
                        SentAt                : 4/21/2015 9:01:21 PM
                        ReceivedAt            : 4/21/2015 9:01:21 PM
                        TTL                   : 00:02:00
                        Description           : CPU is above 80% threshold
                        RemoveWhenExpired     : False
                        IsExpired             : False
                        Transitions           : ->Warning = 4/21/2015 9:01:21 PM

Následující příklad hlásí přechodné upozornění na repliku. Nejprve získá ID oddílu a pak ID repliky pro službu, která ji zajímá. Pak odešle sestavu z powershellWatcheru s vlastností ResourceDependency. Sestava je zajímavá jenom na dvě minuty a automaticky se odebere ze Storu.

PS C:\> $partitionId = (Get-ServiceFabricPartition -ServiceName fabric:/WordCount/WordCount.Service).PartitionId

PS C:\> $replicaId = (Get-ServiceFabricReplica -PartitionId $partitionId | where {$_.ReplicaRole -eq "Primary"}).ReplicaId

PS C:\> Send-ServiceFabricReplicaHealthReport -PartitionId $partitionId -ReplicaId $replicaId -HealthState Warning -SourceId PowershellWatcher -HealthProperty ResourceDependency -Description "The external resource that the primary is using has been rebooted at 4/21/2015 9:01:21 PM. Expect processing delays for a few minutes." -TimeToLiveSec 120 -RemoveWhenExpired

PS C:\> Get-ServiceFabricReplicaHealth  -PartitionId $partitionId -ReplicaOrInstanceId $replicaId


PartitionId           : 8f82daff-eb68-4fd9-b631-7a37629e08c0
ReplicaId             : 130740415594605869
AggregatedHealthState : Warning
UnhealthyEvaluations  :
                        Unhealthy event: SourceId='PowershellWatcher', Property='ResourceDependency', HealthState='Warning', ConsiderWarningAsError=false.

HealthEvents          :
                        SourceId              : System.RA
                        Property              : State
                        HealthState           : Ok
                        SequenceNumber        : 130740768777734943
                        SentAt                : 4/21/2015 8:01:17 AM
                        ReceivedAt            : 4/21/2015 8:02:12 AM
                        TTL                   : Infinite
                        Description           : Replica has been created.
                        RemoveWhenExpired     : False
                        IsExpired             : False
                        Transitions           : ->Ok = 4/21/2015 8:02:12 AM

                        SourceId              : PowershellWatcher
                        Property              : ResourceDependency
                        HealthState           : Warning
                        SequenceNumber        : 130741243777723555
                        SentAt                : 4/21/2015 9:12:57 PM
                        ReceivedAt            : 4/21/2015 9:12:57 PM
                        TTL                   : 00:02:00
                        Description           : The external resource that the primary is using has been rebooted at 4/21/2015 9:01:21 PM. Expect processing delays for a few minutes.
                        RemoveWhenExpired     : True
                        IsExpired             : False
                        Transitions           : ->Warning = 4/21/2015 9:12:32 PM

REST

Odesílat zprávy o stavu pomocí REST s požadavky POST, které odesílají do požadované entity a v těle mají popis sestavy stavu. Podívejte se například, jak odesílat sestavy stavu clusteru REST nebo sestavy stavu služby. Podporují se všechny entity.

Další kroky

Na základě dat o stavu můžou zapisovačé služeb a správci clusterů nebo aplikací vymyslet způsoby, jak tyto informace využívat. Můžou například nastavit výstrahy na základě stavu, aby zachytily závažné problémy předtím, než vyprovokují výpadky. Správci mohou také nastavit systémy oprav, které opravují problémy automaticky.

Úvod do monitorování stavu Service Fabric

Zobrazení sestav stavu Service Fabric

Jak nahlásit a zkontrolovat stav služby

Použití sestav stavu systému k řešení potíží

Místní monitorování a diagnostika služeb

Upgrade aplikace Service Fabric