Úvod do monitorování stavu Service Fabric

Článek
06/01/2023

Azure Service Fabric zavádí model stavu, který poskytuje bohaté, flexibilní a rozšiřitelné vyhodnocení stavu a vytváření sestav. Model umožňuje téměř v reálném čase monitorovat stav clusteru a služeb v něm spuštěných. Můžete snadno získat informace o stavu a opravit potenciální problémy předtím, než se kaskádují a způsobí masivní výpadky. V typickém modelu služby odesílají sestavy na základě svých místních zobrazení a informace se agregují, aby poskytovaly celkové zobrazení na úrovni clusteru.

Komponenty Service Fabric používají tento bohatý model stavu k hlášení svého aktuálního stavu. Stejný mechanismus můžete použít k hlášení stavu z aplikací. Pokud investujete do vysoce kvalitního generování sestav o stavu, které zachycuje vaše vlastní podmínky, můžete problémy se spuštěnou aplikací detekovat a opravit mnohem snadněji.

Na této stránce najdete školicí video, které popisuje model stavu Service Fabric a jeho použití:

Poznámka

Spustili jsme subsystém stavu, abychom vyřešili potřebu monitorovaných upgradů. Service Fabric poskytuje monitorované upgrady aplikací a clusterů, které zajišťují plnou dostupnost, žádné výpadky a minimální až žádný zásah uživatele. Aby bylo možné těchto cílů dosáhnout, upgrade kontroluje stav na základě nakonfigurovaných zásad upgradu. Upgrade může pokračovat pouze v případě, že stav respektuje požadované prahové hodnoty. V opačném případě se upgrade buď automaticky vrátí zpět, nebo se pozastaví, aby správci měli možnost problémy opravit. Další informace o upgradech aplikací najdete v tomto článku.

Úložiště stavu

Úložiště stavů uchovává informace o stavu entit v clusteru pro snadné načtení a vyhodnocení. Implementuje se jako trvalá stavová služba Service Fabric, aby se zajistila vysoká dostupnost a škálovatelnost. Úložiště stavu je součástí aplikace fabric:/System a je k dispozici, když je cluster spuštěný a spuštěný.

Entity stavu a hierarchie

Entity stavu jsou uspořádány v logické hierarchii, která zachycuje interakce a závislosti mezi různými entitami. Úložiště stavů automaticky vytváří entity stavu a hierarchii na základě sestav přijatých z komponent Service Fabric.

Entity stavu zrcadlí entity Service Fabric. (Například entita aplikace health application odpovídá instanci aplikace nasazené v clusteru, zatímco entita stavového uzlu odpovídá uzlu clusteru Service Fabric.) Hierarchie stavu zachycuje interakce systémových entit a je základem pro pokročilé vyhodnocení stavu. Informace o klíčových konceptech Service Fabric najdete v technickém přehledu Service Fabric. Další informace o aplikaci najdete v tématu Aplikační model Service Fabric.

Entity stavu a hierarchie umožňují efektivní hlášení, ladění a monitorování clusteru a aplikací. Model stavu poskytuje přesnou a podrobnou reprezentaci stavu mnoha pohybujících se částí v clusteru.

Entity stavu. Entity stavu uspořádané v hierarchii založené na vztazích nadřazenosti a podřízenosti.

Entity stavu jsou:

Cluster. Představuje stav clusteru Service Fabric. Sestavy stavu clusteru popisují podmínky, které ovlivňují celý cluster. Tyto podmínky ovlivňují více entit v clusteru nebo samotném clusteru. Na základě podmínky nemůže reportér problém zúžit na jednu nebo více dětí, které nejsou v pořádku. Příkladem může být rozdělení clusteru v důsledku dělení sítě nebo problémů s komunikací.
Uzel. Představuje stav uzlu Service Fabric. Sestavy stavu uzlů popisují podmínky, které ovlivňují funkce uzlu. Obvykle ovlivňují všechny nasazené entity, které na nich běží. Mezi příklady patří nedostatek místa na disku uzlu (nebo jiné vlastnosti celého počítače, jako je paměť nebo připojení) a stav mimo provoz uzlu. Entita uzlu je identifikována názvem uzlu (řetězec).
Aplikace. Představuje stav instance aplikace spuštěné v clusteru. Sestavy stavu aplikace popisují podmínky, které ovlivňují celkový stav aplikace. Nelze je zúžit na jednotlivé podřízené položky (služby nebo nasazené aplikace). Příkladem může být kompletní interakce mezi různými službami v aplikaci. Entita aplikace je identifikována názvem aplikace (URI).
Služba. Představuje stav služby spuštěné v clusteru. Stav služby sestavy popisují podmínky, které ovlivňují celkový stav služby. Reportér nemůže problém zúžit na oddíl nebo repliku, které nejsou v pořádku. Mezi příklady patří konfigurace služby (jako je port nebo externí sdílená složka), která způsobuje problémy u všech oddílů. Entita služby je identifikována názvem služby (URI).
Oddíl. Představuje stav oddílu služby. Sestavy stavu oddílů popisují podmínky, které ovlivňují celou sadu replik. Mezi příklady patří, když je počet replik nižší než cílový počet a kdy je oddíl ve ztrátě kvora. Entita oddílu se identifikuje pomocí ID oddílu (GUID).
Replika. Představuje stav repliky stavové služby nebo instance bezstavové služby. Replika je nejmenší jednotka, o které můžou hlídací zařízení a systémové komponenty hlásit aplikaci. U stavových služeb patří například primární replika, která nemůže replikovat operace do sekundárních databází a pomalou replikaci. Bezstavová instance může také hlásit, když jí dochází prostředky nebo dochází k problémům s připojením. Entita repliky se identifikuje podle ID oddílu (GUID) a ID repliky nebo instance (dlouhé).
DeployedApplication. Představuje stav aplikace spuštěné na uzlu. Nasazené sestavy stavu aplikace popisují podmínky specifické pro aplikaci v uzlu, které nelze zúžit na balíčky služeb nasazené na stejném uzlu. Mezi příklady patří chyby, kdy na daném uzlu nejde stáhnout balíček aplikace, a problémy s nastavením objektů zabezpečení aplikace na uzlu. Nasazená aplikace se identifikuje podle názvu aplikace (URI) a názvu uzlu (řetězec).
DeployedServicePackage. Představuje stav balíčku služby spuštěného na uzlu v clusteru. Popisuje podmínky specifické pro balíček služby, které nemají vliv na ostatní balíčky služeb ve stejném uzlu pro stejnou aplikaci. Mezi příklady patří balíček kódu v balíčku služby, který nelze spustit, a konfigurační balíček, který nelze přečíst. Nasazený balíček služby se identifikuje podle názvu aplikace (URI), názvu uzlu (řetězec), názvu manifestu služby (řetězec) a ID (řetězec) aktivace balíčku služby.

Členitost modelu stavu usnadňuje zjišťování a opravy problémů. Pokud například služba nereaguje, je možné nahlásit, že instance aplikace není v pořádku. Generování sestav na této úrovni ale není ideální, protože problém nemusí mít vliv na všechny služby v této aplikaci. Sestava by se měla použít pro službu, která není v pořádku, nebo na konkrétní podřízený oddíl, pokud na tento oddíl odkazují další informace. Data se automaticky zobrazí v hierarchii a oddíl, který není v pořádku, se zobrazí na úrovních služby a aplikace. Tato agregace pomáhá rychleji určit a vyřešit původní příčinu problému.

Hierarchie stavu se skládá ze vztahů nadřazenosti a podřízenosti. Cluster se skládá z uzlů a aplikací. Aplikace mají služby a nasazené aplikace. Nasazené aplikace mají nasazené balíčky služeb. Služby mají oddíly a každý oddíl má jednu nebo více replik. Mezi uzly a nasazenými entitami existuje zvláštní vztah. Uzel, který není v pořádku, jak hlásí jeho komponenta systému autorit, služba Správce převzetí služeb při selhání, ovlivňuje nasazené aplikace, balíčky služeb a repliky, které jsou v něm nasazené.

Hierarchie stavu představuje nejnovější stav systému na základě nejnovějších zpráv o stavu, což jsou informace téměř v reálném čase. Interní a externí sledovací týmy můžou hlásit stejné entity na základě logiky specifické pro aplikaci nebo vlastních monitorovaných podmínek. Sestavy uživatelů existují společně se systémovými sestavami.

Plánujte investovat do toho, jak během návrhu velké cloudové služby vykazovat sestavy a reagovat na jeho stav. Tato počáteční investice usnadňuje ladění, monitorování a provoz služby.

Stavy

Service Fabric používá k popisu, jestli je entita v pořádku, nebo ne: OK, upozornění a chyba. Každá sestava odeslaná do úložiště stavů musí obsahovat jeden z těchto stavů. Výsledkem vyhodnocení stavu je jeden z těchto stavů.

Možné stavy jsou:

Dobře. Entita je v pořádku. Nejsou hlášeny žádné známé problémy s ním nebo jeho podřízenými položkami (pokud jsou k dispozici).
Upozornění: Entita má určité problémy, ale přesto může správně fungovat. Dochází například ke zpožděním, ale zatím nezpůsobují žádné funkční problémy. V některých případech se může stav upozornění sám opravit bez vnějšího zásahu. V těchto případech zprávy o stavu zvyšuje povědomí a poskytuje přehled o tom, co se děje. V jiných případech může stav upozornění degradovat na závažný problém bez zásahu uživatele.
Chyba. Entita není v pořádku. Je potřeba provést akci, která opraví stav entity, protože entita nemůže správně fungovat.
Neznámé: Entita v úložišti stavů neexistuje. Tento výsledek lze získat z distribuovaných dotazů, které slučují výsledky z více součástí. Například dotaz get node list přejde na FailoverManager, ClusterManager a HealthManager; get application list query goes to ClusterManager and HealthManager. Tyto dotazy slučují výsledky z více systémových komponent. Pokud jiná komponenta systému vrátí entitu, která se nenachází v úložišti stavů, sloučený výsledek bude mít neznámý stav. Entita není uložena, protože sestavy stavu ještě nebyly zpracovány nebo entita byla po odstranění vyčištěna.

Zásady stavu

Úložiště stavů používá zásady stavu, aby na základě svých sestav a podřízených položek určilo, jestli je entita v pořádku.

Poznámka

Zásady stavu je možné zadat v manifestu clusteru (pro vyhodnocení stavu clusteru a uzlu) nebo v manifestu aplikace (pro vyhodnocení aplikace a jakékoli jeho podřízené položky). Žádosti o vyhodnocení stavu můžou také projít vlastními zásadami vyhodnocení stavu, které se používají jenom pro toto vyhodnocení.

Service Fabric ve výchozím nastavení používá striktní pravidla (vše musí být v pořádku) pro hierarchický vztah nadřazený-podřízený. Pokud má i jedna z podřízených položek jednu událost, která není v pořádku, nadřazený objekt se považuje za špatný.

Zásady stavu clusteru

Zásady stavu clusteru slouží k vyhodnocení stavu clusteru a uzlu. Zásady je možné definovat v manifestu clusteru. Pokud není k dispozici, použijí se výchozí zásady (nula tolerovaných selhání).

Zásady stavu clusteru obsahují:

Zvažte chybuWarningAsError. Určuje, jestli se mají zprávy o stavu upozornění považovat za chyby při vyhodnocování stavu. Výchozí hodnota: false.
MaxPercentUnhealthyApplications. Určuje maximální tolerované procento aplikací, které můžou být v pořádku, než se cluster považuje za chybný.
MaxPercentUnhealthyNodes. Určuje maximální tolerované procento uzlů, které můžou být v pořádku, než se cluster považuje za chybný. Ve velkých clusterech jsou některé uzly kvůli opravě vždy mimo provoz, takže toto procento by mělo být nakonfigurované tak, aby to toleroval.
ApplicationTypeHealthPolicyMap. Mapu zásad stavu typu aplikace je možné použít při vyhodnocování stavu clusteru k popisu speciálních typů aplikací. Ve výchozím nastavení se všechny aplikace umístí do fondu a vyhodnotí se pomocí MaxPercentUnhealthyApplications. Pokud by se s některými typy aplikací mělo zacházet odlišně, je možné je z globálního fondu vyčíst. Místo toho se v mapě vyhodnocují podle procent přidružených k názvu jejich typu aplikace. Například v clusteru existují tisíce aplikací různých typů a několik řídí instance aplikací speciálního typu aplikace. Řídicí aplikace by nikdy neměly být chybné. Můžete zadat globální MaxPercentUnhealthyApplications na 20 %, aby tolerovala některá selhání, ale pro typ aplikace ControlApplicationType nastavte MaxPercentUnhealthyApplications na 0. Tímto způsobem by se cluster v případě, že některé z mnoha aplikací nejsou v pořádku, ale pod globálním procentem, které nejsou v pořádku, vyhodnotil jako Upozornění. Stav upozornění nemá vliv na upgrade clusteru ani jiné monitorování aktivované stavem chyby. Ale i jedna řídicí aplikace, která je chybná, způsobí, že cluster není v pořádku, což v závislosti na konfiguraci upgradu aktivuje vrácení zpět nebo pozastavení upgradu clusteru. U typů aplikací definovaných v mapě jsou všechny instance aplikací odebrány z globálního fondu aplikací. Vyhodnocují se na základě celkového počtu aplikací typu aplikace pomocí konkrétní aplikace MaxPercentUnhealthyApplications z mapy. Všechny ostatní aplikace zůstávají v globálním fondu a vyhodnocují se pomocí MaxPercentUnhealthyApplications.

Následující příklad je výňatek z manifestu clusteru. Chcete-li definovat položky v mapování typu aplikace, před název parametru zadejte "ApplicationTypeMaxPercentUnhealthyApplications-", následovaný názvem typu aplikace.
```
<FabricSettings>
  <Section Name="HealthManager/ClusterHealthPolicy">
    <Parameter Name="ConsiderWarningAsError" Value="False" />
    <Parameter Name="MaxPercentUnhealthyApplications" Value="20" />
    <Parameter Name="MaxPercentUnhealthyNodes" Value="20" />
    <Parameter Name="ApplicationTypeMaxPercentUnhealthyApplications-ControlApplicationType" Value="0" />
  </Section>
</FabricSettings>
```
NodeTypeHealthPolicyMap. Mapu zásad stavu typu uzlu je možné při vyhodnocování stavu clusteru použít k popisu speciálních typů uzlů. Typy uzlů se vyhodnocují na základě procent přidružených k názvu jejich typu uzlu v mapě. Nastavení této hodnoty nemá žádný vliv na globální fond uzlů používaný pro MaxPercentUnhealthyNodes. Cluster má například stovky uzlů různých typů a několik typů uzlů, které hostují důležitou práci. Žádné uzly v daném typu by neměly být mimo provoz. Pokud chcete tolerovat některé chyby pro všechny uzly, můžete zadat globální MaxPercentUnhealthyNodes hodnotu na 20 %, ale pro typ SpecialNodeTypeuzlu nastavte MaxPercentUnhealthyNodes hodnotu 0. Tímto způsobem, pokud některé z mnoha uzlů nejsou v pořádku, ale nižší než globální procento není v pořádku, cluster by se vyhodnotil jako ve stavu Upozornění. Stav upozornění nemá vliv na upgrade clusteru ani jiné monitorování aktivované stavem chyba. Ale i jeden uzel typu SpecialNodeType ve stavu Chyba způsobí, že cluster není v pořádku a v závislosti na konfiguraci upgradu aktivuje vrácení zpět nebo pozastavení upgradu clusteru. Naopak nastavení globální MaxPercentUnhealthyNodes hodnoty na hodnotu 0 a nastavení maximálního SpecialNodeType procenta uzlů, které nejsou v pořádku, na 100 uzlů s jedním uzlem typu SpecialNodeType v chybovém stavu, by cluster stále dostal do chybového stavu, protože globální omezení je v tomto případě přísnější.

Následující příklad je výňatek z manifestu clusteru. Chcete-li definovat položky v mapování typu uzlu, před název parametru zadejte "NodeTypeMaxPercentUnhealthyNodes-", následovaný názvem typu uzlu.
```
<FabricSettings>
  <Section Name="HealthManager/ClusterHealthPolicy">
    <Parameter Name="ConsiderWarningAsError" Value="False" />
    <Parameter Name="MaxPercentUnhealthyApplications" Value="20" />
    <Parameter Name="MaxPercentUnhealthyNodes" Value="20" />
    <Parameter Name="NodeTypeMaxPercentUnhealthyNodes-SpecialNodeType" Value="0" />
  </Section>
</FabricSettings>
```

Zásady stavu aplikace

Zásady stavu aplikace popisují, jak se u aplikací a jejich podřízených položek provádí vyhodnocení událostí a agregace podřízených stavů. Dá se definovat v manifestu aplikace ApplicationManifest.xmlv balíčku aplikace. Pokud nejsou zadané žádné zásady, Service Fabric předpokládá, že entita není v pořádku, pokud má sestavu stavu nebo podřízenou entitu se stavem upozornění nebo chyby. Konfigurovatelné zásady jsou:

Zvažte chybuWarningAsError. Určuje, jestli se mají zprávy o stavu upozornění považovat za chyby při vyhodnocování stavu. Výchozí hodnota: false.
MaxPercentUnhealthyDeployedApplications. Určuje maximální tolerované procento nasazených aplikací, které můžou být v pořádku, než se aplikace považuje za chybnou. Toto procento se vypočítá rozdělením počtu nasazených aplikací, které nejsou v pořádku, a počtu uzlů, na které jsou aplikace aktuálně nasazené v clusteru. Výpočet se zaokrouhlí nahoru, aby toleroval jedno selhání u malého počtu uzlů. Výchozí procento: nula.
DefaultServiceTypeHealthPolicy. Určuje výchozí zásadu stavu typu služby, která nahradí výchozí zásady stavu pro všechny typy služeb v aplikaci.
ServiceTypeHealthPolicyMap. Poskytuje mapu zásad služby Service Health podle typu služby. Tyto zásady nahrazují výchozí zásady stavu typu služby pro každý zadaný typ služby. Pokud má například aplikace typ služby bezstavové brány a typ služby stavového modulu, můžete zásady stavu pro jejich vyhodnocení nakonfigurovat odlišně. Když zadáte zásadu pro jednotlivé typy služby, můžete získat podrobnější kontrolu nad stavem služby.

Zásady stavu typu služby

Zásady stavu typu služby určují, jak vyhodnotit a agregovat služby a podřízené položky služeb. Zásada obsahuje:

MaxPercentUnhealthyPartitionsPerService. Určuje maximální tolerované procento oddílů, které nejsou v pořádku, než bude služba považována za službu, která není v pořádku. Výchozí procento: nula.
MaxPercentUnhealthyReplicasPerPartition. Určuje maximální tolerované procento replik, které nejsou v pořádku, než se oddíl bude považovat za poškozený. Výchozí procento: nula.
MaxPercentUnhealthyServices. Určuje maximální tolerované procento služeb, které nejsou v pořádku, než se aplikace bude považovat za špatné. Výchozí procento: nula.

Následující příklad je výňatek z manifestu aplikace:

    <Policies>
        <HealthPolicy ConsiderWarningAsError="true" MaxPercentUnhealthyDeployedApplications="20">
            <DefaultServiceTypeHealthPolicy
                   MaxPercentUnhealthyServices="0"
                   MaxPercentUnhealthyPartitionsPerService="10"
                   MaxPercentUnhealthyReplicasPerPartition="0"/>
            <ServiceTypeHealthPolicy ServiceTypeName="FrontEndServiceType"
                   MaxPercentUnhealthyServices="0"
                   MaxPercentUnhealthyPartitionsPerService="20"
                   MaxPercentUnhealthyReplicasPerPartition="0"/>
            <ServiceTypeHealthPolicy ServiceTypeName="BackEndServiceType"
                   MaxPercentUnhealthyServices="20"
                   MaxPercentUnhealthyPartitionsPerService="0"
                   MaxPercentUnhealthyReplicasPerPartition="0">
            </ServiceTypeHealthPolicy>
        </HealthPolicy>
    </Policies>

Vyhodnocení stavu

Uživatelé a automatizované služby můžou kdykoli vyhodnotit stav libovolné entity. Aby bylo možné vyhodnotit stav entity, úložiště stavů agreguje všechny sestavy o stavu entity a vyhodnocuje všechny její podřízené položky (pokud jsou k dispozici). Algoritmus agregace stavu používá zásady stavu, které určují, jak vyhodnotit sestavy stavu a jak agregovat stavy podřízeného stavu (pokud je to možné).

Agregace sestav stavu

Jedna entita může mít několik sestav stavu odesílaných různými zpravodaji (systémových komponent nebo sledovacích zařízení) s různými vlastnostmi. Agregace používá přidružené zásady stavu, zejména zásadu ConsiderWarningAsError, která je členem zásad stavu aplikace nebo clusteru. ConsiderWarningAsError určuje, jak se mají vyhodnotit upozornění.

Agregovaný stav aktivují sestavy nejhoršího stavu entity. Pokud existuje alespoň jedna zpráva o stavu chyby, agregovaný stav je chyba.

Agregace sestavy stavu se zprávou o chybách

Entita stavu, která obsahuje jednu nebo více zpráv o stavu chyb, se vyhodnotí jako Chyba. Totéž platí pro sestavu o stavu s prošlou platností bez ohledu na její stav.

Pokud nejsou k dispozici žádné zprávy o chybách a jedno nebo více upozornění, agregovaný stav je upozornění nebo chyba v závislosti na příznaku zásady ConsiderWarningAsError.

Agregace sestavy stavu se sestavou upozornění a chybou ConsiderWarningAsError

Agregace sestavy stavu se sestavou upozornění a chybou ConsiderWarningAsError nastavenou na hodnotu false (výchozí).

Agregace stavu podřízenosti

Agregovaný stav entity odráží stav podřízeného stavu (pokud je to možné). Algoritmus pro agregaci stavů podřízenosti používá zásady stavu platné na základě typu entity.

Agregace stavu podřízených entit

Podřízená agregace na základě zásad stavu.

Jakmile úložiště stavů vyhodnotí všechny děti, agreguje jejich stav na základě nakonfigurovaného maximálního procenta dětí, které nejsou v pořádku. Toto procento se přebírá ze zásad na základě typu entity a podřízeného typu.

Pokud všechny podřízené děti mají stav OK, je agregovaný stav podřízeného stavu OK.
Pokud mají podřízené děti stav OK i stav upozornění, podřízený agregovaný stav je varování.
Pokud existují podřízené položky s chybovými stavy, které nerespektují maximální povolené procento podřízených položek, které nejsou v pořádku, agregovaný stav nadřazeného objektu je chyba.
Pokud podřízené položky s chybovým stavem respektují maximální povolené procento podřízených položek, které nejsou v pořádku, agregovaný stav nadřazeného stavu je varování.

Generování sestav stavu

Systémové komponenty, aplikace System Fabric a interní/externí watchdogs můžou hlásit entity Service Fabric. Zpravodajé místně určí stav monitorovaných entit na základě podmínek, které monitorují. Nemusí se dívat na globální stav ani agregovaná data. Žádoucím chováním je mít jednoduché zpravodaje, a ne složité organismy, které se musí dívat na mnoho věcí, aby odvozovaly, jaké informace se mají odeslat.

Aby bylo možné odesílat data o stavu do úložiště stavů, musí zpravodaj identifikovat ovlivněnou entitu a vytvořit sestavu stavu. K odeslání sestavy použijte rozhraní API FabricClient.HealthClient.ReportHealth , rozhraní API pro sestavy stavu vystavená na Partition objektech nebo CodePackageActivationContext , rutiny PowerShellu nebo REST.

Sestavy stavu

Sestavy stavu pro každou entitu v clusteru obsahují následující informace:

Id zdroje. Řetězec, který jednoznačně identifikuje zpravodaje události stavu.
Identifikátor entity. Identifikuje entitu, ve které se sestava používá. Liší se v závislosti na typu entity:
- Clusteru. Žádné
- Uzel. Název uzlu (řetězec).
- Aplikace. Název aplikace (URI). Představuje název instance aplikace nasazené v clusteru.
- Služby. Název služby (URI). Představuje název instance služby nasazené v clusteru.
- Oddíl. ID oddílu (GUID). Představuje jedinečný identifikátor oddílu.
- Replika. ID stavové repliky služby nebo ID instance bezstavové služby (INT64).
- DeployedApplication. Název aplikace (URI) a název uzlu (řetězec).
- DeployedServicePackage. Název aplikace (URI), název uzlu (řetězec) a název manifestu služby (řetězec).
Vlastnost Řetězec (nikoli pevný výčet), který umožňuje zpravodaji kategorizovat událost stavu pro konkrétní vlastnost entity. Reportér A může například hlásit stav vlastnosti Úložiště uzlu01 a zpravodaj B může hlásit stav vlastnosti Connectivity Uzlu01. V úložišti stavů se tyto sestavy považují za samostatné události stavu pro entitu Node01.
Popis: Řetězec, který umožňuje zpravodaji poskytnout podrobné informace o události stavu. SourceId, Property a HealthState by měly sestavu plně vystihovat. Popis přidá informace o sestavě čitelné pro člověka. Tento text usnadňuje správcům a uživatelům pochopení sestavy stavu.
HealthState. Výčet, který popisuje stav sestavy. Povolené hodnoty jsou OK, Warning a Error.
TimeToLive. Časový rozsah, který určuje, jak dlouho je zpráva o stavu platná. Spolu s funkcí RemoveWhenExpired umožňuje úložišti stavů zjistit, jak vyhodnotit události s vypršenou platností. Ve výchozím nastavení je hodnota nekonečná a sestava je platná navždy.
RemoveWhenExpired. Logická hodnota. Pokud je nastavená hodnota true, sestava stavu s vypršenou platností se automaticky odebere z úložiště stavů a nebude mít vliv na vyhodnocení stavu entity. Používá se, když je sestava platná pouze po určitou dobu a zpravodaj ji nemusí explicitně vymazat. Používá se také k odstranění sestav z úložiště stavu (například se změní sledovací zařízení a zastaví odesílání sestav s předchozím zdrojem a vlastností). Může odeslat sestavu s krátkým TimeToLive spolu s RemoveWhenExpired vymazat jakýkoli předchozí stav z úložiště stavů. Pokud je hodnota nastavena na false, sestava s vypršenou platností se považuje za chybu při vyhodnocení stavu. Falešná hodnota signalizuje úložišti stavů, že zdroj by měl pravidelně hlásit tuto vlastnost. Pokud ne, pak musí být něco v nepořádku se hlídacímogem. Stav hlídacího psa se zaznamenává tak, že se událost považuje za chybu.
SequenceNumber. Kladné celé číslo, které se musí neustále zvětšovat, představuje pořadí sestav. Používá se v úložišti stavů ke zjišťování zastaralých sestav, které jsou přijaty pozdě kvůli zpoždění sítě nebo jiným problémům. Sestava se odmítne, pokud je pořadové číslo menší nebo rovno naposledy použitému číslu pro stejnou entitu, zdroj a vlastnost. Pokud není zadané, pořadové číslo se vygeneruje automaticky. Pořadové číslo je nutné zadat pouze při hlášení o přechodech stavu. V takové situaci si musí zdroj pamatovat, které zprávy odeslal, a zachovat informace pro obnovení při převzetí služeb při selhání.

Tyto čtyři informace – SourceId, identifikátor entity, Property a HealthState – jsou vyžadovány pro každou sestavu stavu. Řetězec SourceId nesmí začínat předponou System., která je vyhrazená pro systémové sestavy. Pro stejnou entitu existuje pouze jedna sestava pro stejný zdroj a vlastnost. Několik sestav pro stejný zdroj a vlastnost se navzájem přepisuje, a to buď na straně klienta stavu (pokud jsou dávkové), nebo na straně úložiště stavů. Nahrazení je založeno na pořadových číslech; novější sestavy (s vyššími pořadovými čísly) nahrazují starší sestavy.

Události stavu

Úložiště stavů interně uchovává události stavu, které obsahují všechny informace ze sestav a další metadata. Metadata zahrnují čas, kdy byla sestava vydána klientovi stavu a čas, kdy byla změněna na straně serveru. Události stavu vrací dotazy na stav.

Přidaná metadata obsahují:

SourceUtcTimestamp. Čas, kdy byla sestava předaná klientovi stavu (koordinovaný univerzální čas)
LastModifiedUtcTimestamp. Čas poslední změny sestavy na straně serveru (koordinovaný univerzální čas)
IsExpired. Příznak, který označuje, jestli vypršela platnost sestavy při spuštění dotazu úložištěm stavů. Událost může vypršela pouze v případě, že removeWhenExpired má hodnotu false. V opačném případě se událost nevrátí dotazem a odebere se z úložiště.
LastOkTransitionAt, LastWarningTransitionAt, LastErrorTransitionAt. Čas posledního přechodu OK/upozornění/chyby. Tato pole poskytují historii přechodů stavu události.

Pole přechodu stavu se dají použít pro inteligentnější výstrahy nebo "historické" informace o událostech stavu. Umožňují například tyto scénáře:

Pošle výstrahu, když u vlastnosti došlo k upozornění nebo chybě déle než X minut. Kontrolou podmínky po určitou dobu se vyhnete upozorněním na dočasné podmínky. Například výstrahu, pokud byl stav varování déle než pět minut, lze přeložit do (HealthState == Warning and Now - LastWarningTransitionTime > 5 minut).
Upozorňovat pouze na podmínky, které se změnily v posledních X minutách. Pokud byla sestava chybou již před zadaným časem, může být ignorována, protože již byla dříve signalizovala.
Pokud vlastnost přepíná mezi upozorněním a chybou, určete, jak dlouho není v pořádku (to znamená, že není v pořádku). Například upozornění, pokud vlastnost není v pořádku déle než pět minut, lze přeložit na (HealthState != OK a Now - LastOkTransitionTime > 5 minut).

Příklad: Sestava a vyhodnocení stavu aplikace

Následující příklad odešle sestavu stavu prostřednictvím PowerShellu v prostředcích infrastruktury aplikace:/WordCount ze zdrojového myWatchdog. Sestava stavu obsahuje informace o "dostupnosti" vlastnosti stavu ve stavu chyby s nekonečným časem TimeToLive. Potom se dotazuje na stav aplikace, který vrátí agregované chyby stavu a ohlášené události stavu v seznamu událostí stavu.

PS C:\> Send-ServiceFabricApplicationHealthReport –ApplicationName fabric:/WordCount –SourceId "MyWatchdog" –HealthProperty "Availability" –HealthState Error

PS C:\> Get-ServiceFabricApplicationHealth fabric:/WordCount -ExcludeHealthStatistics


ApplicationName                 : fabric:/WordCount
AggregatedHealthState           : Error
UnhealthyEvaluations            :
                                  Error event: SourceId='MyWatchdog', Property='Availability'.

ServiceHealthStates             :
                                  ServiceName           : fabric:/WordCount/WordCountService
                                  AggregatedHealthState : Error

                                  ServiceName           : fabric:/WordCount/WordCountWebService
                                  AggregatedHealthState : Ok

DeployedApplicationHealthStates :
                                  ApplicationName       : fabric:/WordCount
                                  NodeName              : _Node_0
                                  AggregatedHealthState : Ok

                                  ApplicationName       : fabric:/WordCount
                                  NodeName              : _Node_2
                                  AggregatedHealthState : Ok

                                  ApplicationName       : fabric:/WordCount
                                  NodeName              : _Node_3
                                  AggregatedHealthState : Ok

                                  ApplicationName       : fabric:/WordCount
                                  NodeName              : _Node_4
                                  AggregatedHealthState : Ok

                                  ApplicationName       : fabric:/WordCount
                                  NodeName              : _Node_1
                                  AggregatedHealthState : Ok

HealthEvents                    :
                                  SourceId              : System.CM
                                  Property              : State
                                  HealthState           : Ok
                                  SequenceNumber        : 360
                                  SentAt                : 3/22/2016 7:56:53 PM
                                  ReceivedAt            : 3/22/2016 7:56:53 PM
                                  TTL                   : Infinite
                                  Description           : Application has been created.
                                  RemoveWhenExpired     : False
                                  IsExpired             : False
                                  Transitions           : Error->Ok = 3/22/2016 7:56:53 PM, LastWarning = 1/1/0001 12:00:00 AM

                                  SourceId              : MyWatchdog
                                  Property              : Availability
                                  HealthState           : Error
                                  SequenceNumber        : 131032204762818013
                                  SentAt                : 3/23/2016 3:27:56 PM
                                  ReceivedAt            : 3/23/2016 3:27:56 PM
                                  TTL                   : Infinite
                                  Description           :
                                  RemoveWhenExpired     : False
                                  IsExpired             : False
                                  Transitions           : Ok->Error = 3/23/2016 3:27:56 PM, LastWarning = 1/1/0001 12:00:00 AM

Využití modelu stavu

Model stavu umožňuje škálování cloudových služeb a základní platformy Service Fabric, protože monitorování a určení stavu se distribuují mezi různá monitorování v rámci clusteru. Jiné systémy mají jednu centralizovanou službu na úrovni clusteru, která parsuje všechny potenciálně užitečné informace generované službami. Tento přístup brání jejich škálovatelnosti. Zároveň jim neumožňuje shromažďovat konkrétní informace, které jim pomůžou identifikovat problémy a potenciální problémy co nejblíže původní příčině.

Model stavu se intenzivně používá pro monitorování a diagnostiku, pro vyhodnocení stavu clusteru a aplikací a pro monitorované upgrady. Jiné služby používají data o stavu k provádění automatických oprav, sestavování historie stavu clusteru a vydávání upozornění za určitých podmínek.