Aangepaste statusrapporten van Service Fabric toevoegen
Azure Service Fabric introduceert een statusmodel dat is ontworpen om beschadigde cluster- en toepassingsvoorwaarden voor specifieke entiteiten te markeren. Het statusmodel maakt gebruik van statusrapporters (systeemonderdelen en watchdogs). Het doel is eenvoudig en snel diagnose en reparatie. Serviceschrijvers moeten vooraf nadenken over de status. Elke voorwaarde die van invloed kan zijn op de status, moet worden gerapporteerd, met name als dit kan helpen bij het markeren van problemen dicht bij de hoofdmap. De statusinformatie kan tijd en moeite besparen op foutopsporing en onderzoek. De bruikbaarheid is vooral duidelijk zodra de service op schaal in de cloud (privé of Azure) actief is.
De Service Fabric-reporters controleren geïdentificeerde interessevoorwaarden. Ze rapporteren over deze voorwaarden op basis van hun lokale weergave. In het statusarchief worden statusgegevens geaggregeerd die door alle rapportmakers worden verzonden om te bepalen of entiteiten globaal in orde zijn. Het model is bedoeld om rijk, flexibel en gebruiksvriendelijk te zijn. De kwaliteit van de statusrapporten bepaalt de nauwkeurigheid van de statusweergave van het cluster. Fout-positieven die ten onrechte beschadigde problemen vertonen, kunnen negatieve gevolgen hebben voor upgrades of andere services die gebruikmaken van statusgegevens. Voorbeelden van dergelijke services zijn reparatieservices en waarschuwingsmechanismen. Daarom is enige gedachte nodig om rapporten te verstrekken die op de best mogelijke manier de voorwaarden van belang vastleggen.
Als u statusrapportage, watchdogs en systeemonderdelen wilt ontwerpen en implementeren, moet u het volgende doen:
- 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 van het statusrapport en de 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 rapportgever te identificeren.
- Kies een rapportagestrategie, periodiek of bij overgangen. De aanbevolen manier is periodiek, omdat het 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. Met behulp van deze informatie bepaalt u de time-to-live van het rapport en het gedrag voor het verwijderen van de vervaldatum.
Zoals vermeld, kan rapportage worden uitgevoerd vanuit:
- De bewaakte Service Fabric-servicereplica.
- Interne waakhonden die zijn geïmplementeerd als een Service Fabric-service (bijvoorbeeld een stateless Service Fabric-service waarmee voorwaarden en problemen worden bewaakt). De watchdogs kunnen worden geïmplementeerd op alle knooppunten of kunnen worden geaffineerd met de bewaakte service.
- Interne watchdogs die worden uitgevoerd op de Service Fabric-knooppunten, maar die 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. Lees meer over het gebruik van systeemstatusrapporten voor probleemoplossing. De gebruikersrapporten moeten worden verzonden op statusentiteiten die al door het systeem zijn gemaakt.
Zodra het ontwerp voor 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 CodePackageActivationContext betekent niet dat het wordt toegepast in het archief. Het wordt asynchroon verzonden en mogelijk gebatcheerd 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 health manager verzonden via een statusclient, die zich in de fabric-client bevindt. Health Manager slaat rapporten op in het statusarchief. De statusclient kan worden geconfigureerd met de volgende instellingen:
- HealthReportSendInterval: de vertraging tussen de tijd dat het rapport wordt toegevoegd aan de client en de tijd die het naar de health manager wordt verzonden. Wordt gebruikt om rapporten in één bericht te batcheren, in plaats van één bericht voor elk rapport te verzenden. De batchverwerking verbetert de prestaties. Standaard: 30 seconden.
- HealthReportRetrySendInterval: het interval waarmee de statusclient geaccumuleerde statusrapporten opnieuw verzendt naar de health manager. Standaard: 30 seconden, minimum: 1 seconde.
- HealthOperationTimeout: de time-outperiode voor een rapportbericht dat naar de health manager is verzonden. Als er een time-out optreedt voor een bericht, probeert de statusclient het opnieuw totdat de health manager bevestigt dat het rapport is verwerkt. Standaard: twee minuten.
Notitie
Wanneer de rapporten in batches worden uitgevoerd, moet de fabric-client actief worden gehouden voor ten minste healthreportSendInterval om ervoor te zorgen dat ze worden verzonden. Als het bericht verloren gaat of de health manager deze niet kan toepassen vanwege tijdelijke fouten, moet de fabric-client langer actief blijven om het opnieuw te proberen.
Bij het bufferen van de client wordt rekening gehouden met de uniekheid van de rapporten. Als een bepaalde slechte rapporter bijvoorbeeld 100 rapporten per seconde rapporteert op dezelfde eigenschap van dezelfde entiteit, worden de rapporten vervangen door de laatste versie. Maximaal één dergelijk rapport bevindt zich in de clientwachtrij. Als batchverwerking is geconfigureerd, is het aantal rapporten dat naar health manager 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 deze worden 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, vindt 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);
U wordt aangeraden de standaardinstellingen voor de fabric-client te behouden, die is ingesteld op HealthReportSendInterval 30 seconden. Deze instelling zorgt voor optimale prestaties vanwege batchverwerking. Voor kritieke rapporten die zo snel mogelijk moeten worden verzonden, gebruikt HealthReportSendOptions u deze met direct true in FabricClient.HealthClient.ReportHealth-API . Directe rapporten omzeilen het batchinterval. Gebruik deze vlag zorgvuldig; we willen waar mogelijk profiteren van de statusclientbatch. Direct verzenden is ook handig wanneer de fabric-client wordt gesloten (het proces heeft bijvoorbeeld een ongeldige status vastgesteld en moet worden afgesloten om bijwerkingen te voorkomen). Het zorgt voor een best-effort verzenden van de samengevoegde rapporten. Wanneer er één rapport wordt toegevoegd met de vlag Direct, worden alle samengevoegde rapporten sinds de laatste verzendbewerking door de statusclient in batches geplaatst.
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 de API kunnen rapporten worden verzonden met behulp van -Immediate een switch die onmiddellijk moet 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 voor het verzenden van rapporten die elke 30 seconden in batch worden uitgevoerd. U kunt het batchinterval wijzigen met de clusterconfiguratie-instelling op HttpGatewayHealthReportSendInterval HttpGateway. Zoals vermeld, is het een betere optie om de rapporten waar Immediate te verzenden.
Notitie
Om ervoor te zorgen dat niet-geautoriseerde services de status niet kunnen rapporteren voor de entiteiten in het cluster, configureert u de server zodanig dat alleen aanvragen van beveiligde clients worden geaccepteerd. Voor FabricClient de rapportage moet beveiliging zijn ingeschakeld om te kunnen communiceren met het cluster (bijvoorbeeld met Kerberos- of certificaatverificatie). Meer informatie over clusterbeveiliging.
Rapporteren vanuit services met lage 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.
- Voor stateless services gebruikt u IStatelessServicePartition.ReportInstanceHealth om te rapporteren over het huidige service-exemplaar.
- Voor stateful services gebruikt u IStatefulServicePartition.ReportReplicaHealth om te rapporteren over de huidige replica.
- Gebruik IServicePartition.ReportPartitionHealth om te rapporteren over de huidige partitieentiteit.
- Gebruik CodePackageActivationContext.ReportApplicationHealth om te rapporteren over de huidige toepassing.
- Gebruik CodePackageActivationContext.ReportDeployedApplicationHealth om te rapporteren over de huidige toepassing die is geïmplementeerd op het huidige knooppunt.
- Gebruik CodePackageActivationContext.ReportDeployedServicePackageHealth om te rapporteren over een servicepakket voor de toepassing die is geïmplementeerd op het huidige knooppunt.
Notitie
Intern wordt een Partition CodePackageActivationContext statusclient geconfigureerd met standaardinstellingen. Zoals uitgelegd voor de statusclient, worden rapporten gebatcheerd en verzonden op een timer. De objecten moeten in leven worden gehouden om het rapport te kunnen verzenden.
U kunt opgeven HealthReportSendOptions wanneer u rapporten verzendt via Partition en CodePackageActivationContext status-API's. Als u kritieke rapporten hebt die zo snel mogelijk moeten worden verzonden, gebruikt HealthReportSendOptions u deze met Direct true. Directe rapporten omzeilen het batchinterval van de interne statusclient. Zoals eerder vermeld, gebruikt u deze vlag met zorg; we willen waar mogelijk profiteren van de statusclientbatch.
Statusrapportage ontwerpen
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 mogelijk miljarden dollars besparen. De voordelen zijn minder uitgevallen tijd, minder nachturen die zijn besteed aan het onderzoeken en herstellen van problemen, en hogere klanttevredenheid.
Zodra de voorwaarden zijn geïdentificeerd, moeten watchdog-schrijvers de beste manier vinden om ze te controleren op balans tussen overhead en bruikbaarheid. Denk bijvoorbeeld aan een service die complexe berekeningen uitvoert die een aantal tijdelijke bestanden op een share gebruiken. 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 is bereikt en er een fout wordt gerapporteerd als de share vol is. Bij een waarschuwing kan een herstelsysteem oudere bestanden op de share opschonen. Bij een fout kan een herstelsysteem de servicereplica naar een ander knooppunt verplaatsen. Let op hoe de statussen van de voorwaarde worden beschreven in termen van status: de status van de voorwaarde die als in orde (ok) of beschadigd kan worden beschouwd (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 het een bestand probeert te schrijven. Het voordeel van deze aanpak is dat rapportage eenvoudig is. Zorg ervoor dat watchdog-bugs geen invloed hebben 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 van het bewaken van de omstandigheden kan hoog zijn. De voorwaarden zijn mogelijk ook niet specifiek voor een service, maar beïnvloeden in plaats daarvan interacties tussen services. Een andere optie is om watchdogs in het cluster als afzonderlijke processen te hebben. De watchdogs controleren de voorwaarden en rapporten, zonder dat dit van invloed is op de belangrijkste diensten. 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 raadzaam om de watchdogs op dezelfde plaats te hebben als de gebruikersclients. Daar kunnen ze de bewerkingen testen op dezelfde manier als gebruikers ze aanroepen. U kunt bijvoorbeeld een watchdog hebben die zich buiten het cluster bevindt, aanvragen voor de service verzendt en de latentie en juistheid van het resultaat controleert. (Voor een rekenmachineservice retourneert bijvoorbeeld 2+2 4 binnen een redelijke tijd?)
Zodra de details van de watchdog zijn voltooid, moet u beslissen over een bron-id die deze uniek identificeert. Als meerdere watchdogs van hetzelfde type in het cluster wonen, moeten ze rapporteren over verschillende entiteiten of, als ze rapporteren over dezelfde entiteit, verschillende 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 eigenschapShareSize.) Als meerdere rapporten van toepassing zijn op dezelfde voorwaarde, moet de eigenschap dynamische informatie bevatten waarmee rapporten naast elkaar kunnen bestaan. Als er bijvoorbeeld meerdere shares moeten worden bewaakt, kan de eigenschapsnaam ShareSize-sharename zijn.
Notitie
Gebruik het statusarchief niet om statusinformatie te bewaren. Alleen statusgerelateerde informatie moet worden gerapporteerd als status, omdat deze informatie van invloed is op de statusevaluatie van een entiteit. Het gezondheidsarchief is niet ontworpen als een winkel voor algemeen gebruik. Er wordt gebruikgemaakt van logica voor statusevaluatie 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 een status OK) heeft geen invloed op de geaggregeerde status, maar dit kan een negatieve invloed hebben op de prestaties van het statusarchief.
Het volgende beslissingspunt is waarover de entiteit moet 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 op de service. Er zijn echter hoekgevallen waar meer gedachten nodig zijn. Als de voorwaarde van invloed is op een entiteit, zoals een replica, maar de wens is dat de voorwaarde meer dan de duur van de levensduur van de replica wordt gemarkeerd, moet deze worden gerapporteerd op de partitie. Als de replica wordt verwijderd, worden alle rapporten in het statusarchief opgeschoond. Watchdog schrijvers moeten nadenken over de levensduur van de entiteit en het rapport. Het moet duidelijk zijn wanneer een rapport moet worden opgeschoond uit een winkel (bijvoorbeeld wanneer een fout die op een entiteit is gerapporteerd, niet meer van toepassing is).
Laten we eens kijken naar een voorbeeld met de punten die ik heb beschreven. Overweeg een Service Fabric-toepassing die bestaat uit een stateful permanente hoofdservice en secundaire stateless services die op alle knooppunten zijn geïmplementeerd (één secundair servicetype voor elk type taak). De master heeft een verwerkingswachtrij die opdrachten bevat die door secundaire bestanden moeten worden uitgevoerd. De secundaire bestanden 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 bestanden 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 herstellen. De rapporten kunnen zich in de eigenschap QueueStatus bevinden. De watchdog bevindt zich in de service en wordt periodiek verzonden op de primaire hoofdreplica. De time to live is twee minuten en wordt periodiek om de 30 seconden verzonden. Als het primaire bestand uitvalt, wordt het rapport automatisch uit de store opgeschoond. Als de servicereplica actief is, maar deze is vastgelopen of andere problemen ondervindt, verloopt het rapport in het statusarchief. In dit geval wordt de entiteit als fout geëvalueerd.
Een andere voorwaarde die kan worden bewaakt, is de uitvoeringstijd van taken. De master distribueert taken naar de secundaire databases op basis van het taaktype. Afhankelijk van het ontwerp kan de master de secundaire bestanden voor de taakstatus peilen. Het kan ook wachten tot de secundaire secundaire bestanden bevestigingssignalen terugstuurt wanneer ze klaar zijn. In het tweede geval moet worden gezorgd voor het detecteren van situaties waarin secondaries sterven of berichten verloren gaan. Een optie is dat de master een pingaanvraag naar dezelfde secundaire aanvraag verzendt, waardoor de status ervan wordt teruggestuurd. Als er geen status wordt ontvangen, beschouwt de master deze als een fout 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 binnen een bepaalde tijd wordt uitgevoerd (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 hoofdreplica rapporteert periodiek op zichzelf. U kunt één eigenschap hebben voor alle taken die in behandeling zijn in de wachtrij. Als ten minste één taak langer duurt, is de rapportstatus van 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 het primaire element uitvalt, kan de zojuist gepromoveerde primaire blijven rapporteren.
- Een ander watchdog-proces (in de cloud of extern) controleert de taken (van buiten, op basis van het gewenste taakresultaat) om te zien of ze zijn voltooid. Als ze de drempelwaarden niet respecteren, wordt er een rapport verzonden op de hoofdservice. Er wordt ook een rapport verzonden voor elke taak die de taak-id bevat, zoals PendingTask+taskId. Rapporten mogen alleen worden verzonden op beschadigde statussen. Stel time to live in op een paar minuten en markeer de rapporten die moeten worden verwijderd wanneer ze verlopen om ervoor te zorgen dat ze worden opgeschoond.
- De secundaire die een taakrapporten uitvoert wanneer het langer duurt dan verwacht om deze uit te voeren. Het rapporteert over het service-exemplaar op de eigenschap PendingTasks. Het rapport verwijst naar het service-exemplaar dat problemen heeft, maar legt de situatie waarin het exemplaar sterft niet vast. De rapporten worden vervolgens opgeschoond. Deze kan rapporteren over de secundaire service. Als de secundaire taak is voltooid, wist de secundaire instantie het rapport uit het archief. Het rapport legt de situatie waarin het bevestigingsbericht verloren gaat niet vast en de taak is niet voltooid vanuit het oogpunt van de master.
De rapportage wordt echter uitgevoerd in de hierboven beschreven gevallen, de rapporten worden vastgelegd in de status van de toepassing wanneer de status wordt geëvalueerd.
Periodiek rapporteren versus over overgang
Met behulp van het model voor statusrapportage kunnen watchdogs periodiek of bij overgangen rapporten verzenden. De aanbevolen manier voor watchdog-rapportage is periodiek, omdat de code veel eenvoudiger en minder gevoelig is voor fouten. De watchdogs moeten ernaar streven om zo eenvoudig mogelijk fouten te voorkomen die onjuiste rapporten activeren. Onjuiste beschadigde rapporten zijn van invloed op statusevaluaties en scenario's op basis van de status, inclusief upgrades. Onjuiste rapporten met een goede status verbergen problemen in het cluster, wat niet gewenst is.
Voor periodieke rapportage kan de watchdog worden geïmplementeerd met een timer. Bij een callback van een timer 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 of om optimalisaties te maken in termen van berichten. De statusclient heeft batchverwerkingslogica om te helpen bij prestaties. Terwijl de statusclient actief blijft, wordt het 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 zorgvuldige verwerking van statussen. De watchdog bewaakt enkele 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 rapporten onderhouden, zodat ze kunnen worden geïnspecteerd om statuswijzigingen te bepalen. Bij failover moet u ervoor zorgen dat er rapporten worden toegevoegd, maar nog niet naar het statusarchief worden verzonden. Het volgnummer moet steeds groter worden. Zo niet, dan worden de rapporten geweigerd als verouderd. In zeldzame gevallen waarin gegevensverlies optreedt, kan synchronisatie nodig zijn tussen de status van de rapportgever en de status van het statusarchief.
Rapportage over overgangen is zinvol voor services die op 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 rapporter en het statusarchief. Als het rapport voor de bovenliggende partitie of bovenliggende toepassing is, moet u ervoor zorgen dat failover wordt uitgevoerd 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 entiteits- en rapportdetails duidelijk zijn, kunnen statusrapporten worden verzonden 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 waarop ze willen rapporteren. Geef het rapport aan een statusclient. U kunt ook een statusinformatie maken en 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 binnen het cluster. De watchdog controleert of een externe resource toegankelijk is 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 functioneren. Daarom wordt het rapport elke 30 seconden verzonden op 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
Statusrapporten verzenden 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, heeft de rapporter problemen, zodat het knooppunt op fout wordt geëvalueerd. Wanneer de CPU hoger is dan een drempelwaarde, heeft het rapport een waarschuwingsstatus. Wanneer de CPU langer dan de geconfigureerde tijd boven een drempelwaarde blijft, wordt deze gerapporteerd als een fout. Anders verzendt de rapportfunctie een status van 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 en vervolgens de replica-id voor de service waarin deze is geïnteresseerd, ophaalt. Vervolgens wordt een rapport vanuit PowershellWatcher verzonden op de eigenschap ResourceDependency. Het rapport is slechts twee minuten van belang en wordt automatisch uit het archief 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 in de hoofdtekst de beschrijving van het statusrapport bevatten. Zie bijvoorbeeld hoe u statusrapporten voor 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