Övervakning och diagnostik för Azure Service Fabric

  • Artikel
  • 8 minuter för att läsa

Den här artikeln innehåller en översikt över övervakning och diagnostik för Azure Service Fabric. Övervakning och diagnostik är avgörande för att utveckla, testa och distribuera arbetsbelastningar i alla molnmiljöer. Du kan till exempel spåra hur dina program används, vilka åtgärder som vidtas av Service Fabric-plattformen, din resursanvändning med prestandaräknare och klustrets övergripande hälsa. Du kan använda den här informationen för att diagnostisera och åtgärda problem och förhindra att de inträffar i framtiden. I följande avsnitt går vi kortfattat igenom varje område Service Fabric som du bör överväga för produktionsarbetsbelastningar.

Anteckning

Den här artikeln har nyligen uppdaterats för användning av term Azure Monitors loggar i stället för Log Analytics. Loggdata lagras fortfarande i en Log Analytics arbets yta och samlas in och analyseras fortfarande av samma Log Analytics-tjänst. Vi uppdaterar terminologin för att bättre avspegla rollen för loggar i Azure Monitor. Se Azure Monitor terminologis ändringar för mer information.

Programövervakning

Programövervakning spårar hur funktioner och komponenter i ditt program används. Du vill övervaka dina program för att se till att problem som påverkar användarna fångas upp. Ansvaret för programövervakning ligger på användarna som utvecklar ett program och dess tjänster eftersom det är unikt för programmets affärslogik. Det kan vara användbart att övervaka dina program i följande scenarier:

  • Hur mycket trafik upplever mitt program? – Behöver du skala dina tjänster för att uppfylla användarnas krav eller hantera en potentiell flaskhals i ditt program?
  • Lyckas och spåras mina tjänst-till-tjänst-anrop?
  • Vilka åtgärder vidtas av mina programanvändare? – Insamling av telemetri kan vägleda framtida funktionsutveckling och bättre diagnostik för programfel
  • Utlös mitt program ohanterade undantag?
  • Vad händer i de tjänster som körs i mina containrar?

Det som är bra med programövervakning är att utvecklare kan använda vilka verktyg och ramverk de vill eftersom de finns inom ramen för ditt program! Du kan lära dig mer om Azure-lösningen för programövervakning med Azure Monitor – programövervakning Insights händelseanalys med Application Insights. Vi har också en självstudiekurs om hur du ställer in detta för .NET-program. I den här självstudien går vi igenom hur du installerar rätt verktyg, ett exempel på hur du skriver anpassad telemetri i ditt program och visar programdiagnostik och telemetri i Azure Portal.

Plattformsövervakning (kluster)

En användare har kontroll över vilken telemetri som kommer från programmet eftersom en användare skriver själva koden, men hur är det med diagnostiken från Service Fabric plattformen? Ett av Service Fabric mål är att hålla program motståndskraftiga mot maskinvarufel. Det här målet uppnås genom plattformens systemtjänsters möjlighet att identifiera infrastrukturproblem och snabbt redundansvätera arbetsbelastningar till andra noder i klustret. Men i det här specifika fallet, vad händer om själva systemtjänsterna har problem? Eller om regler för placering av tjänster överträds vid försök att distribuera eller flytta en arbetsbelastning? Service Fabric innehåller diagnostik för dessa och mycket mer för att se till att du informeras om aktiviteten som äger rum i klustret. Några exempelscenarier för klusterövervakning är:

Service Fabric innehåller en omfattande uppsättning händelser. Dessa Service Fabric händelser kan nås via EventStore eller driftkanalen (händelsekanal som exponeras av plattformen).

  • Service Fabric händelsekanaler – På Windows är Service Fabric-händelser tillgängliga från en enda ETW-provider med en uppsättning relevanta som används för att välja mellan kanaler för drift- och &-meddelanden – det är på det här sättet som vi separerar utgående Service Fabric-händelser som ska filtreras efter logLevelKeywordFilters behov. I Linux Service Fabric händelser via LTTng och läggs i en Storage tabell, där de kan filtreras efter behov. Dessa kanaler innehåller curated, structured events (strukturerade händelser) som kan användas för att bättre förstå klustrets tillstånd. Diagnostik är aktiverat som standard när klustret skapas, vilket skapar en Azure Storage tabell där händelserna från dessa kanaler skickas så att du kan köra frågor mot dem i framtiden.

  • EventStore – EventStore är en funktion som erbjuds av plattformen som tillhandahåller Service Fabric plattformshändelser som är tillgängliga i Service Fabric Explorer och via REST API. Du kan se en ögonblicksbild av vad som händer i klustret för varje entitet, till exempel nod, tjänst, program och fråga baserat på tidpunkten för händelsen. Du kan också Läsa mer om EventStore i Översikt över EventStore.

Skärmbild som visar fliken HÄNDELSER i fönstret Noder flera händelser, inklusive en NodeDown-händelse.

Den diagnostik som tillhandahålls är i form av en omfattande uppsättning händelser. Dessa Service Fabric händelser illustrerar åtgärder som utförs av plattformen på olika entiteter, till exempel noder, program, tjänster, partitioner osv. I det sista scenariot ovan, om en nod skulle gå ned, skulle plattformen generera en händelse och du kan meddelas omedelbart av det NodeDown övervakningsverktyg du väljer. Andra vanliga exempel är ApplicationUpgradeRollbackStarted eller PartitionReconfigured under en redundans. Samma händelser är tillgängliga i både Windows- och Linux-kluster.

Händelserna skickas via standardkanaler på både Windows och Linux och kan läsas av alla övervakningsverktyg som stöder dessa. Lösningen Azure Monitor är Azure Monitor loggar. Läs gärna mer om integreringen av Azure Monitor loggar som innehåller en anpassad instrumentpanel för klustret och några exempelfrågor som du kan skapa aviseringar från. Fler klusterövervakningsbegrepp är tillgängliga på plattformsnivå för händelse- och logggenerering.

Hälsoövervakning

Plattformen Service Fabric innehåller en hälsomodell som ger utökningsbar hälsorapportering för status för entiteter i ett kluster. Varje nod, program, tjänst, partition, replik eller instans har en kontinuerligt uppdaterbar hälsostatus. Hälsostatusen kan antingen vara "OK", "Varning" eller "Fel". Tänk på Service Fabric händelser som verb som görs av klustret till olika entiteter och hälsa som ett adjektiv för varje entitet. Varje gång hälsotillståndet för en viss entitet övergår genereras även en händelse. På så sätt kan du konfigurera frågor och aviseringar för hälsohändelser i val av övervakningsverktyg, precis som andra händelser.

Dessutom låter vi även användare åsidosätta hälsotillståndet för entiteter. Om programmet uppgraderas och valideringstesterna misslyckas kan du skriva till Service Fabric Health med hjälp av hälso-API:et för att indikera att programmet inte längre är felfritt och Service Fabric kommer automatiskt att återställa uppgraderingen! Mer information om hälsomodellen finns i introduktionen till Service Fabric hälsoövervakning

SFX-hälsoinstrumentpanel

Vakthundar

I allmänhet är en watchdog en separat tjänst som bevakar hälsa och belastning över tjänster, pingar slutpunkter och rapporterar oväntade hälsohändelser i klustret. Detta kan förhindra fel som kanske inte identifieras baserat på prestanda för en enskild tjänst. Watchdogs är också en bra plats för att vara värd för kod som utför åtgärder som inte kräver användarinteraktion, till exempel att rensa loggfiler i lagringen vid vissa tidsintervall. Om du vill ha en fullständigt implementerad SF watchdog-tjänst med öppen källkod som innehåller en lättanvänd watchdog-utökningsmodell och som körs i både Windows- och Linux-kluster kan du gå till FabricObserver-projektet. FabricObserver är produktionsklar programvara. Vi rekommenderar att du distribuerar FabricObserver till dina test- och produktionskluster och utökar den för att uppfylla dina behov, antingen via dess plugin-modell eller genom att förmana den och skriva egna inbyggda observationer. Den tidigare metoden (plugin-program) är den rekommenderade metoden.

Infrastrukturövervakning (prestanda)

Nu när vi har gått in på diagnostiken i ditt program och på plattformen, hur vet vi att maskinvaran fungerar som förväntat? Övervakning av den underliggande infrastrukturen är en viktig del av att förstå tillståndet för klustret och resursanvändningen. Mätning av systemets prestanda beror på många faktorer som kan vara subjektiva beroende på dina arbetsbelastningar. Dessa faktorer mäts vanligtvis via prestandaräknare. Dessa prestandaräknare kan komma från en mängd olika källor, inklusive operativsystemet, .NET Framework eller själva Service Fabric plattformen. Några scenarier där de skulle vara användbara är

  • Använder jag maskinvaran effektivt? Vill du använda maskinvaran med 90 % CPU eller 10 % CPU. Detta är praktiskt när du skalar klustret eller optimerar programmets processer.
  • Kan jag förutsäga infrastrukturproblem proaktivt? – många problem föregås av plötsliga förändringar (sjunker) i prestanda, så du kan använda prestandaräknare som nätverks-I/O och CPU-användning för att förutsäga och diagnostisera problemen proaktivt.

En lista över prestandaräknare som ska samlas in på infrastrukturnivå finns i Prestandamått.

Service Fabric tillhandahåller också en uppsättning prestandaräknare för programmeringsmodellerna Reliable Services och Aktörer. Om du använder någon av dessa modeller kan de här prestandaräknarna information för att säkerställa att dina aktörer snurrar upp och ned korrekt, eller att dina tillförlitliga tjänstbegäranden hanteras tillräckligt snabbt. Mer information finns i Monitoring for Reliable Service Remoting and Performance monitoring for Reliable Actors.

Lösningen Azure Monitor att samla in dessa är Azure Monitor loggar precis som övervakning på plattformsnivå. Du bör använda Log Analytics-agenten för att samla in lämpliga prestandaräknare och visa dem i Azure Monitor loggar.

Nu när vi har gått igenom varje område för övervakning och exempelscenarier finns här en sammanfattning av Azure-övervakningsverktygen och den nödvändiga uppsättningen för att övervaka alla områden ovan.

Du kan också använda och ändra ARM-exempelmallen som finns här för att automatisera distributionen av alla nödvändiga resurser och agenter.

Andra loggningslösningar

Även om de två lösningar som vi rekommenderar har Azure Monitor-loggar och Application Insights inbyggd integrering med Service Fabric, men många händelser skrivs ut via ETW-providers och kan utökas med andra loggningslösningar. Du bör också titta på Elastic Stack (särskilt om du överväger att köra ett kluster i en offlinemiljö), Dynatraceeller någon annan plattform som du föredrar. Vi har en lista över integrerade partner som är tillgängliga här.

Viktiga punkter för alla plattformar du väljer bör omfatta hur bekväm du är med användargränssnittet, frågefunktionerna, de anpassade visualiseringar och instrumentpaneler som är tillgängliga och de ytterligare verktyg som de tillhandahåller för att förbättra din övervakningsupplevelse.

Nästa steg