Aangepaste Service Fabric-statusrapporten toevoegen
Azure Service Fabric introduceert een statusmodel dat is ontworpen voor het markeren van beschadigde cluster- en toepassingsvoorwaarden voor specifieke entiteiten. Het statusmodel maakt gebruik van statusrapporteurs (systeemonderdelen en watchdogs). Het doel is een eenvoudige en snelle diagnose en reparatie. Serviceschrijvers moeten vooraf nadenken over gezondheid. Elke voorwaarde die van invloed kan zijn op de status, moet worden gerapporteerd, met name als deze problemen dicht bij de hoofdmap kan markeren. De statusinformatie kan tijd en moeite besparen bij foutopsporing en onderzoek. Het nut is vooral duidelijk wanneer de service op schaal actief is in de cloud (privé of Azure).
De Service Fabric-verslaggevers bewaken geïdentificeerde voorwaarden die van belang zijn. Ze rapporteren over deze voorwaarden op basis van hun lokale weergave. Het statusarchief verzamelt statusgegevens die door alle verslaggevers worden verzonden om te bepalen of entiteiten wereldwijd in orde zijn. Het model is bedoeld om uitgebreid, flexibel en gebruiksvriendelijk te zijn. De kwaliteit van de statusrapporten bepaalt de nauwkeurigheid van de statusweergave van het cluster. Fout-positieven die ten onrechte problemen met een slechte status aangeven, kunnen een negatieve invloed hebben op upgrades of andere services die gebruikmaken van statusgegevens. Voorbeelden van dergelijke services zijn reparatieservices en waarschuwingsmechanismen. Daarom is er enige aandacht nodig om rapporten te verstrekken waarin de voorwaarden van belang op de best mogelijke manier worden vastgelegd.
Voor het ontwerpen en implementeren van statusrapportage moeten watchdogs en systeemonderdelen:
- Definieer de voorwaarde waarin ze geïnteresseerd zijn, de manier waarop deze wordt bewaakt en de impact op de functionaliteit van het cluster of de toepassing. Bepaal op basis van deze informatie de eigenschap en status van het statusrapport.
- Bepaal de entiteit waarop het rapport van toepassing is.
- Bepaal waar de rapportage wordt uitgevoerd, vanuit de service of vanuit een interne of externe watchdog.
- Definieer een bron die wordt gebruikt om de journalist te identificeren.
- Kies een rapportagestrategie, periodiek of bij overgangen. De aanbevolen manier is periodiek, omdat deze eenvoudigere code vereist en minder gevoelig is voor fouten.
- Bepaal hoe lang het rapport voor beschadigde omstandigheden in het statusarchief moet blijven en hoe het moet worden gewist. Bepaal aan de hand van deze informatie de time-to-live van het rapport en het gedrag bij het verwijderen bij verlooptijd.
Zoals vermeld, kan rapportage worden gedaan vanuit:
- De bewaakte Service Fabric-servicereplica.
- Interne watchdogs die zijn geïmplementeerd als een Service Fabric-service (bijvoorbeeld een stateless Service Fabric-service die voorwaarden en rapporten over problemen bewaakt). De watchdogs kunnen worden geïmplementeerd op alle knooppunten of kunnen worden gekoppeld aan de bewaakte service.
- Interne watchdogs die worden uitgevoerd op de Service Fabric-knooppunten, maar niet worden geïmplementeerd als Service Fabric-services.
- Externe watchdogs die de resource van buiten het Service Fabric-cluster testen (bijvoorbeeld bewakingsservice zoals Gomez).
Notitie
Het cluster wordt standaard gevuld met statusrapporten die door de systeemonderdelen worden verzonden. Zie Systeemstatusrapporten gebruiken voor probleemoplossing voor meer informatie. De gebruikersrapporten moeten worden verzonden naar statusentiteiten die al door het systeem zijn gemaakt.
Zodra het ontwerp van de statusrapportage duidelijk is, kunnen statusrapporten eenvoudig worden verzonden. U kunt FabricClient gebruiken om de status te rapporteren als het cluster niet beveiligd is of als de infrastructuurclient beheerdersbevoegdheden heeft. Rapportage kan worden uitgevoerd via de API met behulp van FabricClient.HealthManager.ReportHealth, via PowerShell of via REST. Configuratieknoppen batchrapporten voor verbeterde prestaties.
Notitie
De rapportstatus is synchroon en vertegenwoordigt alleen het validatiewerk aan de clientzijde. Het feit dat het rapport wordt geaccepteerd door de statusclient of de Partition objecten of CodePackageActivationContext betekent niet dat het wordt toegepast in de store. Het wordt asynchroon verzonden en mogelijk in batches met andere rapporten. De verwerking op de server kan nog steeds mislukken: het volgnummer kan verlopen zijn, de entiteit waarop het rapport moet worden toegepast, is verwijderd, enzovoort.
Statusclient
De statusrapporten worden naar de statusbeheerder verzonden via een statusclient, die zich in de infrastructuurclient bevindt. De statusbeheerder slaat rapporten op in het statusarchief. De statusclient kan worden geconfigureerd met de volgende instellingen:
- HealthReportSendInterval: de vertraging tussen het moment dat het rapport wordt toegevoegd aan de client en het tijdstip waarop het naar de statusmanager wordt verzonden. Wordt gebruikt om rapporten in één bericht te verwerken, in plaats van één bericht voor elk rapport te verzenden. Batchverwerking verbetert de prestaties. Standaardinstelling: 30 seconden.
- HealthReportRetrySendInterval: het interval waarmee de statusclient samengevoegde statusrapporten opnieuw verzendt naar de statusmanager. Standaard: 30 seconden, minimaal 1 seconde.
- HealthOperationTimeout: de time-outperiode voor een rapportbericht dat naar de statusmanager wordt verzonden. Als er een time-out optreedt voor een bericht, probeert de statusclient het opnieuw totdat de statusmanager bevestigt dat het rapport is verwerkt. Standaardinstelling: twee minuten.
Notitie
Wanneer de rapporten in batch worden uitgevoerd, moet de infrastructuurclient ten minste voor healthreportSendInterval in leven worden gehouden om ervoor te zorgen dat ze worden verzonden. Als het bericht verloren is gegaan of als de statusbeheerder deze niet kan toepassen vanwege tijdelijke fouten, moet de infrastructuurclient langer in leven worden gehouden om het opnieuw te proberen.
De buffering op de client houdt rekening met de uniekheid van de rapporten. Als een bepaalde slechte journalist bijvoorbeeld 100 rapporten per seconde rapporteert over dezelfde eigenschap van dezelfde entiteit, worden de rapporten vervangen door de laatste versie. Er bestaat maximaal één dergelijk rapport in de clientwachtrij. Als batchverwerking is geconfigureerd, is het aantal rapporten dat naar de statusmanager wordt verzonden, slechts één per verzendinterval. Dit rapport is het laatst toegevoegde rapport, dat de meest recente status van de entiteit weergeeft.
Geef configuratieparameters op wanneer FabricClient wordt gemaakt door FabricClientSettings door te geven met de gewenste waarden voor statusgerelateerde vermeldingen.
In het volgende voorbeeld wordt een infrastructuurclient gemaakt en wordt aangegeven dat de rapporten moeten worden verzonden wanneer ze worden toegevoegd. Bij time-outs en fouten die opnieuw kunnen worden geprobeerd, vinden elke 40 seconden nieuwe pogingen plaats.
var clientSettings = new FabricClientSettings()
{
HealthOperationTimeout = TimeSpan.FromSeconds(120),
HealthReportSendInterval = TimeSpan.FromSeconds(0),
HealthReportRetrySendInterval = TimeSpan.FromSeconds(40),
};
var fabricClient = new FabricClient(clientSettings);
We raden u aan de standaardinstellingen van de infrastructuurclient te behouden, die zijn ingesteld HealthReportSendInterval op 30 seconden. Deze instelling zorgt voor optimale prestaties vanwege batchverwerking. Gebruik met Immediate true in FabricClient.HealthClient.ReportHealth API voor kritieke rapporten die zo snel mogelijk HealthReportSendOptions moeten worden verzonden. Directe rapporten overslaan het batchinterval. Gebruik deze vlag zorgvuldig; we willen waar mogelijk profiteren van de statusclientbatch. Direct verzenden is ook handig wanneer de infrastructuurclient wordt gesloten (het proces heeft bijvoorbeeld een ongeldige status vastgesteld en moet worden afgesloten om bijwerkingen te voorkomen). Het zorgt ervoor dat de verzamelde rapporten naar beste vermogen worden verzonden. Wanneer één rapport wordt toegevoegd met de vlag Immediate, worden alle samengevoegde rapporten sinds de laatste verzendbewerking door de statusclient gebatcheerd.
Dezelfde parameters kunnen worden opgegeven wanneer een verbinding met een cluster wordt gemaakt via PowerShell. In het volgende voorbeeld wordt een verbinding met een lokaal cluster gestart:
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
}
Net als bij API kunnen rapporten worden verzonden met behulp van -Immediate de switch om onmiddellijk te worden verzonden, ongeacht de HealthReportSendInterval waarde.
Voor REST worden de rapporten verzonden naar de Service Fabric-gateway, die een interne infrastructuurclient heeft. Deze client is standaard geconfigureerd om rapporten elke 30 seconden in batches te verzenden. U kunt het batch-interval wijzigen met de clusterconfiguratie-instelling HttpGatewayHealthReportSendInterval op HttpGateway. Zoals vermeld, is het een betere optie om de rapporten met Immediate true te verzenden.
Notitie
Om ervoor te zorgen dat niet-geautoriseerde services de status niet kunnen rapporteren aan de entiteiten in het cluster, configureert u de server om alleen aanvragen van beveiligde clients te accepteren. Voor de FabricClient rapporten die worden gebruikt, moet beveiliging zijn ingeschakeld om te kunnen communiceren met het cluster (bijvoorbeeld met Kerberos- of certificaatverificatie). Meer informatie over clusterbeveiliging.
Rapporteren vanuit services met beperkte bevoegdheden
Als Service Fabric-services geen beheerderstoegang tot het cluster hebben, kunt u de status van entiteiten vanuit de huidige context rapporteren via Partition of CodePackageActivationContext.
- Gebruik voor stateless services IStatelessServicePartition.ReportInstanceHealth om te rapporteren over het huidige service-exemplaar.
- Gebruik voor stateful services IStatefulServicePartition.ReportReplicaHealth om te rapporteren over de huidige replica.
- Gebruik IServicePartition.ReportPartitionHealth om te rapporteren over de huidige partitie-entiteit.
- Gebruik CodePackageActivationContext.ReportApplicationHealth om te rapporteren over de huidige toepassing.
- Gebruik CodePackageActivationContext.ReportDeployedApplicationHealth om te rapporteren over de huidige toepassing die op het huidige knooppunt is geïmplementeerd.
- Gebruik CodePackageActivationContext.ReportDeployedServicePackageHealth om te rapporteren over een servicepakket voor de toepassing die op het huidige knooppunt is geïmplementeerd.
Notitie
Intern houden de Partition en een CodePackageActivationContext statusclient die is geconfigureerd met standaardinstellingen. Zoals uitgelegd voor de statusclient, worden rapporten in batches en op een timer verzonden. De objecten moeten levend worden gehouden om het rapport te kunnen verzenden.
U kunt opgeven HealthReportSendOptions wanneer rapporten worden verzonden via Partition en CodePackageActivationContext status-API's. Als u kritieke rapporten hebt die zo snel mogelijk moeten worden verzonden, gebruikt HealthReportSendOptions u met Direct true. Directe rapporten omzeilen het batchinterval van de interne statusclient. Zoals eerder vermeld, gebruik deze vlag zorgvuldig; we willen waar mogelijk profiteren van de statusclientbatch.
Ontwerpstatusrapportage
De eerste stap bij het genereren van rapporten van hoge kwaliteit is het identificeren van de voorwaarden die van invloed kunnen zijn op de status van de service. Elke voorwaarde die kan helpen bij het markeren van problemen in de service of het cluster wanneer deze wordt gestart, of nog beter, voordat er een probleem optreedt, kan miljarden dollars besparen. De voordelen zijn onder andere minder uitvallen, minder nachtelijke uren besteed aan het onderzoeken en herstellen van problemen en een hogere klanttevredenheid.
Zodra de voorwaarden zijn geïdentificeerd, moeten watchdog-schrijvers de beste manier vinden om ze te controleren op een balans tussen overhead en bruikbaarheid. Denk bijvoorbeeld aan een service die complexe berekeningen uitvoert die gebruikmaken van enkele tijdelijke bestanden op een share. Een watchdog kan de share controleren om ervoor te zorgen dat er voldoende ruimte beschikbaar is. Het kan luisteren naar meldingen van bestands- of mapwijzigingen. Er kan een waarschuwing worden gerapporteerd als een drempelwaarde vooraf wordt bereikt en een fout wordt gerapporteerd als de share vol is. In een waarschuwing kan een herstelsysteem beginnen met het opschonen van oudere bestanden op de share. Bij een fout kan een herstelsysteem de servicereplica verplaatsen naar een ander knooppunt. Let op hoe de statussen van de voorwaarde worden beschreven in termen van status: de status van de voorwaarde die kan worden beschouwd als in orde (ok) of beschadigd (waarschuwing of fout).
Zodra de bewakingsdetails zijn ingesteld, moet een watchdog-schrijver erachter komen hoe de watchdog moet worden geïmplementeerd. Als de voorwaarden vanuit de service kunnen worden bepaald, kan de watchdog deel uitmaken van de bewaakte service zelf. De servicecode kan bijvoorbeeld het gebruik van de share controleren en vervolgens elke keer rapporteren wanneer een bestand wordt geschreven. Het voordeel van deze aanpak is dat rapportage eenvoudig is. Zorg ervoor dat wordt voorkomen dat watchdog-bugs van invloed zijn op de servicefunctionaliteit.
Rapportage vanuit de bewaakte service is niet altijd een optie. Een watchdog binnen de service kan de voorwaarden mogelijk niet detecteren. Het heeft mogelijk niet de logica of gegevens om de beslissing te nemen. De overhead voor het bewaken van de omstandigheden kan hoog zijn. De voorwaarden zijn mogelijk ook niet specifiek voor een service, maar zijn in plaats daarvan van invloed op interacties tussen services. Een andere optie is om watchdogs als afzonderlijke processen in het cluster te hebben. De watchdogs controleren de voorwaarden en rapporteren, zonder dat dit van invloed is op de belangrijkste services. Deze watchdogs kunnen bijvoorbeeld worden geïmplementeerd als stateless services in dezelfde toepassing, geïmplementeerd op alle knooppunten of op dezelfde knooppunten als de service.
Soms is een watchdog die in het cluster wordt uitgevoerd ook geen optie. Als de bewaakte voorwaarde de beschikbaarheid of functionaliteit van de service is zoals gebruikers deze zien, is het het beste om de watchdogs op dezelfde plaats te hebben als de gebruikersclients. Daar kunnen ze de bewerkingen op dezelfde manier testen als gebruikers ze aanroepen. U kunt bijvoorbeeld een watchdog hebben die zich buiten het cluster bevindt, aanvragen naar de service verzendt en de latentie en juistheid van het resultaat controleert. (Voor een rekenmachineservice retourneert 2+2 bijvoorbeeld 4 in een redelijke tijd?)
Zodra de details van de watchdog zijn voltooid, moet u beslissen over een bron-id die deze uniek identificeert. Als er meerdere watchdogs van hetzelfde type in het cluster wonen, moeten ze rapporteren over verschillende entiteiten of, als ze rapporteren over dezelfde entiteit, een andere bron-id of -eigenschap gebruiken. Op deze manier kunnen hun rapporten naast elkaar bestaan. De eigenschap van het statusrapport moet de bewaakte voorwaarde vastleggen. (In het bovenstaande voorbeeld kan de eigenschap ShareSize zijn.) Als meerdere rapporten van toepassing zijn op dezelfde voorwaarde, moet de eigenschap dynamische informatie bevatten waarmee rapporten naast elkaar kunnen worden gebruikt. Als er bijvoorbeeld meerdere shares moeten worden bewaakt, kan de naam van de eigenschap ShareSize-sharename zijn.
Notitie
Gebruik het statusarchief niet om statusinformatie bij te houden. Alleen gezondheidsgerelateerde informatie moet worden gerapporteerd als status, omdat deze informatie van invloed is op de statusevaluatie van een entiteit. De health store is niet ontworpen als een winkel voor algemeen gebruik. Er wordt gebruikgemaakt van statusevaluatielogica om alle gegevens samen te voegen in de status. Het verzenden van informatie die niet gerelateerd is aan de status (zoals het rapporteren van de status met de status OK) heeft geen invloed op de geaggregeerde status, maar kan wel een negatieve invloed hebben op de prestaties van het statusarchief.
Het volgende beslissingspunt is over welke entiteit moet worden rapporteren. Meestal identificeert de voorwaarde de entiteit duidelijk. Kies de entiteit met de best mogelijke granulariteit. Als een voorwaarde van invloed is op alle replica's in een partitie, rapporteert u over de partitie, niet over de service. Er zijn echter hoekgevallen waar meer nagedacht moet worden. Als de voorwaarde van invloed is op een entiteit, zoals een replica, maar de voorwaarde langer dan de duur van de replica moet worden gemarkeerd, moet deze worden gerapporteerd op de partitie. Anders worden alle rapporten opgeschoond wanneer de replica wordt verwijderd. Watchdog-schrijvers moeten nadenken over de levensduur van de entiteit en het rapport. Het moet duidelijk zijn wanneer een rapport moet worden opgeschoond vanuit een winkel (bijvoorbeeld wanneer een fout die is gerapporteerd voor een entiteit niet meer van toepassing is).
Laten we eens kijken naar een voorbeeld dat de punten samenvoegt die ik heb beschreven. Overweeg een Service Fabric-toepassing die bestaat uit een stateful permanente hoofdservice en secundaire stateless services die zijn geïmplementeerd op alle knooppunten (één secundair servicetype voor elk type taak). De master heeft een verwerkingswachtrij die opdrachten bevat die door secundaire databases moeten worden uitgevoerd. De secundaire databases voeren de binnenkomende aanvragen uit en sturen bevestigingssignalen terug. Een voorwaarde die kan worden bewaakt, is de lengte van de hoofdverwerkingswachtrij. Als de lengte van de hoofdwachtrij een drempelwaarde bereikt, wordt er een waarschuwing gerapporteerd. De waarschuwing geeft aan dat de secundaire databases de belasting niet kunnen verwerken. Als de wachtrij de maximale lengte bereikt en opdrachten worden verwijderd, wordt er een fout gerapporteerd, omdat de service niet kan worden hersteld. De rapporten kunnen zich in de eigenschap QueueStatus bevinden. De watchdog bevindt zich in de service en wordt periodiek verzonden naar de primaire replica van de hoofdserver. De time to live is twee minuten en wordt periodiek elke 30 seconden verzonden. Als de primaire uitvalt, wordt het rapport automatisch opgeschoond vanuit de Store. Als de servicereplica actief is, maar vastgelopen is of andere problemen ondervindt, verloopt het rapport in het statusarchief. In dit geval wordt de entiteit geëvalueerd op fout.
Een andere voorwaarde die kan worden bewaakt, is de uitvoeringstijd van de taak. De master distribueert taken naar de secundaire databases op basis van het taaktype. Afhankelijk van het ontwerp kan de master de secundaire databases op de taakstatus peilen. Het kan ook wachten tot secundaire databases bevestigingssignalen terugsturen wanneer ze klaar zijn. In het tweede geval moet ervoor worden gezorgd dat situaties worden gedetecteerd waarin secundaire bestanden sterven of berichten verloren gaan. Een optie is dat de master een ping-aanvraag verzendt naar dezelfde secundaire, die de status terugstuurt. Als er geen status wordt ontvangen, wordt dit als een fout beschouwd en wordt de taak opnieuw gepland. Bij dit gedrag wordt ervan uitgegaan dat de taken idempotent zijn.
De bewaakte voorwaarde kan worden vertaald als een waarschuwing als de taak niet is voltooid in een bepaalde tijd (t1, bijvoorbeeld 10 minuten). Als de taak niet op tijd is voltooid (t2, bijvoorbeeld 20 minuten), kan de bewaakte voorwaarde worden vertaald als Fout. Deze rapportage kan op verschillende manieren worden uitgevoerd:
- De primaire replica van de hoofdreplica rapporteert periodiek over zichzelf. U kunt één eigenschap hebben voor alle taken in behandeling in de wachtrij. Als ten minste één taak langer duurt, is de rapportstatus voor de eigenschap PendingTasks een waarschuwing of fout, indien van toepassing. Als er geen taken in behandeling zijn of als alle taken zijn gestart, is de rapportstatus OK. De taken zijn permanent. Als de primaire uitvalt, kan de zojuist gepromoveerde primaire naar behoren blijven rapporteren.
- Een ander watchdog-proces (in de cloud of extern) controleert de taken (van buitenaf, op basis van het gewenste taakresultaat) om te zien of ze zijn voltooid. Als ze de drempelwaarden niet respecteren, wordt er een rapport verzonden naar de hoofdservice. Er wordt ook een rapport verzonden voor elke taak die de taak-id bevat, zoals PendingTask+taskId. Rapporten mogen alleen worden verzonden bij beschadigde statussen. Stel time to live in op een paar minuten en markeer de rapporten die moeten worden verwijderd wanneer ze verlopen om opschoning te garanderen.
- De secundaire taak die een taak uitvoert, meldt wanneer het langer duurt dan verwacht om deze uit te voeren. Het rapporteert over het service-exemplaar op de eigenschap PendingTasks. In het rapport wordt het service-exemplaar aangegeven dat problemen ondervindt, maar de situatie waarin het exemplaar sterft, wordt niet vastgelegd. De rapporten worden dan opgeschoond. Deze kan rapporteren over de secundaire service. Als de secundaire instantie de taak voltooit, wordt het rapport uit het archief gewist. Het rapport bevat niet de situatie waarin het bevestigingsbericht verloren is gegaan en de taak niet is voltooid vanuit het oogpunt van het hoofd.
Hoewel de rapportage wordt uitgevoerd in de hierboven beschreven gevallen, worden de rapporten vastgelegd in de toepassingsstatus wanneer de status wordt geëvalueerd.
Periodiek rapporteren versus bij overgang
Met behulp van het model voor statusrapportage kunnen watchdogs periodiek rapporten verzenden of over overgangen. De aanbevolen manier voor het rapporteren van watchdogs is periodiek, omdat de code veel eenvoudiger is en minder gevoelig is voor fouten. De watchdogs moeten ernaar streven om zo eenvoudig mogelijk te zijn om bugs te voorkomen die onjuiste rapporten activeren. Onjuiste rapporten over beschadigde statussen zijn van invloed op statusevaluaties en scenario's op basis van de status, inclusief upgrades. Onjuiste rapporten over de status verbergen problemen in het cluster, wat niet gewenst is.
Voor periodieke rapportage kan de watchdog worden geïmplementeerd met een timer. Bij een timer-callback kan de watchdog de status controleren en een rapport verzenden op basis van de huidige status. U hoeft niet te zien welk rapport eerder is verzonden en u hoeft ook geen optimalisaties aan te brengen op het gebied van berichten. De statusclient heeft batchlogica om de prestaties te verbeteren. Terwijl de statusclient actief wordt gehouden, wordt er intern opnieuw geprobeerd totdat het rapport wordt bevestigd door het statusarchief of de watchdog een nieuwer rapport genereert met dezelfde entiteit, eigenschap en bron.
Rapportage over overgangen vereist een zorgvuldige verwerking van de status. De watchdog bewaakt bepaalde voorwaarden en rapporteert alleen wanneer de voorwaarden veranderen. Het voordeel van deze aanpak is dat er minder rapporten nodig zijn. Het nadeel is dat de logica van de watchdog complex is. De watchdog moet de voorwaarden of de rapporten bijhouden, zodat ze kunnen worden geïnspecteerd om statuswijzigingen te bepalen. Bij failover moet u ervoor zorgen dat rapporten worden toegevoegd, maar nog niet naar het statusarchief worden verzonden. Het volgnummer moet steeds toenemen. Zo niet, dan worden de rapporten afgewezen als verouderd. In de zeldzame gevallen waarin gegevensverlies optreedt, kan synchronisatie nodig zijn tussen de status van de journalist en de status van het statusarchief.
Rapportage over overgangen is zinvol voor services die over zichzelf rapporteren, via Partition of CodePackageActivationContext. Wanneer het lokale object (replica of geïmplementeerd servicepakket/geïmplementeerde toepassing) wordt verwijderd, worden alle bijbehorende rapporten ook verwijderd. Deze automatische opschoning versoepelen de noodzaak van synchronisatie tussen de journalist en het statusarchief. Als het rapport voor de bovenliggende partitie of bovenliggende toepassing is, moet u ervoor zorgen dat failover verloopt om verouderde rapporten in het statusarchief te voorkomen. Logica moet worden toegevoegd om de juiste status te behouden en het rapport uit de opslag te wissen wanneer dit niet meer nodig is.
Statusrapportage implementeren
Zodra de entiteit en rapportdetails duidelijk zijn, kunt u statusrapporten verzenden via de API, PowerShell of REST.
API
Als u wilt rapporteren via de API, moet u een statusrapport maken dat specifiek is voor het entiteitstype waarover ze willen rapporteren. Geef het rapport aan een statusclient. U kunt ook een statusinformatie maken en deze doorgeven aan de juiste rapportagemethoden voor Partition of CodePackageActivationContext om te rapporteren over huidige entiteiten.
In het volgende voorbeeld ziet u periodieke rapportage van een watchdog in het cluster. De watchdog controleert of een externe resource kan worden geopend vanuit een knooppunt. De resource is nodig voor een servicemanifest in de toepassing. Als de resource niet beschikbaar is, kunnen de andere services in de toepassing nog steeds goed werken. Daarom wordt het rapport elke 30 seconden verzonden naar de geïmplementeerde servicepakketentiteit.
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
Verzend statusrapporten met Send-ServiceFabricEntityTypeHealthReport.
In het volgende voorbeeld ziet u periodieke rapportage over CPU-waarden op een knooppunt. De rapporten moeten elke 30 seconden worden verzonden en ze hebben een time-to-live van twee minuten. Als ze verlopen, ondervindt de journalist problemen, waardoor het knooppunt wordt geëvalueerd op fout. Wanneer de CPU een drempelwaarde overschrijdt, heeft het rapport een status van waarschuwing. Wanneer de CPU langer dan de geconfigureerde tijd boven een drempelwaarde blijft, wordt dit gerapporteerd als een fout. Anders verzendt de journalist de status 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
In het volgende voorbeeld wordt een tijdelijke waarschuwing voor een replica gerapporteerd. Eerst wordt de partitie-id opgehaald en vervolgens de replica-id voor de service waarin deze is geïnteresseerd. Vervolgens wordt vanuit PowershellWatcher een rapport verzonden over de eigenschap ResourceDependency. Het rapport is slechts twee minuten van belang en wordt automatisch uit de store verwijderd.
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
Verzend statusrapporten met behulp van REST met POST-aanvragen die naar de gewenste entiteit gaan en de beschrijving van het statusrapport in de hoofdtekst hebben. Zie bijvoorbeeld hoe u statusrapporten van REST-clusters of servicestatusrapporten verzendt. Alle entiteiten worden ondersteund.
Volgende stappen
Op basis van de statusgegevens kunnen serviceschrijvers en cluster-/toepassingsbeheerders manieren bedenken om de informatie te gebruiken. Ze kunnen bijvoorbeeld waarschuwingen instellen op basis van de status om ernstige problemen te ondervangen voordat ze storingen veroorzaken. Beheerders kunnen ook herstelsystemen instellen om problemen automatisch op te lossen.
Inleiding tot Service Fabric-statusbewaking
Service Fabric-statusrapporten weergeven
Servicestatus rapporteren en controleren
Systeemstatusrapporten gebruiken voor probleemoplossing