Lägga till anpassade Service Fabric-hälsorapporter
Azure Service Fabric introducerar en hälsomodell som är utformad för att flagga kluster- och programvillkor som inte är felfria för specifika entiteter. Hälsomodellen använder hälsoreportrar (systemkomponenter och vakthundar). Målet är enkel och snabb diagnos och reparation. Tjänstförfattare måste tänka i förväg om hälsa. Alla villkor som kan påverka hälsan ska rapporteras, särskilt om det kan hjälpa till att flagga problem nära roten. Hälsoinformationen kan spara tid och arbete med felsökning och undersökning. Användbarheten är särskilt tydlig när tjänsten är igång i stor skala i molnet (privat eller Azure).
Service Fabric-reportrar övervakar identifierade intressanta villkor. De rapporterar om dessa villkor baserat på deras lokala vy. Hälsolagret aggregerar hälsodata som skickas av alla reportrar för att avgöra om entiteter är globalt felfria. Modellen är avsedd att vara rik, flexibel och lätt att använda. Kvaliteten på hälsorapporterna avgör precisionen i klustrets hälsovy. Falska positiva identifieringar som felaktigt visar problem med feltillstånd kan påverka uppgraderingar eller andra tjänster som använder hälsodata negativt. Exempel på sådana tjänster är reparationstjänster och aviseringsmekanismer. Därför behövs en del tankar för att tillhandahålla rapporter som fångar in intressanta villkor på bästa möjliga sätt.
För att utforma och implementera hälsorapportering måste vakthundar och systemkomponenter:
- Definiera det villkor som de är intresserade av, hur det övervakas och påverkan på klustret eller programfunktionerna. Baserat på den här informationen väljer du hälsorapportegenskapen och hälsotillståndet.
- Fastställ den entitet som rapporten gäller för.
- Ta reda på var rapporteringen görs, från tjänsten eller från en intern eller extern övervakningsenhet.
- Definiera en källa som används för att identifiera reportern.
- Välj en rapporteringsstrategi, antingen regelbundet eller vid övergångar. Det rekommenderade sättet är regelbundet eftersom det kräver enklare kod och är mindre känsligt för fel.
- Fastställ hur länge rapporten för feltillstånd ska finnas kvar i hälsoarkivet och hur den ska rensas. Med hjälp av den här informationen bestämmer du rapportens time to live- och remove-on-expiration-beteende.
Som nämnts kan rapportering göras från:
- Den övervakade Service Fabric-tjänstrepliken.
- Interna vakthundar distribuerade som en Service Fabric-tjänst (till exempel en tillståndslös Service Fabric-tjänst som övervakar villkor och utfärdar rapporter). Vakthundarna kan distribueras till alla noder eller mappas till den övervakade tjänsten.
- Interna vakthundar som körs på Service Fabric-noderna men som inte implementeras som Service Fabric-tjänster.
- Externa vakthundar som avsöker resursen utanför Service Fabric-klustret (till exempel övervakningstjänsten Gomez).
Anteckning
Klustret fylls i med hälsorapporter som skickas av systemkomponenterna. Läs mer i Använda systemhälsorapporter för felsökning. Användarrapporterna måste skickas på hälsoentiteter som redan har skapats av systemet.
När designen för hälsorapportering är tydlig kan hälsorapporter enkelt skickas. Du kan använda FabricClient för att rapportera hälsa om klustret inte är säkert eller om infrastrukturresursklienten har administratörsbehörighet. Rapportering kan göras via API:et med hjälp av FabricClient.HealthManager.ReportHealth, via PowerShell eller via REST. Batchrapporter för konfigurationsknoppar ger bättre prestanda.
Anteckning
Rapportens hälsotillstånd är synkront och representerar bara valideringsarbetet på klientsidan. Det faktum att rapporten accepteras av hälsoklienten eller objekten Partition eller CodePackageActivationContext betyder inte att den tillämpas i arkivet. Den skickas asynkront och kan eventuellt batchas med andra rapporter. Bearbetningen på servern kan fortfarande misslyckas: sekvensnumret kan vara inaktuellt, entiteten som rapporten måste tillämpas på har tagits bort osv.
Hälsoklient
Hälsorapporterna skickas till hälsohanteraren via en hälsoklient som finns i infrastrukturklienten. Hälsohanteraren sparar rapporter i hälsoarkivet. Hälsoklienten kan konfigureras med följande inställningar:
- HealthReportSendInterval: Fördröjningen mellan tiden då rapporten läggs till i klienten och den tid den skickas till hälsohanteraren. Används för att batchrapportera till ett enda meddelande i stället för att skicka ett meddelande för varje rapport. Batchbearbetningen förbättrar prestandan. Standard: 30 sekunder.
- HealthReportRetrySendInterval: Intervallet då hälsoklienten skickar om ackumulerade hälsorapporter till hälsohanteraren. Standard: 30 sekunder, minst: 1 sekund.
- HealthOperationTimeout: Tidsgränsen för ett rapportmeddelande som skickas till hälsohanteraren. Om tidsgränsen uppnås för ett meddelande försöker hälsoklienten igen tills hälsohanteraren bekräftar att rapporten har bearbetats. Standard: två minuter.
Anteckning
När rapporterna batchas måste infrastrukturresursklienten hållas vid liv i minst HealthReportSendInterval för att säkerställa att de skickas. Om meddelandet försvinner eller om hälsohanteraren inte kan tillämpa dem på grund av tillfälliga fel måste infrastrukturresursklienten hållas vid liv längre för att ge den en chans att försöka igen.
Buffring på klienten tar hänsyn till det unika i rapporterna. Om en viss dålig reporter till exempel rapporterar 100 rapporter per sekund på samma egenskap för samma entitet ersätts rapporterna med den senaste versionen. Högst en sådan rapport finns i klientkön. Om batchbearbetning har konfigurerats är antalet rapporter som skickas till hälsohanteraren bara ett per sändningsintervall. Den här rapporten är den senast tillagda rapporten, som återspeglar den mest aktuella statusen för entiteten.
Ange konfigurationsparametrar när FabricClient skapas genom att skicka FabricClientSettings med önskade värden för hälsorelaterade poster.
I följande exempel skapas en infrastrukturklient och rapporterna ska skickas när de läggs till. Vid timeouter och fel som kan försökas igen görs återförsök var 40:e sekund.
var clientSettings = new FabricClientSettings()
{
HealthOperationTimeout = TimeSpan.FromSeconds(120),
HealthReportSendInterval = TimeSpan.FromSeconds(0),
HealthReportRetrySendInterval = TimeSpan.FromSeconds(40),
};
var fabricClient = new FabricClient(clientSettings);
Vi rekommenderar att du behåller standardinställningarna för fabric-klienten, som är inställda HealthReportSendInterval på 30 sekunder. Den här inställningen garanterar optimala prestanda på grund av batchbearbetning. För kritiska rapporter som måste skickas så snart som möjligt använder du HealthReportSendOptions med Immediate true i FabricClient.HealthClient.ReportHealth API. Omedelbara rapporter kringgår batchningsintervallet. Använd den här flaggan med försiktighet. Vi vill dra nytta av batchbearbetningen av hälsoklienten när det är möjligt. Omedelbar sändning är också användbart när fabric-klienten stängs (till exempel har processen fastställt ogiltigt tillstånd och måste stängas av för att förhindra biverkningar). Det säkerställer bästa möjliga sändning av de ackumulerade rapporterna. När en rapport läggs till med omedelbar flagga batchar hälsoklienten alla ackumulerade rapporter sedan den senaste sändningen.
Samma parametrar kan anges när en anslutning till ett kluster skapas via PowerShell. I följande exempel startar en anslutning till ett lokalt kluster:
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
}
På samma sätt som med API:et HealthReportSendInterval kan rapporter skickas med växeln -Immediate så att de skickas omedelbart, oavsett värde.
För REST skickas rapporterna till Service Fabric-gatewayen, som har en intern infrastrukturklient. Som standard är den här klienten konfigurerad för att skicka rapporter batchvis var 30:e sekund. Du kan ändra batchintervallet med klusterkonfigurationsinställningen HttpGatewayHealthReportSendInterval på HttpGateway. Som nämnts är ett bättre alternativ att skicka rapporterna med Immediate true.
Anteckning
För att säkerställa att obehöriga tjänster inte kan rapportera hälsa mot entiteterna i klustret konfigurerar du servern så att den endast accepterar begäranden från skyddade klienter. Den FabricClient som används för rapportering måste ha säkerhet aktiverad för att kunna kommunicera med klustret (till exempel med Kerberos eller certifikatautentisering). Läs mer om klustersäkerhet.
Rapportera inifrån lågprivilegierade tjänster
Om Service Fabric-tjänster inte har administratörsåtkomst till klustret kan du rapportera hälsotillståndet för entiteter från den aktuella kontexten via Partition eller CodePackageActivationContext.
- För tillståndslösa tjänster använder du IStatelessServicePartition.ReportInstanceHealth för att rapportera om den aktuella tjänstinstansen.
- För tillståndskänsliga tjänster använder du IStatefulServicePartition.ReportReplicaHealth för att rapportera om den aktuella repliken.
- Använd IServicePartition.ReportPartitionHealth för att rapportera om den aktuella partitionsentiteten.
- Använd CodePackageActivationContext.ReportApplicationHealth för att rapportera om det aktuella programmet.
- Använd CodePackageActivationContext.ReportDeployedApplicationHealth för att rapportera om det aktuella programmet som distribuerats på den aktuella noden.
- Använd CodePackageActivationContext.ReportDeployedServicePackageHealth för att rapportera om ett tjänstpaket för programmet som distribueras på den aktuella noden.
Anteckning
Internt Partition har och CodePackageActivationContext en hälsoklient konfigurerats med standardinställningar. Som förklaras för hälsoklienten batchas rapporter och skickas på en timer. Objekten ska hållas vid liv för att kunna skicka rapporten.
Du kan ange HealthReportSendOptions när du skickar rapporter via Partition och CodePackageActivationContext hälso-API:er. Om du har kritiska rapporter som måste skickas så snart som möjligt använder du HealthReportSendOptions med Omedelbar .true Omedelbara rapporter kringgår batchningsintervallet för den interna hälsoklienten. Som tidigare nämnts använder du den här flaggan med försiktighet. vi vill dra nytta av hälsoklientens batchbearbetning när det är möjligt.
Utforma hälsorapportering
Det första steget i att generera rapporter av hög kvalitet är att identifiera de villkor som kan påverka tjänstens hälsa. Alla villkor som kan hjälpa till att flagga problem i tjänsten eller klustret när den startar – eller ännu bättre, innan ett problem inträffar – kan potentiellt spara miljarder dollar. Fördelarna inkluderar mindre stilleståndstid, färre natttimmar som ägnas åt att undersöka och reparera problem och högre kundnöjdhet.
När villkoren har identifierats måste vakthundsförfattare ta reda på det bästa sättet att övervaka dem för balans mellan omkostnader och användbarhet. Tänk dig till exempel en tjänst som utför komplexa beräkningar som använder vissa temporära filer på en resurs. En vakthund kan övervaka resursen för att säkerställa att tillräckligt med utrymme är tillgängligt. Den kan lyssna efter meddelanden om fil- eller katalogändringar. Den kan rapportera en varning om ett starttröskelvärde nås och rapportera ett fel om resursen är full. Vid en varning kan ett reparationssystem börja rensa äldre filer på resursen. Vid ett fel kan ett reparationssystem flytta tjänstrepliken till en annan nod. Observera hur villkorstillstånden beskrivs i termer av hälsa: tillståndet för villkoret som kan anses vara felfritt (ok) eller inte felfri (varning eller fel).
När övervakningsinformationen har angetts måste en övervakningsskrivare ta reda på hur vakthunden ska implementeras. Om villkoren kan fastställas inifrån tjänsten kan vakthunden vara en del av själva den övervakade tjänsten. Tjänstkoden kan till exempel kontrollera resursanvändningen och sedan rapportera varje gång den försöker skriva en fil. Fördelen med den här metoden är att rapporteringen är enkel. Försiktighet måste vidtas för att förhindra att buggar för vakthundar påverkar tjänstens funktioner.
Rapportering inifrån den övervakade tjänsten är inte alltid ett alternativ. En vakthund i tjänsten kanske inte kan identifiera villkoren. Det kanske inte har logiken eller data för att göra bestämningen. Omkostnaderna för att övervaka förhållandena kan vara höga. Villkoren kanske inte heller är specifika för en tjänst, utan påverkar i stället interaktioner mellan tjänster. Ett annat alternativ är att ha vakthundar i klustret som separata processer. Vakthundarna övervakar villkoren och rapporterar, utan att påverka huvudtjänsterna på något sätt. Dessa vakthundar kan till exempel implementeras som tillståndslösa tjänster i samma program, distribueras på alla noder eller på samma noder som tjänsten.
Ibland är en vakthund som körs i klustret inte heller ett alternativ. Om det övervakade villkoret är tillgängligheten eller funktionen för tjänsten som användarna ser den, är det bäst att ha vakthundarna på samma plats som användarklienterna. Där kan de testa åtgärderna på samma sätt som användarna anropar dem. Du kan till exempel ha en vakthund som bor utanför klustret, skicka begäranden till tjänsten och kontrollera svarstiden och korrektheten i resultatet. (För en kalkylatortjänst returnerar till exempel 2+2 4 på en rimlig tid?)
När övervakningsinformationen har slutförts bör du bestämma ett käll-ID som unikt identifierar den. Om flera vakthundar av samma typ finns i klustret måste de rapportera om olika entiteter, eller, om de rapporterar om samma entitet, använda olika käll-ID eller egenskap. På så sätt kan deras rapporter samexistera. Egenskapen för hälsorapporten ska avbilda det övervakade villkoret. (I exemplet ovan kan egenskapen vara ShareSize.) Om flera rapporter gäller för samma villkor bör egenskapen innehålla viss dynamisk information som gör att rapporter kan samexistera. Om flera resurser till exempel behöver övervakas kan egenskapsnamnet vara ShareSize-sharename.
Anteckning
Använd inte hälsoarkivet för att behålla statusinformation. Endast hälsorelaterad information ska rapporteras som hälsa, eftersom den här informationen påverkar hälsoutvärderingen av en entitet. Hälsoarkivet har inte utformats som ett allmänt arkiv. Den använder logik för hälsoutvärdering för att aggregera alla data till hälsotillståndet. Att skicka information som inte är relaterad till hälsa (till exempel rapporteringsstatus med hälsotillståndet OK) påverkar inte det aggregerade hälsotillståndet, men det kan påverka hälsoarkivets prestanda negativt.
Nästa beslutspunkt är vilken entitet som ska rapporteras. För det mesta identifierar villkoret entiteten tydligt. Välj entiteten med bästa möjliga kornighet. Om ett villkor påverkar alla repliker i en partition rapporterar du på partitionen, inte på tjänsten. Det finns dock hörnfall där mer eftertanke behövs. Om villkoret påverkar en entitet, till exempel en replik, men önskan är att villkoret ska flaggas för mer än repliktidens varaktighet, bör det rapporteras på partitionen. Annars rensar hälsoarkivet alla sina rapporter när repliken tas bort. Vakthundsförfattare måste tänka på entitetens och rapportens livslängd. Det måste vara tydligt när en rapport ska rensas från ett arkiv (till exempel när ett fel som rapporterats på en entitet inte längre gäller).
Låt oss titta på ett exempel som sammanställer de punkter som jag beskrev. Överväg att ett Service Fabric-program består av en huvudtillståndskänslig beständig tjänst och sekundära tillståndslösa tjänster som distribueras på alla noder (en sekundär tjänsttyp för varje typ av uppgift). Huvudservern har en bearbetningskö som innehåller kommandon som ska köras av sekundärfiler. Sekundärfilerna kör inkommande begäranden och skickar tillbaka bekräftelsesignaler. Ett villkor som kan övervakas är längden på huvudbearbetningskön. Om huvudkölängden når ett tröskelvärde rapporteras en varning. Varningen anger att sekundärfilerna inte kan hantera belastningen. Om kön når den maximala längden och kommandona tas bort rapporteras ett fel eftersom tjänsten inte kan återställas. Rapporterna kan finnas i egenskapen QueueStatus. Vakthunden finns i tjänsten och skickas regelbundet på den primära primära repliken. Tiden att leva är två minuter och skickas regelbundet var 30:e sekund. Om den primära går ned rensas rapporten automatiskt från arkivet. Om tjänstrepliken är igång, men den är låst eller har andra problem, upphör rapporten att gälla i hälsoarkivet. I det här fallet utvärderas entiteten vid fel.
Ett annat villkor som kan övervakas är körningstiden för aktiviteten. Huvudservern distribuerar aktiviteter till sekundärfilerna baserat på aktivitetstypen. Beroende på designen kan huvudservern avsöka sekundärfilerna efter uppgiftsstatus. Det kan också vänta på att sekundärerna skickar tillbaka bekräftelsesignaler när de är klara. I det andra fallet måste man vara noga med att identifiera situationer där sekundärfiler dör eller meddelanden går förlorade. Ett alternativ är att huvudservern skickar en ping-begäran till samma sekundära, som skickar tillbaka dess status. Om ingen status tas emot anser huvudservern att det är ett fel och schemalägg om uppgiften. Det här beteendet förutsätter att aktiviteterna är idempotenta.
Det övervakade villkoret kan översättas som en varning om aktiviteten inte utförs under en viss tid (t1, till exempel 10 minuter). Om aktiviteten inte har slutförts i tid (t2, till exempel 20 minuter), kan det övervakade villkoret översättas som Fel. Den här rapporteringen kan göras på flera olika sätt:
- Huvudrepliken rapporterar om sig själv med jämna mellanrum. Du kan ha en egenskap för alla väntande aktiviteter i kön. Om minst en aktivitet tar längre tid är rapportstatusen för egenskapen PendingTasks en varning eller ett fel, beroende på vad som är lämpligt. Om det inte finns några väntande aktiviteter eller om alla aktiviteter har startats är rapportstatusen OK. Uppgifterna är beständiga. Om den primära går ned kan den nyligen upphöjda primära rapporten fortsätta att rapporteras korrekt.
- En annan övervakningsprocess (i molnet eller externt) kontrollerar aktiviteterna (utifrån, baserat på önskat aktivitetsresultat) för att se om de har slutförts. Om de inte respekterar tröskelvärdena skickas en rapport på huvudtjänsten. En rapport skickas också för varje aktivitet som innehåller aktivitetsidentifieraren, till exempel PendingTask+taskId. Rapporter bör endast skickas i feltillstånd. Ställ in tid till live till några minuter och markera de rapporter som ska tas bort när de upphör att gälla för att säkerställa rensning.
- Den sekundära som kör en aktivitet rapporterar när det tar längre tid än förväntat att köra den. Den rapporterar om tjänstinstansen på egenskapen PendingTasks. Rapporten identifierar tjänstinstansen som har problem, men den fångar inte upp situationen där instansen dör. Rapporterna rensas då. Den kan rapportera om den sekundära tjänsten. Om den sekundära slutför uppgiften rensar den sekundära instansen rapporten från arkivet. Rapporten registrerar inte den situation där bekräftelsemeddelandet går förlorat och uppgiften inte är klar från huvudsidans synvinkel.
Men rapporteringen görs i de fall som beskrivs ovan, rapporterna samlas in i programmets hälsa när hälsan utvärderas.
Rapportera regelbundet jämfört med vid övergång
Med hjälp av hälsorapporteringsmodellen kan vakthundar skicka rapporter regelbundet eller vid övergångar. Det rekommenderade sättet för övervakningsrapportering är med jämna mellanrum, eftersom koden är mycket enklare och mindre felbenägen. Vakthundarna måste sträva efter att vara så enkla som möjligt för att undvika buggar som utlöser felaktiga rapporter. Felaktiga rapporter med feltillstånd påverkar hälsoutvärderingar och scenarier baserat på hälsa, inklusive uppgraderingar. Felaktiga felfria rapporter döljer problem i klustret, vilket inte är önskvärt.
För regelbunden rapportering kan vakthunden implementeras med en timer. Vid ett timeranrop kan vakthunden kontrollera tillståndet och skicka en rapport baserat på det aktuella tillståndet. Du behöver inte se vilken rapport som skickades tidigare eller göra några optimeringar när det gäller meddelanden. Hälsoklienten har batchlogik som hjälper till med prestanda. Även om hälsoklienten hålls vid liv försöker den internt tills rapporten bekräftas av hälsoarkivet eller vakthunden genererar en nyare rapport med samma entitet, egenskap och källa.
Rapportering om övergångar kräver noggrann hantering av tillstånd. Vakthunden övervakar vissa villkor och rapporterar endast när villkoren ändras. Fördelen med den här metoden är att färre rapporter behövs. Nackdelen är att logiken i vakthunden är komplex. Övervakningsenheten måste underhålla villkoren eller rapporterna så att de kan inspekteras för att fastställa tillståndsändringar. Vid redundansväxling måste du vara försiktig med rapporter som har lagts till, men som ännu inte har skickats till hälsoarkivet. Sekvensnumret måste öka ständigt. Annars avvisas rapporterna som inaktuella. I de sällsynta fall där dataförlust uppstår kan synkronisering behövas mellan reporterns tillstånd och hälsotillståndet för hälsoarkivet.
Rapportering om övergångar är meningsfullt för tjänster som rapporterar om sig själva, via Partition eller CodePackageActivationContext. När det lokala objektet (replik eller distribuerat tjänstpaket/distribuerat program) tas bort tas även alla dess rapporter bort. Den här automatiska rensningen gör det lätt att synkronisera reportern och hälsoarkivet. Om rapporten gäller överordnad partition eller överordnat program måste du vara försiktig vid redundans för att undvika inaktuella rapporter i hälsoarkivet. Logik måste läggas till för att upprätthålla rätt tillstånd och rensa rapporten från arkivet när den inte behövs längre.
Implementera hälsorapportering
När entiteten och rapportinformationen är tydliga kan du skicka hälsorapporter via API: et, PowerShell eller REST.
API
Om du vill rapportera via API:et måste du skapa en hälsorapport som är specifik för den entitetstyp som de vill rapportera om. Ge rapporten till en hälsoklient. Du kan också skapa en hälsoinformation och skicka den till rätt rapporteringsmetoder för Partition eller CodePackageActivationContext för att rapportera om aktuella entiteter.
I följande exempel visas periodisk rapportering från en vakthund i klustret. Vakthunden kontrollerar om en extern resurs kan nås inifrån en nod. Resursen behövs av ett tjänstmanifest i programmet. Om resursen inte är tillgänglig kan de andra tjänsterna i programmet fortfarande fungera korrekt. Därför skickas rapporten på den distribuerade tjänstpaketentiteten var 30:e sekund.
private static Uri ApplicationName = new Uri("fabric:/WordCount");
private static string ServiceManifestName = "WordCount.Service";
private static string NodeName = FabricRuntime.GetNodeContext().NodeName;
private static Timer ReportTimer = new Timer(new TimerCallback(SendReport), null, 30 * 1000, 30 * 1000);
private static FabricClient Client = new FabricClient(new FabricClientSettings() { HealthReportSendInterval = TimeSpan.FromSeconds(0) });
public static void SendReport(object obj)
{
// Test whether the resource can be accessed from the node
HealthState healthState = this.TestConnectivityToExternalResource();
// Send report on deployed service package, as the connectivity is needed by the specific service manifest
// and can be different on different nodes
var deployedServicePackageHealthReport = new DeployedServicePackageHealthReport(
ApplicationName,
ServiceManifestName,
NodeName,
new HealthInformation("ExternalSourceWatcher", "Connectivity", healthState));
// TODO: handle exception. Code omitted for snippet brevity.
// Possible exceptions: FabricException with error codes
// FabricHealthStaleReport (non-retryable, the report is already queued on the health client),
// FabricHealthMaxReportsReached (retryable; user should retry with exponential delay until the report is accepted).
Client.HealthManager.ReportHealth(deployedServicePackageHealthReport);
}
PowerShell
Skicka hälsorapporter med Send-ServiceFabricEntityTypeHealthReport.
I följande exempel visas regelbunden rapportering om CPU-värden på en nod. Rapporterna ska skickas var 30:e sekund och de har en tid att leva på två minuter. Om de upphör att gälla har reportern problem, så noden utvärderas vid fel. När processorn överskrider ett tröskelvärde har rapporten ett hälsotillstånd för varningen. När processorn ligger över ett tröskelvärde under mer än den konfigurerade tiden rapporteras den som ett fel. Annars skickar reportern hälsotillståndet 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
I följande exempel rapporterar vi en tillfällig varning på en replik. Den hämtar först partitions-ID:t och sedan replik-ID:t för tjänsten som den är intresserad av. Den skickar sedan en rapport från PowershellWatcher på egenskapen ResourceDependency. Rapporten är av intresse i bara två minuter och tas bort från arkivet automatiskt.
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
Skicka hälsorapporter med REST med POST-begäranden som går till önskad entitet och har i brödtexten beskrivningen av hälsorapporten. Se till exempel hur du skickar REST-klusterhälsorapporter eller tjänsthälsorapporter. Alla entiteter stöds.
Nästa steg
Baserat på hälsodata kan tjänstförfattare och kluster-/programadministratörer tänka på olika sätt att använda informationen. De kan till exempel konfigurera aviseringar baserat på hälsostatus för att fånga upp allvarliga problem innan de orsakar avbrott. Administratörer kan också konfigurera reparationssystem för att åtgärda problem automatiskt.
Introduktion till Hälsoövervakning av Service Fabric
Visa Service Fabric-hälsorapporter
Så här rapporterar och kontrollerar du tjänstens hälsa
Använda systemhälsorapporter för felsökning