Övervaka klustret

Det är viktigt att övervaka på klusternivå för att avgöra om maskinvaran och klustret beter sig som förväntat. Även om Service Fabric kan hålla program igång under ett maskinvarufel, men du måste fortfarande diagnostisera om ett fel inträffar i ett program eller i den underliggande infrastrukturen. Du bör också övervaka dina kluster för att bättre planera för kapacitet, vilket hjälper dig att fatta beslut om att lägga till eller ta bort maskinvara.

Service Fabric exponerar flera strukturerade plattformshändelser, som Service Fabric-händelser, via EventStore och olika loggkanaler.

I Windows är Service Fabric-händelser tillgängliga från en enda ETW-provider med en uppsättning relevanta logLevelKeywordFilters som används för att välja mellan kanaler för drift och data och meddelanden – det är så vi separerar utgående Service Fabric-händelser som ska filtreras efter behov.

• Driftåtgärder på hög nivå som utförs av Service Fabric och klustret, inklusive händelser för en nod som kommer upp, ett nytt program som distribueras eller en återställning av uppgradering osv. Se den fullständiga listan över händelser här.

• Drift – detaljerad
  Hälsorapporter och beslut om belastningsutjämning.

Du kan komma åt åtgärdskanalen på olika sätt, till exempel ETW/Windows-händelseloggar, EventStore (tillgängligt i Windows i version 6.2 och senare för Windows-kluster). EventStore ger dig åtkomst till klustrets händelser per entitet (entiteter som kluster, noder, program, tjänster, partitioner, repliker och containrar) och exponerar dem via REST-API:er och Service Fabric-klientbiblioteket. Använd EventStore för att övervaka dina dev/test-kluster och för att få en punkt-i-tid-förståelse av tillståndet för dina produktionskluster.

• Data och meddelanden
  Kritiska loggar och händelser som genereras i meddelandena (för närvarande endast ReverseProxy) och datasökvägen (tillförlitliga tjänstmodeller).

• Data och meddelanden – detaljerad
  Utförlig kanal som innehåller alla icke-kritiska loggar från data och meddelanden i klustret (den här kanalen har en stor mängd händelser).

Utöver dessa finns det två strukturerade EventSource-kanaler, samt loggar som vi samlar in för supportändamål.

• Reliable Services-händelser
  Programmeringsmodellspecifika händelser.

• Reliable Actors-händelser
  Programmeringsmodellspecifika händelser och prestandaräknare.

• Supportloggar
  Systemloggar som genereras av Service Fabric används endast av oss när vi tillhandahåller support.

Dessa olika kanaler täcker de flesta av de loggning på plattformsnivå som rekommenderas. För att förbättra loggning på plattformsnivå kan du överväga att investera i att bättre förstå hälsomodellen och lägga till anpassade hälsorapporter och lägga till anpassade prestandaräknare för att skapa en realtidstolkning av effekten av dina tjänster och program på klustret.

För att kunna dra nytta av dessa loggar rekommenderar vi starkt att du låter "Diagnostik" vara aktiverat när klustret skapas i Azure-portalen. Genom att aktivera diagnostik, när klustret distribueras, kan Azure Diagnostics bekräfta kanalerna Operational, Reliable Services och Reliable Actors och lagra data enligt beskrivningen i Aggregerade händelser med Azure Diagnostics.

Hälso- och belastningsrapportering för Azure Service Fabric

Service Fabric har en egen hälsomodell som beskrivs i detalj i följande artiklar:

• Introduktion till Hälsoövervakning av Service Fabric
• Rapportera och kontrollera hälsan hos tjänster
• Lägga till anpassade Service Fabric-hälsorapporter
• Visa Service Fabric-hälsorapporter

Hälsoövervakning är avgörande för flera aspekter av driften av en tjänst, särskilt under en programuppgradering. När varje uppgraderingsdomän för tjänsten har uppgraderats måste uppgraderingsdomänen klara hälsokontroller innan distributionen flyttas till nästa uppgraderingsdomän. Om OK-hälsostatus inte kan uppnås återställs distributionen så att programmet förblir i ett känt OK-tillstånd. Vissa kunder kan påverkas innan tjänsterna återställs, men de flesta kunder får inget problem. Dessutom sker en lösning relativt snabbt utan att behöva vänta på åtgärder från en mänsklig operatör. Ju fler hälsokontroller som ingår i koden, desto mer motståndskraftiga är din tjänst för distributionsproblem.

En annan aspekt av tjänstens hälsa är att rapportera mått från tjänsten. Mått är viktiga i Service Fabric eftersom de används för att balansera resursanvändning. Mått kan också vara en indikator på systemets hälsa. Du kan till exempel ha ett program som har många tjänster, och varje instans rapporterar ett RPS-mått (requests per second). Om en tjänst använder fler resurser än en annan tjänst flyttar Service Fabric tjänstinstanser runt klustret för att försöka upprätthålla en jämn resursanvändning. En mer detaljerad förklaring av hur resursutnyttjande fungerar finns i Hantera resursförbrukning och belastning i Service Fabric med mått.

Mått kan också hjälpa dig att ge dig insikt i hur tjänsten fungerar. Med tiden kan du använda mått för att kontrollera att tjänsten fungerar inom förväntade parametrar. Om trender till exempel visar att den genomsnittliga RPS:en är 1 000 klockan 9 på måndagsmorgonen kan du konfigurera en hälsorapport som varnar dig om RPS är under 500 eller över 1 500. Allt kan vara helt bra, men det kan vara värt en titt för att vara säker på att dina kunder har en bra upplevelse. Tjänsten kan definiera en uppsättning mått som kan rapporteras i hälsokontrollsyfte, men som inte påverkar klustrets resursbalansering. Det gör du genom att ange måttvikten till noll. Vi rekommenderar att du startar alla mått med en vikt på noll och inte ökar vikten förrän du är säker på att du förstår hur viktning av måtten påverkar resursbalansering för klustret.

All information som kan indikera programmets hälsa och prestanda är en kandidat för mått och hälsorapporter. En processorprestandaräknare kan berätta hur din nod används, men den anger inte om en viss tjänst är felfri, eftersom flera tjänster kan köras på en enda nod. Men mått som RPS, bearbetade objekt och svarstid för begäranden kan alla indikera hälsotillståndet för en specifik tjänst.

Service Fabric-stödloggar

Om du behöver kontakta Microsofts support för att få hjälp med ditt Azure Service Fabric-kluster krävs nästan alltid supportloggar. Om klustret finns i Azure konfigureras och samlas supportloggar automatiskt in som en del av skapandet av ett kluster. Loggarna lagras i ett dedikerat lagringskonto i klustrets resursgrupp. Lagringskontot har inget fast namn, men i kontot visas blobcontainrar och tabeller med namn som börjar med infrastrukturresurser. Information om hur du konfigurerar loggsamlingar för ett fristående kluster finns i Skapa och hantera ett fristående Azure Service Fabric-kluster och konfigurationsinställningar för ett fristående Windows-kluster. För fristående Service Fabric-instanser ska loggarna skickas till en lokal filresurs. Du måste ha dessa loggar för support, men de är inte avsedda att kunna användas av någon utanför Microsofts kundsupportteam.

Mäta prestanda

Mät prestanda för klustret för att hjälpa dig att förstå hur det kan hantera belastnings- och körningsbeslut kring skalning av klustret (se mer om att skala ett kluster i Azure eller lokalt). Prestandadata är också användbara jämfört med åtgärder som du eller dina program och tjänster kan ha vidtagit när du analyserar loggar i framtiden.

En lista över prestandaräknare som ska samlas in när du använder Service Fabric finns i Prestandamått

Här är två vanliga sätt att konfigurera insamling av prestandadata för klustret:

• Använda en agent
  Det här är det bästa sättet att samla in prestanda från en dator, eftersom agenter vanligtvis har en lista över möjliga prestandamått som kan samlas in, och det är en relativt enkel process att välja de mått som du vill samla in eller ändra. Läs mer om Azure Monitor som erbjuder Azure Monitor-loggar i Integrering av Azure Monitor-loggar i Service Fabric och Konfigurera Log Analytics-agenten för att lära dig mer om Log Analytics-agenten, som är en sådan övervakningsagent som kan hämta prestandadata för virtuella klusterdatorer och distribuerade containrar.

• Prestandaräknare till Azure Table Storage
  Du kan också skicka prestandamått till samma tabelllagring som händelserna. Detta kräver att du ändrar Azure Diagnostics-konfigurationen för att hämta lämpliga prestandaräknare från de virtuella datorerna i klustret och gör det möjligt för den att hämta dockerstatistik om du ska distribuera några containrar. Läs mer om att konfigurera prestandaräknare i WAD i Service Fabric för att konfigurera insamling av prestandaräknare.

Nästa steg

• Läs mer om Integrering av Azure Monitor-loggar i Service Fabric för att samla in klusterdiagnostik och skapa anpassade frågor och aviseringar
• Lär dig mer om Service Fabrics inbyggda diagnostikupplevelse, EventStore
• Gå igenom några vanliga diagnostikscenarier i Service Fabric