Lägga till anpassade hälsorapporter i Service Fabric
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 bör rapporteras på, 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 och körs i stor skala i molnet (privat eller Azure).
Service Fabric-reportrarna övervakar identifierade intressevillkor. 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 omfattande, flexibel och lätt att använda. Hälsorapporternas kvalitet avgör precisionen i klustrets hälsovy. Falska positiva identifieringar som felaktigt visar problem med fel 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 viss tanke för att tillhandahålla rapporter som fångar in intresseförhållanden på bästa möjliga sätt.
För att kunna 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 ska du besluta om hälsorapportens egenskap och hälsotillstånd.
- 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 vakthund.
- 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 med jämna mellanrum, eftersom det kräver enklare kod och är mindre felbenäget.
- Avgör 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 tid att leva och ta bort förfallobeteende.
Som nämnts kan rapportering göras från:
- Den övervakade Service Fabric-tjänstrepliken.
- Interna vakthundar som distribueras 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 som Gomez).
Kommentar
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 hälsorapporteringsdesignen är tydlig kan hälsorapporter enkelt skickas. Du kan använda FabricClient för att rapportera hälsotillstånd 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 för bättre prestanda.
Kommentar
Rapporthälsan är synkron och representerar endast valideringsarbetet på klientsidan. Det faktum att rapporten godkänns 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 infrastrukturresursklienten. 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 i 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 ett meddelande överskrider tidsgränsen försöker hälsoklienten igen tills hälsohanteraren bekräftar att rapporten har bearbetats. Standard: två minuter.
Kommentar
När rapporterna batchats måste infrastrukturresursklienten hållas vid liv för minst HealthReportSendInterval för att säkerställa att de skickas. Om meddelandet går förlorat 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.
Bufferten på klienten tar hänsyn till rapporternas unika värde. 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. Som mest finns en sådan rapport 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 du anger att 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 infrastrukturklienten, 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 hälsoklientens batchbearbetning 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 startas 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 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 batchade var 30:e sekund. Du kan ändra batchintervallet med konfigurationsinställningen HttpGatewayHealthReportSendInterval för klustret på HttpGateway. Som nämnts är ett bättre alternativ att skicka rapporterna med Immediate true.
Kommentar
För att säkerställa att obehöriga tjänster inte kan rapportera hälsotillståndet 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ågprivilegier
Om Service Fabric-tjänster inte har administratörsåtkomst till klustret kan du rapportera hälsotillstånd 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 distribueras 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.
Kommentar
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 bör 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 Immediate true. Omedelbara rapporter kringgår batchningsintervallet för den interna hälsoklienten. Som tidigare nämnts, använd 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 när det gäller att generera rapporter av hög kvalitet är att identifiera de villkor som kan påverka tjänstens hälsotillstånd. 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 när det gäller 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 vakthundsskrivare 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. Var noga med att förhindra att buggar för vakthundar påverkar tjänstfunktionerna.
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 rapporten, 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, distribuerade 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 funktionaliteten 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 finns 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 inom rimlig tid?)
När övervakningsinformationen har slutförts bör du bestämma ett käll-ID som unikt identifierar det. 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 till exempel flera resurser behöver övervakas kan egenskapsnamnet vara ShareSize-sharename.
Kommentar
Använd inte hälsoarkivet för att behålla statusinformationen. 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 rapporteras 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 huvudrepliken. Tiden att leva är två minuter och skickas med jämna mellanrum 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örningstid för aktiviteter. 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, vilket skickar tillbaka dess status. Om ingen status tas emot anser huvudservern att det är ett fel och schemalägg om aktiviteten. 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 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 uppgifterna (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 i 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. Ange 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 sedan. 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 avbildar inte den situation där bekräftelsemeddelandet går förlorat och uppgiften inte är klar från huvudvyn.
Men rapporteringen görs i de fall som beskrivs ovan, rapporterna registreras 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 som inte är felfria 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 timeråteranrop 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 rapporter 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. Vakthunden 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 noga med att lägga till rapporter, men ännu inte skickas till hälsoarkivet. Sekvensnumret måste ökas 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 även alla dess rapporter bort. Den här automatiska rensningen minskar behovet av synkronisering mellan reporter och hälsoarkiv. 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 frå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 varningstillstånd för hälsotillståndet. 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 den tjänst 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 HJÄLP av 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å 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