Inleiding tot de statuscontrole Service Fabric

Artikel
06/01/2023

Azure Service Fabric introduceert een statusmodel dat uitgebreide, flexibele en uitbreidbare statusevaluatie en -rapportage biedt. Het model maakt bijna realtime bewaking van de status van het cluster en de services die erin worden uitgevoerd. U kunt eenvoudig gezondheidsinformatie verkrijgen en potentiële problemen oplossen voordat ze trapsgewijs worden uitgevoerd en enorme storingen veroorzaken. In het typische model verzenden services rapporten op basis van hun lokale weergaven en wordt die informatie geaggregeerd om een algemene weergave op clusterniveau te bieden.

Service Fabric-onderdelen gebruiken dit uitgebreide statusmodel om hun huidige status te rapporteren. U kunt hetzelfde mechanisme gebruiken om de status van uw toepassingen te rapporteren. Als u investeert in hoogwaardige statusrapportage waarin uw aangepaste voorwaarden worden vastgelegd, kunt u problemen voor uw actieve toepassing veel gemakkelijker detecteren en oplossen.

Bekijk deze pagina voor een trainingsvideo waarin het Service Fabric-statusmodel en hoe het wordt gebruikt wordt beschreven:

Notitie

We hebben het subsysteem health gestart om te reageren op de behoefte aan bewaakte upgrades. Service Fabric biedt bewaakte toepassings- en clusterupgrades die zorgen voor volledige beschikbaarheid, geen downtime en minimale tot geen tussenkomst van de gebruiker. Om deze doelen te bereiken, controleert de upgrade de status op basis van geconfigureerd upgradebeleid. Een upgrade kan alleen worden uitgevoerd als de status de gewenste drempelwaarden respecteert. Anders wordt de upgrade automatisch teruggedraaid of onderbroken om beheerders de kans te geven de problemen op te lossen. Zie dit artikel voor meer informatie over toepassingsupgrades.

Statusarchief

Het statusarchief bewaart statusgerelateerde informatie over entiteiten in het cluster voor eenvoudig ophalen en evalueren. Het wordt geïmplementeerd als een permanente stateful service van Service Fabric om hoge beschikbaarheid en schaalbaarheid te garanderen. Het statusarchief maakt deel uit van de toepassing fabric:/System en is beschikbaar wanneer het cluster actief is.

Statusentiteiten en -hiërarchie

De statusentiteiten zijn ingedeeld in een logische hiërarchie waarin interacties en afhankelijkheden tussen verschillende entiteiten worden vastgelegd. Het statusarchief bouwt automatisch statusentiteiten en -hiërarchie op basis van rapporten die zijn ontvangen van Service Fabric-onderdelen.

De statusentiteiten weerspiegelen de Service Fabric-entiteiten. (De statustoepassingsentiteit komt bijvoorbeeld overeen met een toepassingsexemplaar dat is geïmplementeerd in het cluster, terwijl de statusknooppuntentiteit overeenkomt met een Service Fabric-clusterknooppunt.) De statushiërarchie legt de interacties van de systeementiteiten vast en vormt de basis voor geavanceerde statusevaluatie. Meer informatie over de belangrijkste Service Fabric-concepten vindt u in Het technische overzicht van Service Fabric. Zie Service Fabric-toepassingsmodel voor meer informatie over toepassingen.

Met de statusentiteiten en -hiërarchie kunnen het cluster en de toepassingen effectief worden gerapporteerd, foutopsporing uitgevoerd en bewaakt. Het statusmodel biedt een nauwkeurige, gedetailleerde weergave van de status van de vele bewegende stukken in het cluster.

Statusentiteiten. De statusentiteiten, ingedeeld in een hiërarchie op basis van bovenliggende en onderliggende relaties.

De statusentiteiten zijn:

Cluster. Vertegenwoordigt de status van een Service Fabric-cluster. In de statusrapporten van het cluster worden voorwaarden beschreven die van invloed zijn op het hele cluster. Deze voorwaarden zijn van invloed op meerdere entiteiten in het cluster of het cluster zelf. Op basis van de voorwaarde kan de journalist het probleem niet beperken tot een of meer beschadigde kinderen. Voorbeelden zijn de hersenen van het splitsen van het cluster als gevolg van problemen met netwerkpartitionering of communicatie.
Knooppunt. Vertegenwoordigt de status van een Service Fabric-knooppunt. Statusrapporten van knooppunten beschrijven voorwaarden die van invloed zijn op de functionaliteit van het knooppunt. Ze zijn doorgaans van invloed op alle geïmplementeerde entiteiten die erop worden uitgevoerd. Voorbeelden hiervan zijn knooppunten die onvoldoende schijfruimte hebben (of andere eigenschappen voor de hele machine, zoals geheugen, verbindingen) en wanneer een knooppunt niet beschikbaar is. De knooppuntentiteit wordt aangeduid met de knooppuntnaam (tekenreeks).
Toepassing. Vertegenwoordigt de status van een toepassingsexemplaren die in het cluster worden uitgevoerd. Toepassingsstatusrapporten beschrijven voorwaarden die van invloed zijn op de algehele status van de toepassing. Ze kunnen niet worden beperkt tot afzonderlijke onderliggende items (services of geïmplementeerde toepassingen). Voorbeelden zijn de end-to-end interactie tussen verschillende services in de toepassing. De toepassingsentiteit wordt geïdentificeerd door de toepassingsnaam (URI).
Service. Vertegenwoordigt de status van een service die wordt uitgevoerd in het cluster. Servicestatus rapporten beschrijven voorwaarden die van invloed zijn op de algehele status van de service. De journalist kan het probleem niet beperken tot een beschadigde partitie of replica. Voorbeelden zijn een serviceconfiguratie (zoals poort of externe bestandsshare) die problemen veroorzaakt voor alle partities. De service-entiteit wordt geïdentificeerd door de servicenaam (URI).
Partitie. Vertegenwoordigt de status van een servicepartitie. Partitiestatusrapporten beschrijven voorwaarden die van invloed zijn op de hele replicaset. Voorbeelden hiervan zijn wanneer het aantal replica's lager is dan het doelaantal en wanneer een partitie quorumverlies heeft. De partitie-entiteit wordt geïdentificeerd door de partitie-id (GUID).
Replica. Vertegenwoordigt de status van een stateful servicereplica of een stateless service-exemplaar. De replica is de kleinste eenheid waarover watchdogs en systeemonderdelen kunnen rapporteren voor een toepassing. Voor stateful services zijn voorbeelden een primaire replica die geen bewerkingen naar secundaire databases kan repliceren en trage replicatie. Een staatloos exemplaar kan ook rapporteren wanneer er geen resources meer zijn of wanneer er verbindingsproblemen zijn. De replica-entiteit wordt geïdentificeerd door de partitie-id (GUID) en de replica- of exemplaar-id (lang).
DeployedApplication. Vertegenwoordigt de status van een toepassing die wordt uitgevoerd op een knooppunt. Statusrapporten van geïmplementeerde toepassingen beschrijven voorwaarden die specifiek zijn voor de toepassing op het knooppunt die niet kunnen worden beperkt tot servicepakketten die op hetzelfde knooppunt zijn geïmplementeerd. Voorbeelden zijn fouten wanneer het toepassingspakket niet kan worden gedownload op dat knooppunt en problemen met het instellen van toepassingsbeveiligingsprincipals op het knooppunt. De geïmplementeerde toepassing wordt geïdentificeerd door de toepassingsnaam (URI) en de knooppuntnaam (tekenreeks).
DeployedServicePackage. Vertegenwoordigt de status van een servicepakket dat wordt uitgevoerd op een knooppunt in het cluster. Hierin worden voorwaarden beschreven die specifiek zijn voor een servicepakket die geen invloed hebben op de andere servicepakketten op hetzelfde knooppunt voor dezelfde toepassing. Voorbeelden zijn een codepakket in het servicepakket dat niet kan worden gestart en een configuratiepakket dat niet kan worden gelezen. Het geïmplementeerde servicepakket wordt geïdentificeerd door de toepassingsnaam (URI), de knooppuntnaam (tekenreeks), de naam van het servicemanifest (tekenreeks) en de activerings-id (tekenreeks) van het servicepakket.

De granulariteit van het statusmodel maakt het eenvoudig om problemen te detecteren en op te lossen. Als een service bijvoorbeeld niet reageert, is het mogelijk om te melden dat het exemplaar van de toepassing niet in orde is. Rapportage op dat niveau is echter niet ideaal, omdat het probleem mogelijk niet van invloed is op alle services binnen die toepassing. Het rapport moet worden toegepast op de beschadigde service of op een specifieke onderliggende partitie, als meer informatie naar die partitie verwijst. De gegevens worden automatisch weergegeven in de hiërarchie en een beschadigde partitie wordt zichtbaar gemaakt op service- en toepassingsniveau. Met deze aggregatie kunt u de hoofdoorzaak van het probleem sneller vaststellen en oplossen.

De statushiërarchie bestaat uit bovenliggende en onderliggende relaties. Een cluster bestaat uit knooppunten en toepassingen. Toepassingen hebben services en geïmplementeerde toepassingen. Geïmplementeerde toepassingen hebben servicepakketten geïmplementeerd. Services hebben partities en elke partitie heeft een of meer replica's. Er is een speciale relatie tussen knooppunten en geïmplementeerde entiteiten. Een beschadigd knooppunt, zoals gerapporteerd door het instantiesysteemonderdeel, de failoverbeheerservice, is van invloed op de geïmplementeerde toepassingen, servicepakketten en replica's die erop zijn geïmplementeerd.

De statushiërarchie vertegenwoordigt de meest recente status van het systeem op basis van de meest recente statusrapporten, wat bijna realtime informatie is. Interne en externe watchdogs kunnen rapporteren over dezelfde entiteiten op basis van toepassingsspecifieke logica of aangepaste bewaakte voorwaarden. Gebruikersrapporten bestaan naast de systeemrapporten.

Plan om te investeren in het rapporteren en reageren op status tijdens het ontwerpen van een grote cloudservice. Deze investering vooraf maakt de service eenvoudiger om fouten op te sporen, te bewaken en te gebruiken.

Statussen

Service Fabric gebruikt drie statusstatussen om te beschrijven of een entiteit in orde is of niet: OK, waarschuwing en fout. Elk rapport dat naar het statusarchief wordt verzonden, moet een van deze statussen opgeven. Het resultaat van de statusevaluatie is een van deze statussen.

De mogelijke statussen zijn:

Oké. De entiteit is in orde. Er zijn geen bekende problemen gerapporteerd over de app of de onderliggende items (indien van toepassing).
Waarschuwing. Er zijn enkele problemen met de entiteit, maar deze kan nog steeds correct werken. Er zijn bijvoorbeeld vertragingen, maar deze veroorzaken nog geen functionele problemen. In sommige gevallen kan de waarschuwingsvoorwaarde zichzelf herstellen zonder externe tussenkomst. In dergelijke gevallen vergroten gezondheidsrapporten het bewustzijn en bieden ze inzicht in wat er aan de hand is. In andere gevallen kan de waarschuwingsvoorwaarde zonder tussenkomst van de gebruiker afnemen tot een ernstig probleem.
Fout. De entiteit is beschadigd. Er moet actie worden ondernomen om de status van de entiteit te herstellen, omdat deze niet goed kan werken.
Onbekend. De entiteit bestaat niet in het statusarchief. Dit resultaat kan worden verkregen uit de gedistribueerde query's waarmee resultaten van meerdere onderdelen worden samengevoegd. De query get node list gaat bijvoorbeeld naar FailoverManager, ClusterManager en HealthManager; get application list query gaat naar ClusterManager en HealthManager. Met deze query's worden resultaten van meerdere systeemonderdelen samengevoegd. Als een ander systeemonderdeel een entiteit retourneert die niet aanwezig is in het statusarchief, heeft het samengevoegde resultaat een onbekende status. Een entiteit is niet in de opslag omdat statusrapporten nog niet zijn verwerkt of omdat de entiteit is opgeschoond na verwijdering.

Statusbeleid

Het statusarchief past statusbeleid toe om te bepalen of een entiteit in orde is op basis van de rapporten en onderliggende items.

Notitie

Statusbeleid kan worden opgegeven in het clustermanifest (voor evaluatie van de status van het cluster en knooppunt) of in het toepassingsmanifest (voor toepassingsevaluatie en alle onderliggende items). Aanvragen voor statusevaluatie kunnen ook worden doorgegeven in aangepaste statusevaluatiebeleidsregels, die alleen voor die evaluatie worden gebruikt.

Service Fabric past standaard strikte regels toe (alles moet in orde zijn) voor de bovenliggende en onderliggende hiërarchische relatie. Als zelfs een van de onderliggende elementen één beschadigde gebeurtenis heeft, wordt het bovenliggende item als beschadigd beschouwd.

Clusterstatusbeleid

Het clusterstatusbeleid wordt gebruikt om de status van het cluster en de status van het knooppunt te evalueren. Het beleid kan worden gedefinieerd in het clustermanifest. Als deze niet aanwezig is, wordt het standaardbeleid (nul getolereerde fouten) gebruikt.

Het clusterstatusbeleid bevat:

ConsiderWarningAsError. Hiermee geeft u op of waarschuwingsstatusrapporten moeten worden behandeld als fouten tijdens de statusevaluatie. Standaard: onwaar.
MaxPercentUnhealthyApplications. Hiermee geeft u het maximum getolereerde percentage toepassingen op dat beschadigd kan zijn voordat het cluster als fout wordt beschouwd.
MaxPercentUnhealthyNodes. Hiermee geeft u het maximum getolereerde percentage knooppunten op dat beschadigd kan zijn voordat het cluster als fout wordt beschouwd. In grote clusters zijn sommige knooppunten altijd offline of niet beschikbaar voor reparaties, dus dit percentage moet worden geconfigureerd om dat te tolereren.
ApplicationTypeHealthPolicyMap. De statusbeleidstoewijzing van het toepassingstype kan tijdens de evaluatie van de clusterstatus worden gebruikt om speciale toepassingstypen te beschrijven. Standaard worden alle toepassingen in een pool geplaatst en geëvalueerd met MaxPercentUnhealthyApplications. Als sommige toepassingstypen anders moeten worden behandeld, kunnen ze uit de globale pool worden gehaald. In plaats daarvan worden ze geëvalueerd op basis van de percentages die zijn gekoppeld aan hun toepassingstypenaam in de kaart. In een cluster zijn er bijvoorbeeld duizenden toepassingen van verschillende typen en enkele exemplaren van beheertoepassingen van een speciaal toepassingstype. De besturingstoepassingen mogen nooit fouten veroorzaken. U kunt de globale MaxPercentUnhealthyApplications opgeven op 20% om bepaalde fouten te tolereren, maar voor het toepassingstype ControlApplicationType stelt u maxPercentUnhealthyApplications in op 0. Op deze manier wordt het cluster geëvalueerd als sommige van de vele toepassingen niet in orde zijn, maar lager is dan het algemene beschadigde percentage. Een waarschuwingsstatus heeft geen invloed op de clusterupgrade of andere bewaking die wordt geactiveerd door de status van de fout. Maar zelfs één besturingstoepassing in fout zou het cluster beschadigd maken, waardoor het terugdraaien wordt geactiveerd of de clusterupgrade wordt onderbroken, afhankelijk van de upgradeconfiguratie. Voor de toepassingstypen die in de kaart zijn gedefinieerd, worden alle toepassingsexemplaren uit de globale groep met toepassingen gehaald. Ze worden geëvalueerd op basis van het totale aantal toepassingen van het toepassingstype, met behulp van de specifieke MaxPercentUnhealthyApplications van de kaart. Alle overige toepassingen blijven in de globale pool en worden geëvalueerd met MaxPercentUnhealthyApplications.

Het volgende voorbeeld is een fragment uit een clustermanifest. Als u vermeldingen in de toepassingstypetoewijzing wilt definiëren, vervangt u de parameternaam door 'ApplicationTypeMaxPercentUnhealthyApplications-', gevolgd door de naam van het toepassingstype.
```
<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. De statusbeleidstoewijzing van het knooppunttype kan tijdens de evaluatie van de clusterstatus worden gebruikt om speciale knooppunttypen te beschrijven. De knooppunttypen worden geëvalueerd op basis van de percentages die zijn gekoppeld aan de naam van het knooppunttype in de kaart. Het instellen van deze waarde heeft geen invloed op de globale pool met knooppunten die worden gebruikt voor MaxPercentUnhealthyNodes. Een cluster heeft bijvoorbeeld honderden knooppunten van verschillende typen en een paar knooppunttypen die als host fungeren voor belangrijk werk. Er mogen geen knooppunten in dat type niet beschikbaar zijn. U kunt globaal MaxPercentUnhealthyNodes opgeven op 20% om bepaalde fouten voor alle knooppunten te tolereren, maar voor het knooppunttype SpecialNodeTypestelt u de MaxPercentUnhealthyNodes in op 0. Als sommige van de vele knooppunten een slechte status hebben, maar onder het algemene percentage van de slechte status liggen, wordt het cluster geëvalueerd als een waarschuwingsstatus. Een waarschuwingsstatus heeft geen invloed op de clusterupgrade of andere bewaking die wordt geactiveerd door een foutstatus. Maar zelfs één knooppunt van het type SpecialNodeType met de status Fout zou het cluster beschadigd maken en terugdraaien activeren of de clusterupgrade onderbreken, afhankelijk van de upgradeconfiguratie. Als u daarentegen de globale MaxPercentUnhealthyNodes waarde instelt op 0 en het SpecialNodeType maximumpercentage knooppunten met een foutstatus instelt op 100 met één knooppunt van het type SpecialNodeType , wordt het cluster nog steeds in een foutstatus geplaatst, omdat de algemene beperking in dit geval strenger is.

Het volgende voorbeeld is een fragment uit een clustermanifest. Als u vermeldingen in de toewijzing van het knooppunttype wilt definiëren, vervangt u de parameternaam door 'NodeTypeMaxPercentUnhealthyNodes-', gevolgd door de naam van het knooppunttype.
```
<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>
```

Toepassingsstatusbeleid

In het toepassingsstatusbeleid wordt beschreven hoe de evaluatie van gebeurtenissen en aggregatie van onderliggende statussen wordt uitgevoerd voor toepassingen en hun onderliggende elementen. Deze kan worden gedefinieerd in het toepassingsmanifest ,ApplicationManifest.xml, in het toepassingspakket. Als er geen beleid is opgegeven, gaat Service Fabric ervan uit dat de entiteit een slechte status heeft als deze een statusrapport of een onderliggend item heeft bij de status van de waarschuwing of fout. De configureerbare beleidsregels zijn:

ConsiderWarningAsError. Hiermee geeft u op of waarschuwingsstatusrapporten moeten worden behandeld als fouten tijdens de statusevaluatie. Standaard: onwaar.
MaxPercentUnhealthyDeployedApplications. Hiermee geeft u het maximale getolereerde percentage geïmplementeerde toepassingen op dat beschadigd kan zijn voordat de toepassing als fout wordt beschouwd. Dit percentage wordt berekend door het aantal beschadigde geïmplementeerde toepassingen te delen over het aantal knooppunten waarop de toepassingen momenteel in het cluster zijn geïmplementeerd. De berekening wordt naar boven afgerond om één fout op kleine aantallen knooppunten te tolereren. Standaardpercentage: nul.
DefaultServiceTypeHealthPolicy. Hiermee geeft u het statusbeleid voor het standaardservicetype op, dat het standaardstatusbeleid voor alle servicetypen in de toepassing vervangt.
ServiceTypeHealthPolicyMap. Biedt een overzicht van servicestatusbeleid per servicetype. Deze beleidsregels vervangen het standaard statusbeleid voor servicetypen voor elk opgegeven servicetype. Als een toepassing bijvoorbeeld een staatloos gatewayservicetype en een servicetype stateful engine heeft, kunt u het statusbeleid voor de evaluatie ervan anders configureren. Wanneer u beleid per servicetype opgeeft, kunt u gedetailleerdere controle krijgen over de status van de service.

Statusbeleid voor servicetypen

Het statusbeleid voor servicetypen geeft aan hoe de services en de onderliggende elementen van de services moeten worden geëvalueerd en samengevoegd. Het beleid bevat:

MaxPercentUnhealthyPartitionsPerService. Hiermee geeft u het maximale getolereerde percentage van beschadigde partities voordat een service als beschadigd wordt beschouwd. Standaardpercentage: nul.
MaxPercentUnhealthyReplicasPerPartition. Hiermee geeft u het maximum getolereerde percentage van beschadigde replica's voordat een partitie als beschadigd wordt beschouwd. Standaardpercentage: nul.
MaxPercentUnhealthyServices. Hiermee geeft u het maximum getolereerde percentage van beschadigde services voordat de toepassing als beschadigd wordt beschouwd. Standaardpercentage: nul.

Het volgende voorbeeld is een fragment uit een toepassingsmanifest:

    <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>

Statusevaluatie

Gebruikers en geautomatiseerde services kunnen de status voor elke entiteit op elk gewenst moment evalueren. Om de status van een entiteit te evalueren, worden in het statusarchief alle statusrapporten over de entiteit samengevoegd en worden alle onderliggende rapporten van de entiteit geëvalueerd (indien van toepassing). Het algoritme voor statusaggregatie maakt gebruik van statusbeleid dat aangeeft hoe statusrapporten moeten worden geëvalueerd en hoe de statussen van kinderen moeten worden geaggregeerd (indien van toepassing).

Aggregatie van statusrapport

Eén entiteit kan meerdere statusrapporten hebben die door verschillende verslaggevers (systeemonderdelen of watchdogs) over verschillende eigenschappen worden verzonden. De aggregatie maakt gebruik van het bijbehorende statusbeleid, met name het lid ConsiderWarningAsError van het toepassings- of clusterstatusbeleid. ConsiderWarningAsError geeft aan hoe waarschuwingen moeten worden geëvalueerd.

De geaggregeerde status wordt geactiveerd door de slechtste statusrapporten van de entiteit. Als er ten minste één foutstatusrapport is, is de geaggregeerde status een fout.

Aggregatie van statusrapporten met foutenrapport.

Een statusentiteit met een of meer foutstatusrapporten wordt geëvalueerd als Fout. Hetzelfde geldt voor een verlopen statusrapport, ongeacht de status.

Als er geen foutrapporten en een of meer waarschuwingen zijn, is de geaggregeerde status waarschuwing of fout, afhankelijk van de beleidsvlag ConsiderWarningAsError.

Aggregatie van statusrapporten met waarschuwingsrapport en ConsiderWarningAsError false.

Aggregatie van statusrapporten met waarschuwingsrapport en ConsiderWarningAsError ingesteld op false (standaard).

Onderliggende statusaggregatie

De geaggregeerde status van een entiteit weerspiegelt de onderliggende statussen (indien van toepassing). Het algoritme voor het aggregeren van onderliggende statussen maakt gebruik van het statusbeleid dat van toepassing is op basis van het entiteitstype.

Aggregatie van de status van onderliggende entiteiten.

Onderliggende aggregatie op basis van statusbeleid.

Nadat het statusarchief alle onderliggende items heeft geëvalueerd, worden hun statussen geaggregeerd op basis van het geconfigureerde maximumpercentage van beschadigde kinderen. Dit percentage wordt opgehaald uit het beleid op basis van de entiteit en het onderliggende type.

Als alle onderliggende items de status OK hebben, is de geaggregeerde status van het onderliggende item OK.
Als kinderen zowel de status OK als de waarschuwingsstatus hebben, is de geaggregeerde status van het onderliggende item een waarschuwing.
Als er onderliggende items zijn met foutstatussen die het maximaal toegestane percentage beschadigde kinderen niet respecteren, is de geaggregeerde status van de bovenliggende status een fout.
Als de onderliggende items met foutstatussen het maximaal toegestane percentage beschadigde kinderen respecteren, is de geaggregeerde status van de bovenliggende status een waarschuwing.

Statusrapportage

Systeemonderdelen, System Fabric-toepassingen en interne/externe watchdogs kunnen rapporteren op basis van Service Fabric-entiteiten. De verslaggevers bepalen lokaal de status van de bewaakte entiteiten op basis van de voorwaarden die ze bewaken. Ze hoeven geen globale status te bekijken of gegevens te aggregeren. Het gewenste gedrag is om eenvoudige verslaggevers te hebben, en geen complexe organismen die naar veel dingen moeten kijken om af te maken welke informatie moet worden verzonden.

Als u statusgegevens naar het statusarchief wilt verzenden, moet een journalist de betrokken entiteit identificeren en een statusrapport maken. Als u het rapport wilt verzenden, gebruikt u de API FabricClient.HealthClient.ReportHealth , rapportstatus-API's die worden weergegeven op de Partition objecten of CodePackageActivationContext , PowerShell-cmdlets of REST.

Statusrapporten

De statusrapporten voor elk van de entiteiten in het cluster bevatten de volgende informatie:

SourceId. Een tekenreeks die de journalist van de statusgebeurtenis uniek identificeert.
Entiteits-id. Hiermee wordt de entiteit aangegeven waarop het rapport wordt toegepast. Dit verschilt op basis van het entiteitstype:
- Cluster. Geen.
- Knooppunt. Knooppuntnaam (tekenreeks).
- Toepassing. Toepassingsnaam (URI). Vertegenwoordigt de naam van het toepassingsexemplaar dat in het cluster is geïmplementeerd.
- Service. Servicenaam (URI). Vertegenwoordigt de naam van het service-exemplaar dat in het cluster is geïmplementeerd.
- Partitie. Partitie-id (GUID). Vertegenwoordigt de unieke partitie-id.
- Replica. De stateful servicereplica-id of de staatloze service-exemplaar-id (INT64).
- DeployedApplication. Toepassingsnaam (URI) en knooppuntnaam (tekenreeks).
- DeployedServicePackage. Toepassingsnaam (URI), knooppuntnaam (tekenreeks) en servicemanifestnaam (tekenreeks).
Eigenschap. Een tekenreeks (geen vaste opsomming) waarmee de journalist de statusgebeurtenis voor een specifieke eigenschap van de entiteit kan categoriseren. Journalist A kan bijvoorbeeld de status van de eigenschap 'Opslag' van Node01 rapporteren en journalist B kan de status van de eigenschap 'Connectiviteit' van Node01 rapporteren. In het statusarchief worden deze rapporten behandeld als afzonderlijke statusgebeurtenissen voor de entiteit Node01.
Beschrijving. Een tekenreeks waarmee een journalist gedetailleerde informatie kan verstrekken over de statusgebeurtenis. SourceId, Property en HealthState moeten het rapport volledig beschrijven. De beschrijving voegt door mensen leesbare informatie over het rapport toe. De tekst maakt het voor beheerders en gebruikers gemakkelijker om het statusrapport te begrijpen.
HealthState. Een opsomming die de status van het rapport beschrijft. De geaccepteerde waarden zijn OK, Waarschuwing en Fout.
TimeToLive. Een periode die aangeeft hoe lang het statusrapport geldig is. In combinatie met RemoveWhenExpired laat het de statusopslag weten hoe verlopen gebeurtenissen moeten worden geëvalueerd. De waarde is standaard oneindig en het rapport is voor altijd geldig.
RemoveWhenExpired. Een Booleaanse waarde. Als dit is ingesteld op true, wordt het verlopen statusrapport automatisch verwijderd uit het statusarchief en heeft het rapport geen invloed op de statusevaluatie van de entiteit. Wordt gebruikt wanneer het rapport alleen geldig is voor een opgegeven periode en de journalist het niet expliciet hoeft uit te wissen. Het wordt ook gebruikt om rapporten te verwijderen uit het statusarchief (een watchdog wordt bijvoorbeeld gewijzigd en stopt met het verzenden van rapporten met de vorige bron en eigenschap). Het kan een rapport verzenden met een korte TimeToLive samen met RemoveWhenExpired om eventuele eerdere statussen uit het statusarchief te wissen. Als de waarde is ingesteld op onwaar, wordt het verlopen rapport behandeld als een fout in de statusevaluatie. De waarde false geeft aan dat de bron regelmatig over deze eigenschap moet rapporteren. Als dat niet zo is, moet er iets mis zijn met de waakhond. De status van de watchdog wordt vastgelegd door de gebeurtenis als een fout te beschouwen.
SequenceNumber. Een positief geheel getal dat steeds groter moet worden, het vertegenwoordigt de volgorde van de rapporten. Het wordt gebruikt door het statusarchief om verouderde rapporten te detecteren die te laat worden ontvangen vanwege netwerkvertragingen of andere problemen. Een rapport wordt geweigerd als het reeksnummer kleiner is dan of gelijk is aan het laatst toegepaste getal voor dezelfde entiteit, bron en eigenschap. Als dit niet is opgegeven, wordt het volgnummer automatisch gegenereerd. Het is noodzakelijk om het volgnummer alleen in te voeren wanneer er wordt gerapporteerd over statusovergangen. In dit geval moet de bron onthouden welke rapporten zijn verzonden en de informatie bewaren voor herstel na failover.

Deze vier gegevens, SourceId, entiteits-id, Property en HealthState, zijn vereist voor elk statusrapport. De SourceId-tekenreeks mag niet beginnen met het voorvoegsel 'System.', dat is gereserveerd voor systeemrapporten. Voor dezelfde entiteit is er slechts één rapport voor dezelfde bron en eigenschap. Meerdere rapporten voor dezelfde bron en eigenschap overschrijven elkaar, hetzij aan de statusclientzijde (als ze in batch zijn) of aan de kant van het statusarchief. De vervanging is gebaseerd op volgnummers; nieuwere rapporten (met hogere volgnummers) vervangen oudere rapporten.

Statusgebeurtenissen

Intern bewaart het statusarchief statusgebeurtenissen, die alle informatie uit de rapporten bevatten, en aanvullende metagegevens. De metagegevens omvatten het tijdstip waarop het rapport aan de statusclient is gegeven en het tijdstip waarop het is gewijzigd aan de serverzijde. De statusgebeurtenissen worden geretourneerd door statusquery's.

De toegevoegde metagegevens bevatten:

SourceUtcTimestamp. Het tijdstip waarop het rapport aan de statusclient is gegeven (Coordinated Universal Time).
LastModifiedUtcTimestamp. Het tijdstip waarop het rapport voor het laatst is gewijzigd aan de serverzijde (Coordinated Universal Time).
IsExpired. Een vlag om aan te geven of het rapport is verlopen toen de query werd uitgevoerd door het statusarchief. Een gebeurtenis kan alleen worden verlopen als RemoveWhenExpired false is. Anders wordt de gebeurtenis niet geretourneerd door een query en wordt deze verwijderd uit de store.
LastOkTransitionAt, LastWarningTransitionAt, LastErrorTransitionAt. De laatste keer voor overgangen van OK/waarschuwing/fout. Deze velden geven de geschiedenis van de statusovergangen voor de gebeurtenis.

De velden voor statusovergang kunnen worden gebruikt voor slimmere waarschuwingen of 'historische' statusgebeurtenissen. Ze maken scenario's mogelijk, zoals:

Waarschuwing wanneer een eigenschap meer dan x minuten een waarschuwing/fout heeft gehad. Als u de voorwaarde gedurende een bepaalde periode controleert, voorkomt u waarschuwingen over tijdelijke omstandigheden. Een waarschuwing als de status meer dan vijf minuten een waarschuwing heeft gehad, kan bijvoorbeeld worden omgezet in (HealthState == Warning en Now - LastWarningTransitionTime > 5 minuten).
Alleen waarschuwen voor voorwaarden die in de afgelopen x minuten zijn gewijzigd. Als een rapport al een fout had vóór de opgegeven tijd, kan het worden genegeerd omdat het al eerder is gesignaleerd.
Als een eigenschap wisselt tussen waarschuwing en fout, bepaalt u hoe lang deze niet in orde is (dus niet OK). Een waarschuwing als de eigenschap bijvoorbeeld langer dan vijf minuten niet in orde is geweest, kan worden omgezet in (HealthState != Ok and Now - LastOkTransitionTime > 5 minuten).

Voorbeeld: Toepassingsstatus rapporteren en evalueren

In het volgende voorbeeld wordt een statusrapport verzonden via PowerShell op de toepassingsinfrastructuur:/WordCount van de bron MyWatchdog. Het statusrapport bevat informatie over de statuseigenschap 'beschikbaarheid' in een foutstatus, met oneindig TimeToLive. Vervolgens wordt er een query uitgevoerd op de toepassingsstatus, die geaggregeerde statusfouten en de gerapporteerde statusgebeurtenissen in de lijst met statusgebeurtenissen retourneert.

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

Gebruik van statusmodel

Met het statusmodel kunnen cloudservices en het onderliggende Service Fabric-platform worden geschaald, omdat bewakings- en statusbepalingen worden verdeeld over de verschillende monitors in het cluster. Andere systemen hebben één gecentraliseerde service op clusterniveau waarmee alle mogelijk nuttige informatie die door services wordt verzonden, wordt geparseerd. Deze benadering belemmert de schaalbaarheid ervan. Het staat hen ook niet toe om specifieke informatie te verzamelen om problemen en mogelijke problemen zo dicht mogelijk bij de hoofdoorzaak te identificeren.

Het statusmodel wordt intensief gebruikt voor bewaking en diagnose, voor het evalueren van de cluster- en toepassingsstatus en voor bewaakte upgrades. Andere services gebruiken statusgegevens om automatische reparaties uit te voeren, de statusgeschiedenis van het cluster op te bouwen en waarschuwingen te geven onder bepaalde voorwaarden.