Přidání vlastních stavových sestav Service Fabric
Azure Service Fabric zavádí model stavu navržený tak, aby označoval podmínky clusteru a aplikací, které nejsou v pořádku u konkrétních entit. Model stavu používá sestavy stavu (systémové komponenty a kukátky). Cílem je snadná a rychlá diagnostika a oprava. Autoři služeb se musí předem zamyslet nad stavem. Všechny podmínky, které můžou mít vliv na stav, by měly být hlášeny, zejména pokud můžou pomoct označit problémy blízko kořenového adresáře. Informace o stavu můžou ušetřit čas a úsilí při ladění a vyšetřování. Užitečnost je obzvláště jasná, když je služba ve velkém měřítku v cloudu (privátní nebo Azure).
Reportéři Service Fabric monitorují zjištěné podmínky zájmu. Tyto podmínky hlásí na základě místního zobrazení. Úložiště stavu agreguje data o stavu odesílaná všemi reportéry, aby bylo možné určit, jestli jsou entity globálně v pořádku. Model má být bohatý, flexibilní a snadno použitelný. Kvalita sestav 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 si představit, že je potřeba poskytnout sestavy, které zachycují podmínky zájmu nejlepším možným způsobem.
K návrhu a implementaci generování sestav stavu musí sledovací hlídačky a systémové komponenty:
- Definujte podmínku, o kterou se zajímá, jak se monitoruje, a vliv na funkčnost clusteru nebo aplikace. Na základětěchtoch
- Určete entitu, na kterou se sestava vztahuje.
- Určete, kde se vytváření sestav provádí, v rámci služby nebo z interního nebo externího sledovacího zařízení.
- Definujte zdroj použitý k identifikaci zpravodaje.
- Zvolte strategii vytváření sestav, a to buď pravidelně, nebo při přechodech. 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 sestava měla zůstat v úložišti stavu a jak by měla být vymazána. Při použití těchto informací se rozhodněte, kdy se sestava bude chovat jako aktivní, a odeberete chování při vypršení platnosti.
Jak už bylo zmíněno, vytváření sestav lze provést z:
- Monitorovaná replika služby Service Fabric.
- Interní watchdogs nasazené jako služba Service Fabric (například bezstavová služba Service Fabric, která monitoruje podmínky a sestavy problémů). Watchdogs je možné nasadit všechny uzly nebo je lze spřažením s monitorovanou službou.
- Interní watchdogs, které běží na uzlech Service Fabric, ale nejsou implementovány jako služby Service Fabric.
- Externí watchdogs, které testuje prostředek mimo cluster Service Fabric (například monitorovací služba, jako je Gomez).
Poznámka:
V rámci tohoto políčka se cluster naplní zprávami o stavu odesílanými systémovými komponentami. Další informace najdete v článku Použití sestav stavu systému pro řešení potíží. Sestavy uživatelů musí být odeslány u entit stavu, které už systém vytvořil.
Jakmile je návrh generování sestav stavu jasný, můžete snadno odesílat sestavy o stavu. Pokud cluster není zabezpečený nebo pokud má klient prostředků infrastruktury oprávnění správce, můžete pomocí FabricClient hlásit stav. Vytváření sestav je možné provádět prostřednictvím rozhraní API pomocí FabricClient.HealthManager.ReportHealth, prostřednictvím PowerShellu nebo rozhraní REST. Sestavy dávek pro konfiguraci 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 sestava je přijata klientem stavu nebo Partition objekty CodePackageActivationContext , neznamená, že se používá v úložišti. Odesílá se asynchronně a pravděpodobně dávkově s jinými sestavami. Zpracování na serveru může stále selhat: pořadové číslo může být zastaralé, entita, na které se sestava musí použít, byla odstraněna atd.
Klient stavu
Zprávy o stavu se posílají správci stavu prostřednictvím klienta stavu, který se nachází v klientovi infrastruktury. Správce stavu ukládá sestavy do úložiště stavu. Klienta stavu je možné nakonfigurovat s následujícími nastaveními:
- HealthReportSendInterval: Prodleva mezi časem přidání sestavy do klienta a časem odeslání správci stavu. Slouží k dávkové sestavě do jedné zprávy, nikoli k odesílání jedné zprávy pro každou sestavu. Dávkování zlepšuje výkon. Výchozí hodnota: 30 sekund.
- HealthReportRetrySendInterval: Interval, ve kterém klient stavu znovu odešle sestavy o stavu správci stavu. Výchozí hodnota: 30 sekund, minimum: 1 sekunda.
- HealthOperationTimeout: Období časového limitu zprávy sestavy odeslané správci stavu. Pokud vyprší časový limit zprávy, klient stavu ho opakuje, dokud správce stavu nestvrdí, že sestava byla zpracována. Výchozí hodnota: dvě minuty.
Poznámka:
Při dávkovém dávkování musí být klient prostředků infrastruktury udržován naživu, aby se zajistilo, že se odešlou aspoň healthReportSendInterval. Pokud dojde ke ztrátě zprávy nebo správce stavu je nemůže použít kvůli přechodným chybám, klient prostředků infrastruktury musí být aktivní déle, aby mohl opakovat akci.
Ukládání do vyrovnávací paměti klienta bere v úvahu jedinečnost sestav. Pokud například konkrétní chybný reportér hlásí 100 sestav za sekundu ve stejné vlastnosti stejné entity, nahradí se sestavy poslední verzí. Ve frontě klienta existuje maximálně jedna taková sestava. Pokud je nakonfigurované dávkování, počet sestav odeslaných správci stavu je jen jeden pro interval odeslání. Tato sestava je poslední přidanou sestavou, která odráží nejaktuálnější stav entity.
Zadejte parametry konfigurace při FabricClient vytvář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čuje, že se sestavy mají odesílat při jejich přidání. Při vypršení časových limitů a chyb, které je možné opakovat, dochází k opakovaným pokusům 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 zachovat výchozí nastavení klienta infrastruktury, které je nastavené HealthReportSendInterval na 30 sekund. Toto nastavení zajišťuje optimální výkon z důvodu dávkování. Pro kritické sestavy, které je potřeba odeslat co nejdříve, použijte HealthReportSendOptions s Příkazem Immediate true in FabricClient.HealthClient.ReportHealth API. Okamžité sestavy vynechají interval dávkování. Používat tento příznak s opatrností; Chceme využít dávkování klienta stavu, kdykoli je to možné. Okamžité odeslání je také užitečné, když se klient prostředků infrastruktury zavře (například proces určil neplatný stav a musí se vypnout, aby se zabránilo vedlejším účinkům). Zajišťuje nejlepší úsilí při odesílání kumulovaných sestav. Když se přidá jedna sestava s příznakem Okamžité, klient stavu v dávkách všechny kumulované sestavy od posledního odeslání.
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 u rozhraní API je možné odesílat sestavy pomocí -Immediate přepínače, který se má odeslat okamžitě bez HealthReportSendInterval ohledu na hodnotu.
V případě REST se sestavy odesílají do brány Service Fabric, která má interního klienta infrastruktury. Ve výchozím nastavení je tento klient nakonfigurovaný tak, aby odesílal sestavy dávkově každých 30 sekund. Interval dávky můžete změnit nastavením konfigurace HttpGatewayHealthReportSendInterval clusteru .HttpGateway Jak už bylo zmíněno, lepší možností je odeslat sestavy s Immediate true.
Poznámka:
Pokud chcete zajistit, aby neautorizované služby nemohly hlásit stav entit v clusteru, nakonfigurujte server tak, aby přijímal požadavky pouze ze zabezpečených klientů. Použití FabricClient pro vytváření sestav musí mít povolené zabezpečení, aby bylo možné komunikovat s clusterem (například s ověřováním kerberos nebo certifikátem). Přečtěte si další informace o zabezpečení clusteru.
Sestava 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 ohlásit stav entit z aktuálního kontextu prostřednictvím Partition nebo CodePackageActivationContext.
- Pro bezstavové služby použijte IStatelessServicePartition.ReportInstanceHealth k hlášení aktuální instance služby.
- Pro stavové služby použijte IStatefulServicePartition.ReportReplicaHealth k hlášení aktuální repliky.
- Pomocí IServicePartition.ReportPartitionHealth můžete hlásit aktuální entitu oddílu.
- K hlášení aktuální aplikace použijte CodePackageActivationContext.ReportApplicationHealth .
- Pomocí CodePackageActivationContext.ReportDeployedApplicationHealth můžete hlásit aktuální aplikaci nasazenou na aktuálním uzlu.
- Použijte CodePackageActivationContext.ReportDeployedServicePackageHealth k hlášení balíčku služby pro aplikaci nasazenou na aktuálním uzlu.
Poznámka:
Klient stavu nakonfigurovaný s výchozím nastavením interně Partition a CodePackageActivationContext blokováním. Jak je vysvětleno pro klienta stavu, sestavy se dávkovají a odesílají v časovači. Objekty by měly být udržovány naživu, aby měly šanci odeslat sestavu.
Při odesílání sestav prostřednictvím Partition rozhraní API pro CodePackageActivationContext stav a jejich odesílání můžete určitHealthReportSendOptions. Pokud máte kritické sestavy, které musí být odeslány co nejdříve, použijte HealthReportSendOptions s okamžitou true. Okamžité sestavy vynechají interval dávkování interního klienta stavu. Jak již bylo zmíněno dříve, použijte tento příznak s opatrností; Chceme využít dávkování klienta stavu, kdykoli je to možné.
Návrh generování sestav o stavu
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ě lepším, než dojde k problému, může potenciálně ušetřit miliardy dolarů. Mezi výhody patří menší 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ího zařízení zjistit nejlepší způsob, jak je monitorovat pro rovnováhu 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 monitorovat sdílenou složku, aby zajistilo, že je k dispozici dostatek místa. Může naslouchat oznámením o změnách souborů nebo adresářů. Pokud dojde k dosažení počáteční prahové hodnoty, může nahlásit upozornění a ohlásit chybu, pokud je sdílená složka plná. V upozornění může systém oprav spustit čištění starších souborů ve sdílené složce. V případě chyby může opravný systém přesunout repliku služby do jiného uzlu. Všimněte si, jak jsou stavy podmínek popsány z hlediska stavu: stav podmínky, která může být považována za v pořádku (OK) nebo není v pořádku (upozornění nebo chyba).
Jakmile jsou podrobnosti monitorování nastavené, musí spisovatel sledovacího zařízení zjistit, jak implementovat watchdog. Pokud lze podmínky určit v rámci služby, může být sledovací služba 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 dbát na to, aby se zabránilo chybám sledovacího systému, aby ovlivnily funkčnost služby.
Generování sestav z monitorované služby není vždy možností. Sledovací zařízení ve službě nemusí být schopno rozpoznat podmínky. Nemusí mít logiku ani data k určení. Režie při monitorování 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 kukátky jako samostatné procesy. Hodinké monitorují podmínky a sestavu, aniž by to mělo vliv na hlavní služby. Tyto watchdogs by se například mohly implementovat jako bezstavové služby ve stejné aplikaci, nasazené na všech uzlech nebo ve stejných uzlech jako služba.
V některých případech není v clusteru možné, že sledovací zařízení spuštěné v clusteru. Pokud je monitorovaná podmínka dostupnost nebo funkčnost služby, jak ji uživatelé vidí, je nejlepší mít kukátky 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í 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 v přiměřeném časovém intervalu 4?)
Po dokončení podrobností sledovacího zařízení byste se měli rozhodnout o ID zdroje, které ho jednoznačně identifikuje. Pokud v clusteru žije více kukátků stejného typu, musí hlásit různé entity, nebo pokud se hlásí na stejné entitě, použijte jiné ID zdroje nebo vlastnost. Díky tomu můžou jejich sestavy existovat společně. Vlastnost sestavy stavu by měla zachytit monitorovanou podmínku. (V příkladu výše může být vlastnostShareSize.) 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:
Neuchovávejte informace o stavu pomocí úložiště stavu. Jako stav by měly být hlášeny pouze informace související se stavem, protože tyto informace ovlivňují vyhodnocení stavu entity. Úložiště stavu nebylo navrženo jako úložiště pro obecné účely. Používá logiku vyhodnocení stavu k agregaci všech dat do stavu. Odesílání informací nesouvisejících se stavem (například hlášení stavu 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, na kterou se má sestavovat. Ve většině případů podmínka entitu jasně identifikuje. Vyberte entitu s nejlepší možnou členitostí. Pokud má podmínka vliv na všechny repliky v oddílu, nahlásit ho, ne ve službě. Existují ale případy, kdy je potřeba více uvažovat. Pokud má podmínka vliv na entitu, jako je například replika, ale touha je, aby byla podmínka označena příznakem delší než doba životnosti repliky, měla by být hlášena v oddílu. Jinak při odstranění repliky úložiště stavu vyčistí všechny sestavy. Sledovací autoři musí přemýšlet o životnosti entity a sestavy. Musí být jasné, kdy by se sestava měla vyčistit z úložiště (například když už neplatí chyba hlášená u entity).
Podívejme se na příklad, který spojuje body, které jsem popsal. Zvažte aplikaci Service Fabric složenou 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 pro zpracování, která obsahuje příkazy, které se mají spustit pomocí sekundárních souborů. Sekundáři spouštějí příchozí požadavky a odesílají signály potvrzení zpět. Jedna podmínka, kterou je možné monitorovat, je délka hlavní fronty zpracování. Pokud délka hlavní fronty dosáhne prahové hodnoty, zobrazí se upozornění. Upozornění značí, že sekundární soubory nezvládnou zatížení. Pokud fronta dosáhne maximální délky a příkazy se zahodí, zobrazí se chyba, protože služba nemůže obnovit. Sestavy mohou být ve vlastnosti QueueStatus. Sledovací zařízení se nachází ve službě a pravidelně se odesílá na hlavní primární repliku. Doba života je dvě minuty a pravidelně se odesílají každých 30 sekund. Pokud dojde k výpadku primárního serveru, sestava se automaticky vyčistí z úložiště. Pokud je replika služby aktivní, ale je zablokovaná nebo má jiné problémy, platnost sestavy vyprší v úložišti stavu. V tomto případě se entita vyhodnotí jako chybná.
Další podmínkou, kterou lze monitorovat, je doba provádění úkolů. Předloha distribuuje úkoly do sekundárních podle typu úkolu. V závislosti na návrhu by se hlavní server mohl dotazovat na sekundární stav úkolu. Může také počkat, až sekundáři po dokončení odešlou signály potvrzení zpět. V druhém případě je potřeba dbát na to, aby bylo možné zjistit situace, kdy se ztratí sekundární zprávy nebo zprávy. 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 svůj stav. Pokud není přijat žádný stav, hlavní server ho považuje za selhání a přeplánuje úkol. Toto chování předpokládá, že úlohy jsou idempotentní.
Monitorovaná podmínka se dá přeložit jako upozornění, pokud se úkol v určitém čase neprovede (například 10 minut). Pokud úkol není dokončen v čase (t2, například 20 minut), monitorovaná podmínka se dá přeložit jako Chyba. Toto vytváření sestav lze provést několika způsoby:
- Hlavní primární replika se pravidelně hlásí. Můžete mít jednu vlastnost pro všechny čekající úkoly ve frontě. Pokud alespoň jeden úkol trvá déle, stav sestavy vlastnosti PendingTasks je podle potřeby upozornění nebo chyba. Pokud neexistují žádné čekající úkoly nebo spuštění všech úkolů, stav sestavy je v pořádku. Úkoly jsou trvalé. Pokud dojde k výpadku primárního serveru, může nově povýšený primární server i nadále správně hlásit.
- Jiný proces sledovacího zařízení (v cloudu nebo externím) kontroluje úlohy (zvenčí na základě požadovaného výsledku úkolu) a zjišťuje, jestli jsou dokončené. Pokud nerespektují prahové hodnoty, odešle se v hlavní službě sestava. Sestava se také odešle pro každý úkol, který obsahuje identifikátor úkolu, například PendingTask+taskId. Sestavy by se měly posílat jenom ve stavech, které nejsou v pořádku. Nastavte dobu na dobu, po kterou se má žít, a označte sestavy, které se mají odebrat, když vyprší jejich platnost, aby se zajistilo vyčištění.
- Sekundární, která spouští sestavy úloh, když jeho spuštění trvá déle, než se čekalo. Hlásí instanci služby ve vlastnosti PendingTasks. Sestava uvádí instanci služby, která má problémy, ale nezachytí 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 se nedokončí z pohledu hlavního serveru.
Generování sestav se ale provádí v případech popsaných výše, sestavy se při vyhodnocování stavu aplikace zaznamenávají do stavu aplikace.
Sestava pravidelně vs. při přechodu
Pomocí modelu generování sestav stavu můžou watchdogs pravidelně posílat sestavy nebo přechody. Doporučený způsob generování sestav watchdogu je pravidelně, 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, ovlivňují vyhodnocení stavu a scénáře na základě stavu, včetně upgradů. Nesprávné sestavy, které jsou v pořádku , skryjí problémy v clusteru, což není žádoucí.
V případě pravidelného hlášení lze sledovací zařízení implementovat pomocí časovače. 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í nutné zjistit, která sestava byla odeslána dříve, nebo 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 klient stavu je stále aktivní, opakuje interně, dokud se sestava neověkne úložištěm stavu nebo sledovacím zařízením vygeneruje novější sestavu se stejnou entitou, vlastností a zdrojem.
Vytváření sestav o přechodech vyžaduje pečlivé zpracování stavu. Sledovací zařízení monitoruje určité podmínky a hlásí pouze v případech, kdy se podmínky mění. Nevýhodou tohoto přístupu je, že je potřeba méně sestav. Nevýhodou je, že logika watchdogu je složitá. Sledovací zařízení 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 věnovat pozornost přidaným sestavám, ale ještě se neodesílají do úložiště stavu. Pořadové číslo musí být stále větší. 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 synchronizace potřebná mezi stavem reportéru a stavem úložiště stavu.
Vytváření sestav o přechodech dává smysl pro samotné generování sestav služeb prostřednictvím Partition nebo CodePackageActivationContext. Když dojde k odebrání místního objektu (repliky nebo nasazeného balíčku služby nebo nasazené aplikace), odeberou se také všechny její sestavy. Toto automatické čištění uvolní potřebu synchronizace mezi reportérem a úložištěm stavu. 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 nedocházelo k zastaralým sestavám v úložišti stavu. Logika se musí přidat, aby se zachoval správný stav a v případě potřeby se sestava vymaže z úložiště.
Implementace generování sestav stavu
Jakmile jsou podrobnosti o entitě a sestavě jasné, můžete odesílání sestav o stavu provádět prostřednictvím rozhraní API, PowerShellu nebo ROZHRANÍ REST.
rozhraní API
Pokud chcete vytvářet sestavy prostřednictvím rozhraní API, musíte vytvořit sestavu stavu specifickou pro typ entity, se kterou chce sestavovat. Poskytněte sestavě klientovi stavu. Případně vytvořte informace o stavu a předejte je správným metodám Partition vytváření sestav nebo CodePackageActivationContext sestavám o aktuálních entitách.
Následující příklad ukazuje pravidelné hlášení z sledovacího zařízení v clusteru. Sledovací modul zkontroluje, jestli se k externímu prostředku dá přistupovat z uzlu. Prostředek potřebuje manifest služby v rámci aplikace. Pokud prostředek není dostupný, ostatní služby v aplikaci můžou stále fungovat správně. Proto se sestava odešle do entity nasazeného 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
Odešlete sestavy stavu pomocí entity Send-ServiceFabricEntityTypeHealthReport.
Následující příklad ukazuje pravidelné generování sestav o hodnotách procesoru na uzlu. Sestavy by měly být odeslány každých 30 sekund a mají čas naživu dvě minuty. Pokud vyprší jejich platnost, má reportér problémy, takže uzel se vyhodnotí jako chybný. Pokud je procesor nad prahovou hodnotou, sestava má stav upozornění. Pokud procesor překročí prahovou hodnotu delší než nakonfigurovaný čas, zobrazí se 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, o které se zajímá. Pak odešle sestavu z PowershellWatcheru na vlastnost ResourceDependency. Sestava je zajímavá jenom na dvě minuty a automaticky se odebere z obchodu.
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
Odešlete sestavy o stavu pomocí rest s požadavky POST, které přejdou na požadovanou entitu a mají v textu 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či služeb a správci clusteru nebo aplikací uvažovat o způsobech využívání informací. Mohou například nastavit výstrahy na základě stavu, aby zachytily závažné problémy před vyvoláním výpadků. Správci můžou také nastavit systémy oprav, které opravují problémy automaticky.
Úvod do monitorování stavu Service Fabric
Zobrazení sestav stavu Service Fabric
Jak hlásit a zkontrolovat stav služby
Řešení potíží s využitím sestav stavu systému