Metodtips för övervakning och diagnostik

Distribuerade program och tjänster som körs i molnet är komplexa programvarudelar som består av många rörliga delar. I en produktionsmiljö är det viktigt att spåra hur kunder använder systemet, spåra resursutnyttjande och övervaka systemets hälsa och prestanda. Du kan använda den här informationen för att identifiera och korrigera problem och för att fånga upp potentiella problem innan de inträffar.

Scenarier för övervakning och diagnostik

Du kan använda övervakning för att få insikt i hur väl ett system fungerar. Övervakning är en viktig del av upprätthållandet av tjänstkvalitetsmål (QoS). Samla in övervakningsdata för följande vanliga scenarier:

• Se till att systemet förblir felfritt.

• Spåra tillgängligheten för systemet och dess komponenter.

• Underhåll prestanda för att säkerställa att systemets dataflöde inte försämras oväntat när arbetsvolymen ökar.

• Garantera att systemet uppfyller serviceavtal (SLA).

• Skydda systemets, användarnas och deras datas integritet och säkerhet.

• Spåra revisions- eller regelefterlevnadsåtgärder.

• Övervaka den dagliga användningen av systemet och åtgärda trender som kan leda till problem.

• Spåra problem som uppstår, från den första rapporten till analys av möjliga orsaker, korrigering, programuppdateringar och distribution.

• Spåra operationer och felsök programvarureleaser.

I följande avsnitt beskrivs dessa scenarier mer detaljerat.

Hälsoövervakning

Ett felfritt system körs och kan bearbeta begäranden. Använd hälsoövervakning för att generera en ögonblicksbild av systemets aktuella hälsotillstånd så att du kan kontrollera att alla komponenter fungerar som förväntat.

Konfigurera aviseringar

Systemet bör generera en avisering inom några sekunder om någon del inte är felfri. Aviseringar kan markera systemets hälsa via trafikljussignaler:

• Rött för ohälsosamt tillstånd (systemet har stannat)
• Gult för delvis felfri (systemet körs med nedsatt funktionalitet)
• Grön för felfri

Ett omfattande hälsoövervakningssystem visar hälsotillståndet för varje undersystem och komponent så att du kan avgöra vilka delar som fungerar normalt och vilka delar som har problem.

Samla in hälsodata

Följande källor kan generera de rådata som krävs för hälsoövervakning:

• Spåra exekveringen av användarförfrågningar. Du kan använda den här informationen för att avgöra vilka begäranden som lyckas eller misslyckas och för att mäta hur lång tid varje begäran tar.

• Övervaka syntetiska användare. Den här processen simulerar de åtgärder som en användare utför och följer en fördefinierad serie steg. Samla in resultatet av varje steg.

• Logga undantag, fel och varningar. Du kan samla in den här informationen från spårningsinstruktioner som är inbäddade i programkoden och från händelseloggarna för tjänster som systemet refererar till.

• Övervaka hälsotillståndet för icke-Microsoft-tjänster som systemet använder. Du kan behöva hämta och parsa hälsodata som dessa tjänster tillhandahåller.

• Övervaka slutpunkter.

• Samla in information om omgivande prestanda, till exempel cpu-användning i bakgrunden eller I/O-åtgärder (input/output), inklusive nätverksaktivitet.

Analysera hälsodata

Det primära fokuset för hälsoövervakning är att snabbt ange om systemet körs. Snabb analys av omedelbara data kan utlösa en avisering om en kritisk komponent inte är felfri.

Ett mer avancerat system kan innehålla ett förutsägande element som utför en kall analys över de senaste och aktuella arbetsbelastningarna. En kall analys kan identifiera trender och avgöra om systemet sannolikt kommer att förbli hälsosamt eller behöver fler resurser. Basera det här förutsägande elementet på följande kritiska prestandamått:

• Frekvens för begäranden som riktas till varje tjänst eller undersystem
• Svarstiderna för dessa begäranden
• Mängden data som flödar in i och ut ur varje tjänst

Om värdet för något mått överskrider ett definierat tröskelvärde kan systemet skapa en avisering för att skala upp. Du kan också lägga till resurser, starta om tjänster som misslyckas eller begränsa begäranden med lägre prioritet för att upprätthålla systemets hälsa.

Tillgänglighetsövervakning

I ett felfritt system är alla komponenter och undersystem tillgängliga. Tillgänglighetsövervakning är nära relaterat till hälsoövervakning. Hälsoövervakning ger en omedelbar vy över systemets aktuella hälsotillstånd. Tillgänglighetsövervakning spårar tillgängligheten för systemet och dess komponenter för att generera statistik om drifttid.

I många system konfigureras vissa komponenter, till exempel databaser, med inbyggd redundans för att möjliggöra snabb redundans om ett allvarligt fel eller en anslutning går förlorad. Samla in så mycket information som möjligt om dessa fel för att fastställa orsaken och vidta korrigerande åtgärder för att förhindra upprepning.

Vilka data som krävs för att spåra tillgängligheten kan bero på flera faktorer på lägre nivå som kan vara specifika för programmet, systemet och miljön. Ett effektivt övervakningssystem samlar in tillgänglighetsdata som motsvarar dessa lågnivåfaktorer och aggregerar dem sedan för att ge en övergripande bild av systemet. I ett e-handelssystem kan till exempel de affärsfunktioner som gör det möjligt för en kund att göra beställningar bero på den lagringsplats som lagrar orderinformation och det betalningssystem som hanterar monetära transaktioner. Tillgängligheten för beställningsplaceringsfunktionen beror på tillgängligheten för lagringsplatsen och betalningsundersystemet.

Tillgänglighetsövervakningslösningen innehåller aktuella och historiska vyer över tillgänglighetsstatusen för varje undersystem. Den varnar dig snabbt när en eller flera tjänster misslyckas eller när användarna inte kan ansluta till tjänster. Använd den här informationen för att identifiera trender som kan orsaka att undersystem misslyckas. Du kan till exempel använda tillgänglighetsdata för att identifiera vilka tjänster som misslyckas under bearbetningstimmar med hög belastning.

Samla in tillgänglighetsdata

Övervaka syntetiska användare, logga undantag, fel och varningar och övervaka slutpunkter för att generera rådata som krävs för tillgänglighetsövervakning. Applikationen kan exponera en eller flera hälsoändpunkter som var och en testar åtkomst till ett funktionsområde i systemet. Övervakningssystemet följer ett definierat schema för att pinga varje slutpunkt och samla in resultaten, till exempel lyckades eller misslyckades.

Registrera alla timeout-händelser, fel i nätverksanslutningen och försök till återanslutning, och tidsstämpla all data.

Analysera tillgänglighetsdata

Aggregera och korrelera data för att stödja följande typer av analys:

• Systemets och undersystemens omedelbara tillgänglighet.

• Tillgänglighetsfelfrekvensen för systemet och undersystemen. Korrelera fel med specifika aktiviteter för att förstå orsakerna till systemfel.

• En historisk vy över felfrekvenser under en angiven period och belastningen på systemet, till exempel antalet användarbegäranden, när ett fel inträffar.

• Orsakerna till att systemet eller undersystemen inte är tillgängliga. Dessa orsaker är att tjänsten inte körs, förlorad anslutning, tidsgränser eller felkodssvar.

Du kan beräkna den procentuella tillgängligheten för en tjänst under en viss tidsperiod med hjälp av följande formel:

%Availability =  ((Total Time – Total Downtime) / Total Time ) * 100

Använd den här formeln för SLA-övervakning. Definitionen av stilleståndstid beror på tjänsten. Till exempel definierar Azure DevOps build-tjänsten stilleståndstid som perioden, totalt ackumulerade minuter, under vilken byggtjänsten inte är tillgänglig. Tjänsten anses vara otillgänglig i en minut om alla kontinuerliga HTTP-begäranden under den minuten resulterar i en felkod eller inte returnerar något svar.

Prestandaövervakning

När antalet användare ökar ökar storleken på de datauppsättningar som användarna har åtkomst till och risken för fel på en eller flera komponenter blir mer sannolik. Prestandaförsämring inträffar ofta före komponentfel. Om du kan identifiera försämring kan du vidta proaktiva åtgärder för att förhindra fel.

Systemprestanda beror på flera faktorer. Du mäter vanligtvis varje faktor via nyckelprestandaindikatorer (KPI:er), till exempel antalet databastransaktioner per sekund eller volymen av nätverksbegäranden som har betjänats inom en angiven tidsram. Vissa av dessa KPI:er kan vara tillgängliga som specifika prestandamått, medan andra KPI:er kan härledas från en kombination av mått.

Krav för prestandaövervakning

För att utvärdera systemprestanda behöver du vanligtvis följande information:

• Svarsfrekvensen för användarbegäranden
• Antalet samtidiga användarbegäranden
• Volymen av nätverkstrafik
• De priser med vilka systemet slutför affärstransaktioner
• Den genomsnittliga bearbetningstiden för begäranden

Använd verktyg som kan hjälpa dig att identifiera följande korrelationer:

• Antalet samtidiga användare jämfört med svarstider för begäranden, eller hur lång tid det tar att börja bearbeta en begäran efter att användaren har skickat den

• Antalet samtidiga användare jämfört med den genomsnittliga svarstiden eller hur lång tid det tar att slutföra en begäran när den har börjat bearbetas

• Mängden begäranden jämfört med antalet bearbetningsfel

Tillsammans med den här funktionella informationen på hög nivå får du en detaljerad vy över prestanda för varje komponent i systemet. Prestandaräknare på låg nivå tillhandahåller vanligtvis dessa data. De spårar följande information:

• Minnesanvändning
• Antal trådar
• Processorbearbetningstid
• Längd på begärandekö
• Disk- eller nätverks-I/O-hastigheter och -fel
• Antal byte som skrivits eller lästs
• Mellanprogramsindikatorer, till exempel kölängd

Med alla visualiseringar kan du ange en tidsperiod. De data som visas kan vara en ögonblicksbild av den aktuella situationen eller en historisk vy över prestandan. Systemet bör generera aviseringar baserat på eventuella prestandamätningar för ett angivet värde under ett angivet tidsintervall.

Insamla prestandadata

Samla in prestandadata på hög nivå, till exempel dataflöde, antalet samtidiga användare, antalet affärstransaktioner och felfrekvenser genom att övervaka förloppet för användarnas begäranden. Införliva spårningsinstruktioner och tidsinformation vid viktiga punkter i programkoden. Samla in alla fel, undantag och varningar med tillräckligt med data och korrelera dem med de begäranden som orsakade dem.

Samla om möjligt in prestandadata för alla externa system som programmet använder. Dessa externa system kan tillhandahålla egna prestandaräknare eller andra funktioner för att begära prestandadata. Om den här metoden inte är möjlig, registrera information som start- och sluttid för varje begäran till ett externt system samt om åtgärden lyckades, misslyckades eller gav en varning.

Prestandadata på låg nivå för enskilda komponenter i ett system kan vara tillgängliga via funktioner och tjänster, till exempel Windows prestandaräknare som Azure Monitor Agent samlar in.

Analysera prestandainformation

De flesta analyser aggregerar prestandadata efter typ av användarbegäran eller av det undersystem eller den tjänst som varje begäran skickas till. Ett exempel på en användarbegäran är att lägga till ett objekt i en kundvagn eller kassaprocessen i ett e-handelssystem.

Ett annat vanligt krav är att sammanfatta prestandadata i percentiler. Du kan till exempel fastställa svarstiderna för 99% begäranden, 95% begäranden och 70% begäranden. Du kan ange SLA-mål eller andra mål för varje percentil. Rapportera pågående resultat i nära realtid för att identifiera problem omedelbart. Sammanställa resultat över tid för statistiska ändamål.

Problem med svarstid kan också påverka prestanda. För att snabbt identifiera orsaken till flaskhalsar utvärderar du svarstiden för varje steg som varje begäran utför. Prestandadata måste vara ett sätt att korrelera prestandamått för varje steg för att associera dem med en specifik begäran.

Beroende på dina visualiseringskrav kan det vara användbart att generera och lagra en datakub som innehåller vyer av rådata. Den här datakuben kan tillåta komplexa, oplanerade frågor och analys av prestandainformation.

Säkerhetsövervakning

Alla kommersiella system som innehåller känsliga data måste implementera en säkerhetsstruktur. Datakänsligheten avgör vanligtvis hur komplex säkerhetsmekanismen är. I ett system som kräver att användare autentiseras registrerar du följande information:

• Alla inloggningsförsök och om de misslyckas eller lyckas

• Alla åtgärder som utförs av en autentiserad användare och information om alla resurser som de har åtkomst till

• När en användare avslutar en session och loggar ut

Övervakning kan hjälpa till att identifiera attacker på systemet. Flera misslyckade inloggningsförsök kan till exempel tyda på en brute-force-attack. En oväntad ökning av begäranden kan bero på en DDoS-attack. Var beredd på att övervaka alla begäranden till alla resurser oavsett källa. Ett system som har en inloggningsrisk kan oavsiktligt exponera resurser utan att en användare behöver logga in.

Krav för säkerhetsövervakning

De data som säkerhetsövervakningen samlar in kan hjälpa dig:

• Identifiera intrångsförsök av en oautentiserad entitet.

• Identifiera försök av entiteter att utföra åtgärder på data som de inte har åtkomst till.

• Avgör om en oautentiserad användare eller en obehörig autentiserad användare försöker attackera systemet.

För att stödja dessa uppgifter bör systemet skicka aviseringar om:

• Ett konto gör upprepade misslyckade inloggningsförsök inom en angiven period.

• Ett autentiserat konto försöker upprepade gånger komma åt en förbjuden resurs under en angiven period.

• Ett stort antal oautentiserade eller obehöriga begäranden sker under en angiven period.

Konfigurera aviseringar för att inkludera källans värdadress för varje begäran. Om säkerhetsöverträdelser regelbundet inträffar från ett visst adressintervall kan du blockera dessa värdar.

En viktig del av att upprätthålla säkerheten i ett system är möjligheten att snabbt identifiera åtgärder som avviker från det vanliga mönstret. Du kan visa information som antalet misslyckade eller lyckade inloggningsbegäranden visuellt för att identifiera aktivitetstoppar vid ovanliga tidpunkter. Du kan också använda den här informationen för att konfigurera tidsbaserad autoskalning. Om du till exempel ser att många användare regelbundet loggar in vid en viss tidpunkt kan du starta extra autentiseringstjänster för att hantera arbetsvolymen. Stäng av dessa tjänster när toppen har passerat.

Samla in säkerhetsdata

Säkerhet är en heltäckande aspekt av de flesta distribuerade system, och övervakning genererar relevanta data på flera punkter i hela systemet. Anta en SIEM-metod (Security Information and Event Management) för att samla in information som är resultatet av händelser som genereras av programmet, nätverksutrustning, servrar, brandväggar, antivirusprogram och andra intrångsskyddselement.

Säkerhetsövervakning kan innehålla data från verktyg utanför programmet. Dessa verktyg omfattar verktyg som identifierar portgenomsökningsaktiviteter av externa byråer och nätverksfilter som identifierar försök att få oautentiserad åtkomst till ditt program och dina data. I vissa fall utgör distributionsverktyget för kontinuerlig integrering och kontinuerlig leverans (CI/CD) en viktig del av programmets livscykel. Dessa verktyg bör också flagga avvikande beteende.

Analysera säkerhetsdata

En viktig funktion i säkerhetsövervakningen är att den samlar in data från många källor. De olika formaten och detaljnivåerna kräver ofta komplex analys för att kompilera data i en sammanhängande informationstråd. Du kan identifiera misslyckade inloggningar eller upprepade försök att få obehörig åtkomst till resurser, men komplex automatiserad bearbetning av säkerhetsdata kanske inte är möjlig. I det här scenariot måste du tidsstämpla data och skriva dem till en säker lagringsplats i dess ursprungliga form för manuell expertanalys.

SLA-övervakning

Kommersiella system som stöder betalande kunder gör åtaganden om systemprestanda i form av serviceavtal. Serviceavtal anger att systemet kan hantera en definierad arbetsvolym inom en överenskommen tidsram och utan att förlora viktig information. SLA-övervakning säkerställer att systemet uppfyller mätbara serviceavtal.

Följande mått definierar serviceavtal:

• Övergripande systemtillgänglighet. En organisation kan till exempel åta sig att systemet är tillgängligt 99,9 % av tiden. Den här procentandelen motsvarar högst nio timmars stilleståndstid per år, eller cirka 10 minuter per vecka.

• Operativ genomflöde. Den här aspekten uttrycks ofta som en eller flera högvattenmärken, till exempel ett åtagande om att systemet kan stödja upp till 100 000 samtidiga användarbegäranden eller hantera 10 000 samtidiga affärstransaktioner.

• Driftsvarstid. Systemet kan också behöva bearbeta begäranden med en definierad hastighet. Till exempel måste 99% av alla affärstransaktioner slutföras inom 2 sekunder och ingen enskild transaktion tar längre tid än 10 sekunder.

Krav för SLA-övervakning

Du bör snabbt kunna avgöra om systemet uppfyller ett serviceavtal. Om det inte uppfyller serviceavtalet måste du utvärdera de underliggande faktorerna för att hitta orsaken till undermåliga prestanda.

Du kan visa följande indikatorer på hög nivå visuellt:

• Procentandelen drifttid för tjänsten

• Programmets dataflöde, mätt i termer av lyckade transaktioner eller åtgärder per sekund

• Antalet lyckade eller misslyckade programbegäranden

• Antalet program- och systemfel, undantag och varningar

Se till att du kan filtrera alla dessa indikatorer efter en angiven tidsperiod.

Ditt molnprogram består troligen av flera undersystem och komponenter. Du bör kunna välja en indikator på hög nivå, till exempel övergripande systemupptid, och avgöra vilka underliggande element som påverkar dess hälsostatus.

I aviseringssyfte bör systemet skapa en händelse om någon av indikatorerna på hög nivå överskrider ett angivet tröskelvärde. Gör informationen på lägre nivå tillgänglig för aviseringssystemet som kontextuella data.

Samla in SLA-data

Vidta följande åtgärder för att samla in rådata som krävs för SLA-övervakning:

• Utför slutpunktsövervakning.
• Logga undantag, fel och varningar.
• Spåra exekveringen av användarförfrågningar.
• Övervaka tillgängligheten för alla icke-Microsoft-tjänster som systemet använder.
• Använd prestandamått och räknare.

Alla data måste ha en tidtagningsfunktion och vara tidsstämplade.

Analysera SLA-data

Aggregera SLA-data för att generera en bild av systemets övergripande prestanda. Du bör också kunna öka detaljnivån för aggregerade data för att utvärdera underliggande undersystem. Du bör till exempel kunna utföra följande uppgifter:

• Beräkna det totala antalet användarbegäranden under en angiven period och fastställa lyckade och misslyckade begäranden.

• Kombinera svarstiderna för användarbegäranden för att generera en övergripande vy över systemets svarstider.

• Analysera förloppet för användarbegäranden för att dela upp den totala svarstiden i svarstiderna för enskilda arbetsobjekt i begäran.

• Fastställa systemets övergripande tillgänglighet i procent av drifttiden under en viss period.

• Analysera procentandelen tidstillgänglighet för de enskilda komponenterna och tjänsterna i systemet. Du kan behöva tolka loggar som genereras av tjänster som inte kommer från Microsoft.

Kommersiella system måste rapportera verkliga prestandasiffror mot serviceavtal för en angiven period. Du kan använda den här informationen för att beräkna krediter eller andra former av återbetalningar för kunder om du inte uppfyller serviceavtalen under den perioden. Du kan beräkna tillgängligheten för en tjänst med hjälp av den teknik som beskrivs i Analysera tillgänglighetsdata.

I interna syften kan en organisation också spåra antalet och typen av incidenter som gör att tjänsterna misslyckas. Lär dig hur du löser dessa problem snabbt eller eliminerar dem så att du kan minska stilleståndstiden och uppfylla serviceavtal.

Auditing

Beroende på programmets art kan juridiska föreskrifter ange krav för granskning av användarnas åtgärder och registrering av all dataåtkomst. Granskning kan ge bevis som länkar kunder till specifika begäranden. Nonrepudiation är en viktig faktor i elektroniska affärssystem för att upprätthålla förtroendet mellan en kund och den organisation som ansvarar för programmet eller tjänsten.

Krav för granskning

Du måste kunna spåra den sekvens av affärsåtgärder som användarna utför så att du kan rekonstruera användarnas åtgärder. Den här uppgiften kan vara nödvändig i dokumentationssyfte eller som en del av en forensisk undersökning.

Granskningsinformationen är mycket känslig. Den innehåller troligen data som identifierar systemanvändare och de uppgifter som de utför. Därför är granskningsinformation sannolikt endast tillgänglig för betrodda analytiker, snarare än som en del av ett interaktivt system. Analytikern genererar ett antal rapporter som följande exempel:

• Rapporter som visar alla användares aktiviteter under en angiven tidsram

• Rapporter som beskriver aktivitetskronologin för en enskild användare

• Rapporter som visar sekvensen med åtgärder som utförs mot en eller flera resurser

Samla in granskningsdata

De primära informationskällorna för granskning är:

• Det säkerhetssystem som hanterar användarautentisering.
• Spåra loggar som registrerar användaraktivitet.
• Säkerhetsloggar som spårar alla identifierbara och oidentifierbara nätverksbegäranden.

Regelkrav kan fastställa formatet på granskningsdata och hur du lagrar dem. Om reglerna kräver att du registrerar data i dess ursprungliga format kanske du inte kan rensa data. Därför måste åtkomsten till lagringsplatsen som lagrar den skyddas noggrant för att förhindra manipulering.

Analysera granskningsdata

Du måste kunna komma åt rådata i sin helhet och i dess ursprungliga form. Förutom kravet på att generera vanliga granskningsrapporter är verktygen för att analysera dessa data sannolikt specialiserade och hålls utanför systemet.

Övervakning av användning

Användningsövervakning spårar hur kunder använder ett programs funktioner och komponenter. Du kan använda data för att:

• Identifiera populära funktioner och potentiella hotspots i systemet. Högtrafikelement kan dra nytta av funktionell partitionering eller replikering för att sprida belastningen jämnare. Du kan också använda den här informationen för att avgöra vilka funktioner som används sällan och är möjliga kandidater för pensionering eller ersättning i en framtida version av systemet.

• Hämta information om drifthändelserna i systemet under normal användning. På en e-handelswebbplats kan du till exempel registrera statistisk information om antalet transaktioner och mängden kunder som ansvarar för dem. Du kan använda den här informationen för kapacitetsplanering när antalet kunder växer.

• Identifiera användarnöjdhet med systemets prestanda och funktioner. Om till exempel många kunder i ett e-handelssystem regelbundet överger sina kundvagnar kan det uppstå problem med kassafunktionen.

• Generera faktureringsinformation. Ett kommersiellt program eller en tjänst för flera klientorganisationer kan debitera kunderna för de resurser som de använder.

• Framtvinga kvoter. Om en användare i ett flerklientsystem överskrider sin betalda kvot för bearbetningstid eller resursanvändning under en angiven period, kan du begränsa användarens åtkomst eller strypa bearbetningen.

• Identifiera problem med bullriga grannar. För att underlätta felundersökningar eller produktbeslut kan du avgöra om trafiken är jämnt spridd eller om en liten uppsättning användare genererar det mesta av trafiken. Om en enskild användare genererar betydande trafik kan funktionen behöva prestandajustering. Du kan också välja att införa extra kvoter för att minska trafiken.

Krav för användningsövervakning

För att utvärdera systemanvändningen behöver du vanligtvis följande information:

• Antalet begäranden som varje undersystem bearbetar och dirigerar till varje resurs

• Det arbete som varje användare utför

• Mängden datalagring som varje användare upptar

• De resurser som varje användare kommer åt

Du bör också kunna generera grafer. Vanliga exempel är diagram över användare som använder mest resurser och de resurser eller systemfunktioner som används oftast.

Samla in användningsdata

Du kan utföra högnivåanvändningsspårning genom att notera start- och sluttiderna för varje begäran och typen av varje begäran, till exempel läsning eller skrivning. Gör följande för att samla in den här informationen:

• Spåra användaraktivitet.
• Samla in prestandaräknare som mäter användningen för varje resurs.
• Övervaka varje användares resursförbrukning.

I avläsningssyfte måste du också identifiera vilka användare som utför vilka åtgärder och vilka resurser som dessa åtgärder använder. Se till att den information du samlar in är tillräckligt detaljerad för att stödja korrekt fakturering.

Problemspårning

Kunder och andra användare kan rapportera problem om oväntade händelser eller beteenden inträffar i systemet. Problemspårning hanterar dessa problem, associerar problem med arbetet med att åtgärda dem och informerar kunderna om lösningar.

Krav för problemspårning

Om du vill spåra problem använder du ett separat system där du kan registrera och rapportera information om problem som användarna rapporterar. Den här informationen omfattar försök till uppgifter, problemsymptom, händelsesekvens och fel- eller varningsmeddelanden.

Samla in problemspårningsdata

Den första datakällan för problemspårningsdata är den användare som rapporterar problemet. Den här användaren kanske kan ange följande information:

• En kraschdump om programmet innehåller en komponent som körs på användarens skrivbord

• En ögonblicksbild av skärmen

• Datum och tid då felet inträffade och annan miljöinformation, till exempel användarens plats

Använd den här informationen för att hjälpa dig att felsöka systemet och skapa en backlogg för framtida programvaruversioner.

Analysera problemspårningsdata

Olika användare kan rapportera samma problem och systemet för problemspårning bör associera vanliga rapporter.

Registrera förloppet för felsökningsinsatsen mot varje rapport. När du löser problemet bör du informera kunden om lösningen.

Om en användare rapporterar ett problem som har en känd lösning i systemet för problemspårning kan du informera användaren om lösningen omedelbart.

Spårningsåtgärder och felsökning av programvaruversioner

När en användare rapporterar ett problem är de vanligtvis bara medvetna om den omedelbara effekt det har på deras åtgärder. Användaren kan bara rapportera resultatet av sin egen upplevelse. Dessa upplevelser är vanligtvis ett synligt symptom på ett eller flera grundläggande problem. I många fall måste en analytiker analysera kronologin för de underliggande åtgärderna för att fastställa problemets rotorsak. Den här processen kallas rotorsaksanalys (RCA).

Krav för spårning och felsökning

För att spåra oväntade händelser och andra problem måste övervakningsdata tillhandahålla tillräckligt med information för att en analytiker ska kunna hitta problemets ursprung och rekonstruera händelsesekvensen. Sedan kan en utvecklare göra ändringar för att förhindra att problemet uppstår igen.

Samla in spårnings- och felsökningsdata

Om du vill felsöka kan du spåra alla metoder och deras parametrar som anropas som en del av en åtgärd. Skapa sedan ett träd som visar det logiska flödet genom systemet när en kund gör en specifik begäran. Samla in och logga undantag och varningar som systemet genererar som ett resultat av det här flödet.

För att stödja felsökning tillhandahåller systemet krokar som du kan använda för att samla in tillståndsinformation vid viktiga punkter i systemet. Eller så kan systemet tillhandahålla detaljerad steg-för-steg-information allteftersom valda operationer fortskrider. Insamling av data på den här detaljnivån kan öka belastningen på systemet och bör vara en tillfällig process. Använd den här processen när ovanliga och svåra att replikera händelser inträffar eller när en ny version kräver noggrann övervakning för att säkerställa att elementen fungerar som förväntat.

Pipelinen för övervakning och diagnostik

Det kan vara en stor utmaning att övervaka ett stort distribuerat system. Du bör inte nödvändigtvis betrakta var och en av scenarierna som beskrivs i föregående avsnitt isolerat. Övervaknings- och diagnostikdata som krävs för varje situation överlappar varandra, men du kan behöva bearbeta och presentera dessa data på olika sätt. Ta därför en helhetssyn på övervakning och diagnostik.

Du kan föreställa dig hela övervaknings- och diagnostikprocessen som en pipeline som består av de steg som visas i följande diagram.

Diagrammet visar hur övervaknings- och diagnostikdata kommer från olika källor. Instrumenterings- och insamlingsstegen hjälper dig att identifiera de data som du behöver samla in, var och hur du avbildar dem och hur du formaterar data så att du enkelt kan analysera dem. Analys- och diagnossteget tar rådata och använder dem för att generera meningsfull information som du kan använda för att fastställa systemets tillstånd. Du kan använda den här informationen för att avgöra vilka möjliga åtgärder som ska utföras och sedan mata tillbaka resultaten till instrumentations- och insamlingsstegen. Visualiserings- och larmsteget ger en lättöverskådlig vy av systemets tillstånd. Den kan visa information nästan i realtid med hjälp av en serie instrumentpaneler. Den kan generera rapporter, diagram och diagram för att ge en historisk vy över data som kan hjälpa dig att identifiera långsiktiga trender. Om information anger att en KPI sannolikt överskrider acceptabla gränser kan det här steget också utlösa en avisering. I vissa fall kan en avisering också utlösa en automatiserad process som försöker vidta korrigerande åtgärder, till exempel automatisk skalning.

De här stegen utgör en process för kontinuerligt flöde där faserna körs parallellt. Helst bör alla faser vara dynamiskt konfigurerbara. I vissa fall, särskilt när ett system nyligen har distribuerats eller har problem, kan du behöva samla in utökade data oftare. Vid andra tillfällen kan du fortsätta att samla in viktig information på hög nivå för att kontrollera att systemet fungerar korrekt.

Behandla hela övervakningsprocessen som en aktiv, pågående lösning som behöver finjusteras och förbättras baserat på feedback. Du kan till exempel börja med att mäta många faktorer för att fastställa systemets hälsa och förfina din analys över tid för att ta bort mått som inte är relevanta.

Källor för övervakning och diagnostikdata

Den information som används i övervakningsprocessen kan komma från flera källor. På programnivå kommer information från spårningsloggar som du införlivar i systemkoden. Utvecklare bör följa en standardmetod för att spåra kontrollflödet via sin kod. En post till en metod kan till exempel generera ett spårningsmeddelande som anger namnet på metoden, aktuell tid, värdet för varje parameter och annan relevant information. Du kanske också vill registrera in- och avslutstiderna.

Logga alla undantag och varningar och se till att du behåller en fullständig spårning av kapslade undantag och varningar. Samla in information som identifierar den användare som kör kod- och aktivitetskorrelationsinformationen för att spåra begäranden när de passerar genom systemet. Loggen försöker komma åt alla resurser, till exempel meddelandeköer, databaser, filer och andra beroende tjänster. Du kan använda den här informationen i mätnings- och granskningssyfte.

Många program använder bibliotek och ramverk för att utföra vanliga uppgifter som att komma åt ett datalager eller kommunicera via ett nätverk. Du kanske kan konfigurera dessa ramverk för att tillhandahålla egna spårningsmeddelanden och rå diagnostikinformation, till exempel transaktionshastigheter och lyckade och misslyckade dataöverföringar.

Operativsystemet som programmet körs på kan vara en källa till information på låg nivå, systemomfattande information, till exempel prestandaräknare som anger I/O-priser, minnesanvändning och CPU-användning. Det kan också rapportera operativsystemfel, till exempel att det inte gick att öppna en fil korrekt.

Tänk också på den underliggande infrastrukturen och komponenterna som systemet körs på. Virtuella datorer, virtuella nätverk och lagringstjänster kan alla vara källor till viktiga prestandaräknare på infrastrukturnivå och andra diagnostikdata.

Om ditt program använder andra externa tjänster, till exempel en webbserver eller databashanteringssystem (DBMS), kan dessa tjänster publicera sin egen spårningsinformation, loggar och prestandaräknare. Till exempel dynamiska hanteringsvyer (DMV:er) i SQL Server spåra åtgärder som utförs mot en SQL Server databas. Application Insights spårar loggar för inspelning av begäranden som görs till Azure App Service.

När du ändrar systemkomponenter och distribuerar nya versioner är det viktigt att du kan tillskriva problem, händelser och mått till varje version. Associera den här informationen med versionspipelinen så att du snabbt kan spåra och åtgärda problem med en specifik version av en komponent.

Använd följande strategier för att samla in övervaknings- och diagnostikdata:

• Program- och systemövervakning använder interna källor inom programmet, programramverk, operativsystem och infrastruktur. Programkoden kan generera egna övervakningsdata vid viktiga punkter under livscykeln för en klientbegäran. Programmet kan innehålla spårningsinstruktioner som du kan aktivera och inaktivera efter behov. Du kan också mata in diagnostik dynamiskt med hjälp av ett diagnostikramverk. Dessa ramverk tillhandahåller vanligtvis plugin-program som ansluter till olika instrumentationspunkter i koden och samlar in spårningsdata vid dessa tidpunkter.

  Din kod eller den underliggande infrastrukturen kan också generera händelser vid kritiska punkter. Övervakningsagenter som har konfigurerats för att lyssna efter dessa händelser kan registrera händelseinformationen.

• Verklig användarövervakning registrerar interaktionerna mellan en användare och programmet och observerar flödet för varje begäran och svar. Använd den här informationen för att mäta varje användares användning och avgöra om användarna får en lämplig QoS, inklusive snabba svarstider, låg svarstid och minimala fel. Du kan använda data för att identifiera områden där fel inträffar oftast. Du kan också använda data för att identifiera områden där systemet saktar ner på grund av hotspots i programmet eller andra flaskhalsar. Om du implementerar den här metoden noggrant kanske du kan rekonstruera användarnas flöden via programmet i felsöknings- och testsyfte.

  Important

  Behandla data som samlas in av verklig användarövervakning som mycket känsliga eftersom de kan innehålla konfidentiellt material. Om du sparar insamlade data lagrar du dem på ett säkert sätt. Om du vill använda data för prestandaövervakning eller felsökning tar du först bort alla personuppgifter.

• Syntetisk användarövervakning kräver att du skriver en egen testklient som simulerar en användare och utför en konfigurerbar men typisk serie åtgärder. Du kan spåra testklientens prestanda för att avgöra systemets tillstånd. Du kan också använda flera instanser av testklienten som en del av en belastningstestningsåtgärd för att fastställa hur systemet svarar under stress och de övervakningsutdata som dessa villkor genererar.

  Note

  Du kan implementera verklig och syntetisk användarövervakning genom att inkludera kod som spårar och gånger körningen av metodanrop och andra viktiga delar av ett program.

• Profilering hjälper dig att övervaka och förbättra programmets prestanda. Till skillnad från verklig användarövervakning och syntetisk användarövervakning, som fungerar på funktionsnivå, samlar profilering in information på lägre nivå när programmet körs. Implementera profilering genom att regelbundet sampla körningstillståndet för ett program eller genom att avgöra vilken kod som programmet kör vid en viss tidpunkt. Du kan också använda instrumentering som infogar sonder i koden vid viktiga punkter, till exempel i början och slutet av ett metodanrop. Proberna registrerar vilka metoder som anropet anropade, vid vilken tidpunkt detta skedde och hur lång tid varje anrop tar. Du kan sedan analysera dessa data för att avgöra vilka delar av programmet som kan orsaka prestandaproblem.

• Slutpunktsövervakning använder en eller flera diagnostikslutpunkter som programmet exponerar specifikt för att aktivera övervakning. En slutpunkt ger en väg in i programkoden och kan returnera information om systemets hälsotillstånd. Olika slutpunkter kan fokusera på olika aspekter av funktionerna. Du kan skriva en egen diagnostikklient som skickar regelbundna begäranden till dessa slutpunkter och assimilerar svaren. Mer information finns i mönstret Hälsoslutpunktsövervakning.

• Användarfelsdumpar är beroende av att programmet tillhandahåller ett sätt att ta en ögonblicksbild av programmets tillstånd om det inte kan återhämta sig. Användarna måste också frivilligt dela ögonblicksbilden. Du kan inte garantera att en feldump skapas, men du kan använda de lågnivådata som den tillhandahåller för att fastställa grundorsaken till fel. Det här scenariot är vanligt om felen inträffar sällan eller om fel endast inträffar i en programfunktion som används sällan.

För maximal täckning bör du använda en kombination av dessa tekniker.

Instrumentera ett program

Instrumentation är en viktig del av övervakningsprocessen. Du måste samla in data som hjälper dig att fatta meningsfulla beslut om systemets prestanda och hälsa. Använd instrumentation för att samla in tillräckligt med information för att utvärdera prestanda, diagnostisera problem och fatta beslut utan att logga in på en fjärrproduktionsserver för att spåra och felsöka manuellt. Instrumentationsdata består vanligtvis av mått och information som skrivits till spårningsloggar.

En spårningslogg kan innehålla textdata som programmet skriver eller binära data som en spårningshändelse skapar, om programmet använder händelsespårning för Windows (ETW). Systemloggar som registrerar händelser som inträffar från delar av infrastrukturen, till exempel en webbserver, kan också generera spårningslogginnehåll. Textloggmeddelanden är ofta läsbara för människor, men skriv dem i ett format som ett automatiserat system också enkelt kan parsa.

Kategorisera även loggar. Skriv inte alla spårningsdata till en enda logg. Använd separata loggar för att registrera spårningsutdata från olika driftsaspekter i systemet. Du kan sedan snabbt filtrera loggmeddelanden genom att läsa från lämplig logg i stället för att bearbeta en enda lång fil. Skriv aldrig information som har olika säkerhetskrav, till exempel granskningsinformation och felsökning av data, till samma logg.

Mått är vanligtvis ett mått eller antal av någon aspekt eller resurs i systemet vid en viss tidpunkt, med en eller flera associerade taggar eller dimensioner, även kallat ett exempel. En enskild instans av ett mått är inte användbar isolerat. Samla i stället in mått över tid. Tänk på vilka mått som ska registreras och hur ofta. Att generera data för mått för ofta kan lägga för mycket belastning på systemet. Men om du inte samlar in tillräckligt med data kan det leda till att du missar de omständigheter som leder till en betydande händelse. Övervägandena varierar från mått till mått. Processoranvändningen på en server kan till exempel variera från sekund till sekund, men hög användning blir bara ett problem om den kvarstår i flera minuter.

Information för korrelering av data

Du kan enkelt övervaka enskilda prestandaräknare på systemnivå, samla in mått för resurser och hämta programspårningsinformation från olika loggfiler. Men vissa former av övervakning kräver analys- och diagnostikfasen i övervakningspipelinen för att korrelera data som hämtats från flera källor. Dessa rådata kan ha flera former och analysprocessen måste ha tillräckligt med instrumentationsdata för att kunna mappa dessa olika formulär. På programramverksnivå kan till exempel ett tråd-ID identifiera en uppgift. I ett program kan samma arbete associeras med användar-ID:t för den användare som utför den uppgiften.

En en-till-en-mappning finns troligen inte mellan trådar och användarbegäranden eftersom asynkrona åtgärder kan återanvända samma trådar för att utföra åtgärder för fler än en användare. Mer än en tråd kan också hantera en och samma begäran allteftersom exekveringen fortskrider genom systemet. Associera om möjligt varje begäran med ett unikt aktivitets-ID som sprids via systemet som en del av begärandekontexten. Tekniken för att generera och inkludera aktivitets-ID i spårningsinformation beror på vilken teknik du använder för att samla in spårningsdata.

Tidsstämpla all övervakningsdata på samma sätt. För konsekvens registrerar du alla datum och tider med hjälp av UTC. Den här metoden hjälper dig att enklare spåra sekvenser av händelser.

Information som ska ingå i instrumentationsdata

Tänk på följande när du bestämmer vilka instrumentationsdata som ska samlas in:

• Se till att information som samlas in av spårningshändelser är maskinläsbar och läsbar för människor. Anta väldefinierade scheman för den här informationen för att underlätta automatisk bearbetning av loggdata mellan system och för att ge konsekvens till den drifts- och ingenjörspersonal som läser loggarna. Inkludera miljöinformation, till exempel distributionsmiljön, den dator där processen körs, information om processen och anropsstacken.

• Aktivera profilering endast när det behövs eftersom det kan lägga till betydande omkostnader i systemet. Profilering med hjälp av instrumentation registrerar en händelse, till exempel ett metodanrop, varje gång den inträffar, medan sampling endast registrerar valda händelser. Urvalet kan vara tidsbaserat, en gång var n:e sekund, eller frekvensbaserat, en gång var n:e förfrågan. Om händelser inträffar ofta kan profilering efter instrumentation orsaka för mycket av en börda och påverka den övergripande prestandan. I det här fallet är samplingsmetoden att föredra. Men om händelsefrekvensen är låg kan sampling missa dem. I det här fallet kan instrumentering vara den bättre metoden.

• Ge tillräcklig kontext så att en utvecklare eller administratör kan fastställa källan för varje begäran. Den här kontexten kan innehålla ett aktivitets-ID som identifierar en specifik instans av en begäran eller information som korrelerar en aktivitet med det beräkningsarbete som utförts och de resurser som används. Det här arbetet kan korsa process- och datorgränser. För mätning bör kontexten även innehålla, antingen direkt eller indirekt via annan korrelerad information, en referens till den kund som skickar begäran. Den här kontexten ger värdefull information om programtillståndet när du samlar in övervakningsdata.

• Registrera alla begäranden och de platser eller regioner från vilka dessa begäranden görs. Den här informationen kan hjälpa dig att avgöra om det finns platsspecifika hotspots. Det kan också hjälpa dig att avgöra om du vill partitionera om ett program eller de data som det använder.

• Registrera och samla in information om undantag noggrant. Ofta går viktig felsökningsinformation förlorad på grund av dålig undantagshantering. Samla in fullständig information om undantag som programmet genererar, inklusive eventuella inre undantag och annan kontextinformation. Inkludera anropsstacken om möjligt.

• Var konsekvent i de data som de olika elementen i programmet samlar in. Konsekvens kan hjälpa dig att analysera händelser och korrelera dem med användarbegäranden. Överväg att använda ett omfattande och konfigurerbart loggningspaket för att samla in information i stället för att beroende på utvecklare använda samma metod som de implementerar olika delar av systemet. Samla in data från viktiga prestandaräknare, till exempel I/O-volym, nätverksanvändning, antal begäranden, minnesanvändning och CPU-användning. Vissa infrastrukturtjänster kan tillhandahålla sina egna prestandaräknare, till exempel antalet anslutningar till en databas, den hastighet med vilken systemet utför transaktioner och antalet transaktioner som lyckas eller misslyckas. Program kan också definiera sina egna specifika prestandaräknare.

• Logga alla anrop som görs till externa tjänster, till exempel databassystem, webbtjänster eller andra tjänster på systemnivå som ingår i infrastrukturen. Registrera information om den tid det tar att utföra varje anrop och om anropet lyckas eller misslyckas. Samla om möjligt in information om alla återförsök och fel vid tillfälliga fel som inträffar.

Säkerställa kompatibilitet med telemetrisystem

I många fall genereras den information som instrumentationen producerar som en serie händelser och skickas till ett separat telemetrisystem för bearbetning och analys. Ett telemetrisystem är vanligtvis oberoende av specifika program eller tekniker, men det förväntar sig att information följer ett specifikt format som definieras av ett schema. Schemat anger ett kontrakt som definierar de datafält och typer som telemetrisystemet kan mata in. Generalisera schemat för att tillåta data från en rad olika plattformar och enheter. Ett exempel på ett allmänt använt ramverk och schema är OpenTelemetry.

Ett vanligt schema bör innehålla fält som alla instrumentationshändelser har gemensamt, till exempel händelsenamnet, händelsetiden, avsändarens IP-adress. Den bör också innehålla den information som krävs för att korrelera med andra händelser, till exempel ett användar-ID, ett enhets-ID och ett program-ID. Kom ihåg att valfritt antal enheter kan generera händelser, så schemat bör inte vara beroende av enhetstypen. Dessutom kan olika enheter generera händelser för samma program, och programmet kan ha stöd för roaming eller någon annan form av distribution mellan enheter.

Schemat kan också innehålla domänfält som är relevanta för ett visst scenario som är gemensamt för olika program. Dessa scenarier omfattar information om undantag, programstart- och sluthändelser samt lyckade eller misslyckade API-anrop för webbtjänster. Alla program som använder samma uppsättning domänfält bör generera samma uppsättning händelser för att skapa en uppsättning vanliga rapporter och analyser.

Slutligen kan ett schema innehålla anpassade fält för att samla in information om programspecifika händelser.

Metodtips för instrumentering av program

I följande lista sammanfattas metodtips för instrumentering av ett distribuerat program som körs i molnet:

• Gör loggarna lätta att läsa och parsa. Använd strukturerad loggning där det är möjligt. Var kortfattad och beskrivande i loggmeddelanden.

• I alla loggar identifierar du källan och anger sammanhangs- och tidsinformation när varje loggpost skrivs.

• Använd samma tidszon och format för alla tidsstämplar. Den här metoden hjälper till att korrelera händelser för åtgärder som omfattar maskinvara och tjänster som körs i olika geografiska regioner.

• Kategorisera loggar och skriv meddelanden till lämplig loggfil.

• Lämna inte ut känslig information om systemet eller personlig information om användare. Rensa den här informationen innan du loggar den, men se till att du behåller relevant information. Ta till exempel bort ID och lösenord från databasanslutningssträngar. Skriv den återstående informationen till loggen så att du kan avgöra om systemet har åtkomst till rätt databas. Logga alla kritiska undantag, men tillåt administratören att aktivera och inaktivera loggning för lägre nivåer av undantag och varningar. Samla också in och logga all logikinformation för återförsök. Du kan använda dessa data för att övervaka systemets tillfälliga hälsa.

• Spåra out-of-process-anrop, till exempel begäranden till externa webbtjänster eller databaser.

• Blanda inte loggmeddelanden med olika säkerhetskrav i samma loggfil. Skriv till exempel inte felsöknings- och granskningsinformation till samma logg.

• Initiera loggningsanrop som fortsätter att fungera autonomt. Dessa typer av åtgärder blockerar inte förloppet för affärsåtgärder. Granskningshändelser är ett undantag eftersom de är viktiga för verksamheten. Klassificera dem som en grundläggande del av verksamheten.

• Se till att loggningen är utökningsbar och inte har några direkta beroenden för ett konkret mål. I stället för att till exempel skriva information med hjälp av System.Diagnostics.Trace definierar du ett abstrakt gränssnitt, till exempel ILogger, som exponerar loggningsmetoder och som du kan implementera på alla lämpliga sätt.

• Kontrollera att all loggning är felsäker och aldrig utlöser sammanhängande fel. Loggning får inte generera några undantag.

• Behandla instrumentation som en pågående iterativ process och granska loggar regelbundet, inte bara när ett problem uppstår.

Samla in och lagra data

Samlingssteget hämtar den information som instrumentation genererar, formaterar dessa data för att göra det enklare att använda under analys- och diagnosfasen och sparar transformerade data i tillförlitlig lagring. Du kan lagra instrumentationsdata som du samlar in från olika delar av ett distribuerat system på olika platser och format. Programkoden kan till exempel generera spårningsloggfiler och programhändelseloggdata. Andra tekniker kan samla in prestandaräknare som övervakar viktiga aspekter av infrastrukturen som programmet använder. Alla icke-Microsoft komponenter och tjänster som ditt program använder kan ge instrumentationsinformation i olika format med hjälp av separata spårningsfiler, bloblagring eller till och med ett anpassat datalager.

En insamlingstjänst som körs fristående från applikationen som genererar instrumentationsdata samlar vanligtvis in dessa data. Följande diagram visar ett exempel på denna arkitektur och lyfter fram instrumenterings- och datainsamlingsdelsystemet.

Det här diagrammet visar en förenklad vy över datainsamling. Samlingstjänsten består vanligtvis av många delar som körs på olika datorer. Om du behöver analysera telemetridata snabbt använder du lokala komponenter som fungerar utanför insamlingstjänsten. Efter analysbearbetningen skickar komponenterna resultatet direkt till delsystemet visualisering och avisering. Data som är föremål för varm eller kall analys lagras medan de väntar på bearbetning. Mer information finns i Stöd för het, ljummen och kall analys.

För Azure program och tjänster som körs på virtuella datorer tillhandahåller Azure Monitor-agenten en lösning för att samla in data. Du definierar regler för datainsamling (DCR) som anger vilka data som ska samlas in från varje beräkningsnod och den Log Analytics arbetsytan i Azure Monitor att skicka dem till. Agenten kan samla in data från följande källor:

• IIS-loggar (Internet Information Services)
• Windows händelseloggar
• Prestandaräknare
• Syslog från Linux-noder
• Text- och JSON-loggar som program skriver

Strategier för insamling av instrumentationsdata

På grund av molnets elastiska karaktär och för att undvika att manuellt hämta telemetridata från varje nod i systemet kan du konsolidera data och överföra dem till en central plats. I ett system som omfattar flera datacenter kanske du först vill samla in, konsolidera och lagra data region för region och sedan aggregera regionala data till ett enda centralt system.

För att optimera bandbreddsanvändningen kan du överföra mindre brådskande data som batchar. Fördröj inte överföringen på obestämd tid, särskilt om data innehåller tidskänslig information.

Hämta och skicka instrumentationsdata

Undersystemet för instrumenteringsdatainsamling kan aktivt hämta instrumentationsdata från de olika loggarna och andra källor för varje instans av programmet. Den här metoden kallas pull-modellen. Eller så kan den fungera som en passiv mottagare som väntar på att de komponenter som utgör varje instans av programmet ska skicka data. Den här metoden kallas push-modellen.

En metod för pull-modellen är att använda övervakningsagenter som körs lokalt med varje instans av programmet. En övervakningsagent är en separat process som regelbundet hämtar telemetridata som samlas in på den lokala noden och skriver informationen till centraliserad lagring som alla instanser av programmet delar. Azure Monitor Agent implementerar den här mekanismen. Du konfigurerar data att samla in från varje beräkningsinstans via en datainsamlingsregel. Övervakningsagenten som körs tillsammans med varje instans samlar in angivna data, till exempel IIS-loggar, Windows händelseloggar och prestandaräknare, och skickar dem till en Log Analytics arbetsyta i Azure Monitor, där du kan fråga och analysera den. Följande diagram visar ett exempel på den här arkitekturen.

Du kan använda pull- och push-modeller för att lagra telemetridata för ett småskaligt program som körs på ett begränsat antal noder på en enda plats. Ett komplext, mycket skalbart, globalt molnprogram kan generera enorma mängder data från hundratals beräkningsinstanser, databasskärvor och andra tjänster. Den här datamängden kan enkelt överbelasta I/O-bandbredden som är tillgänglig vid en enda central plats. Därför måste du kunna skala telemetrilösningen för att förhindra en flaskhals när systemet expanderar. Helst bör lösningen innehålla en viss redundans för att minska risken för att förlora viktig övervakningsinformation, till exempel gransknings- eller faktureringsdata, om en del av systemet misslyckas.

Implementera köer för att lösa dessa problem. I följande exempelarkitektur publicerar den lokala övervakningsagenten eller den anpassade datainsamlingstjänsten data till en kö. Lagringsskrivtjänsten, en separat asynkron process, hämtar data från den här kön och skriver det till delad lagring. En meddelandekö är lämplig för det här scenariot eftersom den innehåller semantik minst en gång som hjälper till att säkerställa att köade data inte går förlorade när de har publicerats. Du kan implementera tjänsten för lagringsskrivning med hjälp av en separat bakgrundsprocess.

Den lokala datainsamlingstjänsten kan lägga till data i en kö omedelbart efter att ha tagit emot dem. Kön fungerar som en buffert och tjänsten för lagringsskrivning kan hämta och skriva data i sin egen takt. Som standard fungerar en kö först in, först ut. Men du kan prioritera meddelanden för att påskynda dem genom kön om de innehåller data som du måste hantera snabbt. Mer information finns i mönstret Prioritetskö. Alternativt kan du använda olika kanaler, till exempel Service Bus-ämnen, för att styra data till olika mål beroende på vilken form av analytisk bearbetning som krävs.

För skalbarhet kan du köra flera instanser av tjänsten för lagringsskrivning. För stora mängder händelser kan du använda en händelsehubb för att skicka data till olika beräkningsresurser för bearbetning och lagring.

Sammanställ instrumenteringsdata

Instrumentationsdata som datainsamlingstjänsten hämtar från en enda instans av ett program ger en lokaliserad vy över den instansens hälsa och prestanda. Om du vill utvärdera systemets övergripande hälsa konsoliderar du aspekter av data i de lokala vyerna. Du kan utföra det här steget när data har lagrats, men i vissa fall kan du också göra det när data samlas in. I stället för att skriva direkt till delad lagring passerar instrumentationsdata genom en separat tjänst som konsoliderar, filtrerar och rensar data. Instrumentationsdata som innehåller samma korrelationsinformation, t.ex. ett aktivitets-ID, kan till exempel amalgameras. En användare kan starta en affärsåtgärd på en nod och sedan överföras till en annan nod om noden misslyckas eller på grund av belastningsutjämning. Den här processen kan också identifiera och ta bort duplicerade data, vilket är möjligt om telemetritjänsten använder meddelandeköer för att skicka ut instrumentationsdata till lagring. Följande diagram visar ett exempel på den här strukturen.

Lagra instrumentationsdata

I föregående avsnitt visas en förenklad vy över hur du lagrar instrumentationsdata. I praktiken bör du lagra olika typer av information med hjälp av de tekniker som passar hur du planerar att använda den.

Till exempel Azure Blob Storage och Azure Table Storage har liknande åtkomstmönster, men de åtgärder som de kan utföra är begränsade och kornigheten för de data som de lagrar varierar. Om du behöver utföra analysåtgärder eller kräver fulltextsökningsfunktioner kan du behöva använda datalagring som tillhandahåller följande funktioner för fråga och dataåtkomst:

• Lagra prestandaräknare i en SQL-databas för att aktivera oplanerad analys.
• Lagra spårningsloggar i Azure Cosmos DB.
• Skriv säkerhetsinformation till HDFS (Hadoop Distributed File System).
• Lagra information som kräver fulltextsökning med elasticsearch, som använder omfattande indexering för att påskynda sökningar.

Följande diagram visar hur du kan implementera en extra tjänst som regelbundet hämtar data från delad lagring, partitioner och filtrerar data enligt dess syfte och sedan skriver dem till en lämplig uppsättning datalager. En annan metod är att inkludera den här funktionen i konsoliderings- och rensningsprocessen och skriva data direkt till dessa lager när de hämtas, i stället för att spara dem i ett mellanliggande delat lagringsområde. Varje metod har fördelar och nackdelar. Om du implementerar en separat partitioneringstjänst minskar belastningen på konsoliderings- och rensningstjänsten. Det gör också att du vid behov kan återskapa åtminstone en del av de partitionerade data som den delade lagringen behåller, beroende på hur mycket data den delade lagringen behåller. Den här metoden förbrukar dock mer resurser. Det kan också fördröja mottagandet av instrumentationsdata från varje programinstans och konverteringen av dessa data till användbar information.

Du kan behöva samma instrumentationsdata för mer än ett syfte. Prestandaräknare kan till exempel ge en historisk vy över systemprestanda över tid. Du kan kombinera den här informationen med andra användningsdata för att generera kundfaktureringsinformation. I dessa scenarier skickar du samma data till fler än ett mål, till exempel en dokumentdatabas som lagrar faktureringsinformation och ett flerdimensionellt lager som hanterar komplexa prestandaanalyser.

Överväg hur snabbt du behöver data. Data som tillhandahåller information för aviseringar måste nås snabbt, så du bör lagra dem i snabb datalagring och indexera eller strukturera dem för att optimera systemfrågor för aviseringar. I vissa fall kan telemetritjänsten som samlar in data på varje nod behöva formatera och spara data lokalt så att en lokal instans av aviseringssystemet snabbt kan meddela dig om problem. Du kan skicka samma data till tjänsten för lagringsskrivning som de tidigare diagrammen visar och lagrar dem centralt om du behöver dem för andra ändamål.

Information som du använder för mer komplex analys, för rapportering och för att identifiera historiska trender är mindre brådskande. Lagra den på ett sätt som stöder datautvinning och oplanerade frågor. Mer information finns i Stöd för het, ljummen och kall analys.

Loggrotation och datakvarhållning

Instrumentation genererar mycket data. I vissa fall kan du ta bort de ursprungliga rådata från varje nod när data har bearbetats och överförts. Eller så kan du behöva spara rådata.

Prestandadata har vanligtvis en längre livslängd så att du kan använda dem för att identifiera prestandatrender och planera kapacitet. Håll den konsoliderade vyn av dessa data online under en begränsad period så att du kan komma åt dem snabbt. Du kan behöva spara data som samlats in för mätning och fakturering på obestämd tid. Dessutom kan regelkrav kräva att du arkiverar och sparar information som samlas in för granskning och säkerhetsändamål. Kryptera eller på annat sätt skydda känsliga data för att förhindra manipulering. Registrera aldrig användarnas lösenord eller annan personlig information. Ta bort de här detaljerna från datan innan du lagrar den.

Nedprovtagning av data

Lagra historiska data för att upptäcka långsiktiga trender. I stället för att spara all gammal data kan du sampla ned datan för att minska upplösningen och lagringskostnaderna. I stället för att spara prestandaindikatorer minut för minut kan du till exempel konsolidera data som är mer än en månad gamla för att bilda en timme för timme-vy.

Metodtips för att samla in och lagra loggningsinformation

I följande lista sammanfattas metodtips för att samla in och lagra loggningsinformation:

• Övervakningsagenten eller datainsamlingstjänsten ska köras som en out-of-process-tjänst och vara enkel att distribuera.

• Alla utdata från övervakningsagenten eller datainsamlingstjänsten ska vara ett agnostiskt format som är oberoende av datorn, operativsystemet eller nätverksprotokollet. Generera till exempel information i ett självbeskrivande format, till exempel JSON-, MessagePack- eller Protobuf-filer i stället för ETL-filer (Event Trace Log) i Linux eller ETW. Använd ett standardformat så att systemet kan konstruera bearbetningspipelines. Du kan enkelt integrera komponenter som läser, transformerar och skickar data i det överenskomna formatet.

• Övervaknings- och datainsamlingsprocessen måste vara felsäker och får inte utlösa sammanhängande fel.

• Om ett tillfälligt fel skickar information till en datamottagare bör övervakningsagenten eller datainsamlingstjänsten vara beredd att ordna om telemetridata så att den senaste informationen skickas först. Övervakningsagenten eller datainsamlingstjänsten kan välja att släppa äldre data eller spara dem lokalt och överföra dem senare för att komma ikapp, efter eget gottfinnande.

Analysera data och diagnostisera problem

En viktig del av övervakning och diagnostik är att analysera insamlade data för att få en bild av systemets övergripande hälsa. Definiera dina egna KPI:er och prestandamått och lär dig hur du strukturerar data för att uppfylla dina analyskrav. Förstå hur data som samlas in i olika mått och loggfiler korrelerar eftersom den här informationen är nyckeln till att spåra en sekvens av händelser och diagnostisera problem.

Data för varje del av systemet samlas vanligtvis in lokalt, men sedan måste du kombinera dem med data som genereras på andra platser som deltar i systemet. Korrelera den här informationen noggrant för att säkerställa att data kombineras korrekt. Användningsdata för en åtgärd kan till exempel omfatta följande noder:

• En nod som är värd för en webbplats som en användare ansluter till
• En nod som kör en separat tjänst som används som en del av den här åtgärden
• En nod som lagrar data

Du måste koppla ihop den här informationen för att ge en övergripande vy över resursen och bearbetningsanvändningen för åtgärden. Noden som samlar in data kan förbearbeta och filtrera dem, men centrala noder aggregerar och formaterar vanligtvis data. Mer information finns i Konsolidera instrumentationsdata.

Stöd för het, varm och kall analys

Att analysera och formatera om data för visualisering, rapportering och avisering kan vara en komplex process som förbrukar en egen uppsättning resurser. Vissa former av övervakning kräver att omedelbar dataanalys är effektiv, även kallad frekvent analys. Exempel är analys för aviseringar och säkerhetsövervakning. För snabb analys gör du data tillgängliga och strukturerade för effektiv bearbetning. I vissa fall kan du behöva flytta analysbearbetningen till de enskilda noder som innehåller data.

Andra former av analys är mindre tidskänsliga och kan kräva beräkning och aggregering efter att rådata har tagits emot. Den här metoden kallas för varm analys. Prestandaanalys ingår ofta i den här kategorin. I det här fallet kan en plötslig topp eller ett plötsligt fel orsaka en isolerad, enskild prestandahändelse som inte är statistiskt signifikant. Data från en serie händelser ger en mer tillförlitlig bild av systemets prestanda.

Du kan också använda varm analys för att diagnostisera hälsoproblem. Använd snabbanalys för att bearbeta en hälsohändelse och skapa en avisering omedelbart. Använd sedan varm analys för att analysera data och hitta orsaken till hälsohändelsen.

Vissa typer av övervakning genererar mer långsiktiga data. Du kan utföra den här analysen vid ett senare tillfälle, eventuellt enligt ett fördefinierat schema. I vissa fall kan analysen behöva filtrera stora mängder data som samlas in över tid. Den här metoden kallas kall analys. Det avgörande kravet är att du lagrar datan på ett säkert sätt när du har samlat in den. Användningsövervakning och granskning kräver till exempel en korrekt bild av systemtillståndet med jämna mellanrum, men den här tillståndsinformationen behöver inte vara omedelbart tillgänglig för bearbetning.

Du kan också använda kall analys för att tillhandahålla data för förutsägande hälsoanalys. Samla in historisk information under en angiven period och kombinera den med aktuella hälsodata för att se trender som kan orsaka hälsoproblem. I dessa fall kan du behöva skapa en avisering för att korrigera trenden.

Korrelera data

De data som instrumentationen samlar in kan ge en ögonblicksbild av systemtillståndet, men syftet med analysen är att göra dessa data användbara. Du kan till exempel fastställa orsaken till intensiv I/O-inläsning på systemnivå vid en viss tidpunkt och se till att databassvarstiderna, antalet transaktioner per sekund och programsvarstiderna vid samma tidpunkt bekräftar dina resultat.

Ett sätt att minska belastningen är att fragmentera data över fler servrar. Undantag kan inträffa på grund av ett fel på valfri nivå i systemet. Ett undantag på en nivå utlöser ofta ett annat fel på nivån ovanför det.

Av dessa skäl måste du korrelera de olika typerna av övervakningsdata på varje nivå för att skapa en övergripande vy över systemtillståndet och de program som körs på den. Använd den här informationen för att avgöra om systemet fungerar acceptabelt och avgöra vad du kan göra för att förbättra kvaliteten.

Se till att rådata för instrumentation innehåller tillräcklig kontext- och aktivitets-ID-information för att stödja nödvändiga sammansättningar för korrelering av händelser. Dessa data kan lagras i olika format, så du kan behöva parsa och konvertera dem till ett standardiserat format för analys. Mer information finns i Information om korrelering av data.

Felsöka och diagnostisera problem

För att diagnostisera problem måste du göra RCA för att fastställa orsaken till fel eller oväntat beteende. Du behöver vanligtvis följande information för hela systemet eller för ett visst undersystem under en angiven tidsperiod:

• Detaljerad information från händelseloggar och spårningar
• Slutföra stackspårningar från undantag och fel på en angiven nivå
• Kraschdumpar för alla processer som har kraschat
• Aktivitetsloggar som registrerar de åtgärder som alla användare eller utvalda användare utför

För att analysera data i felsökningssyfte behöver du en djup teknisk förståelse för systemarkitekturen och dess komponenter. Du måste tolka data, fastställa orsaken till problem och rekommendera en strategi för att korrigera dem. En annan strategi är att lagra en kopia av den här informationen i sitt ursprungliga format och göra den tillgänglig för kall analys av en expert.

Visualisera data och skapa aviseringar

Övervakningssystem måste presentera data så att du snabbt kan identifiera trender eller problem. De måste också meddela dig omedelbart när en händelse som kräver uppmärksamhet inträffar.

Datapresentationen kan ta flera former, inklusive visualisering med hjälp av instrumentpaneler, aviseringar och rapportering.

Visualisering med hjälp av instrumentpaneler

Det vanligaste sättet att visualisera data är att använda instrumentpaneler som visar information som en serie diagram, diagram eller andra illustrationer. Du kan parametrisera dessa objekt och välja viktiga parametrar, till exempel tidsperioden, för en specifik situation.

Du kan ordna instrumentpaneler hierarkiskt. Översiktspaneler på högsta nivån ger en övergripande bild av varje aspekt av systemet och låter dig gå ner till detaljerna. I en instrumentpanel som visar systemets övergripande disk-I/O kan du till exempel visa I/O-priserna för varje enskild disk för att avgöra om en eller flera specifika enheter står för en oproportionerlig trafikvolym. Instrumentpanelen bör också visa relaterad information, till exempel den användare eller aktivitet som genererar denna I/O. Den här informationen kan hjälpa dig att sprida belastningen jämnare över enheter.

En instrumentpanel kan också använda färgkodning eller andra visuella tips för att ange värden som visas avvikande eller som ligger utanför ett förväntat intervall. Överväg följande exempel på färgkodning:

• Röd för en disk med en I/O-hastighet som närmar sig sin maximala kapacitet under en längre period, eller en frekvent disk

• Gul för en disk med en I/O-hastighet som regelbundet körs med sin maximala gräns under korta perioder eller en varm disk

• Grönt för en disk som uppvisar normal användning

Dashboardssystem måste ha den rådata som krävs för att fungera effektivt. Om du skapar ett eget instrumentpanelssystem eller använder en instrumentpanel som utvecklats av en annan organisation måste du förstå vilka instrumentationsdata du behöver samla in, på vilka detaljnivåer och hur du formaterar dem så att instrumentpanelen kan användas.

Med en effektiv instrumentpanel kan du också ställa frågor om information. Vissa system tillhandahåller hanteringsverktyg som du kan använda för att utföra dessa uppgifter och utforska underliggande data. Beroende på vilken lagringsplats som innehåller informationen kanske du kan köra frågor mot data direkt eller importera dem till verktyg som Excel för ytterligare analys och rapportering.

Skapa aviseringar

Aviseringar analyserar övervaknings- och instrumentationsdata och genererar ett meddelande om det upptäcker en betydande händelse.

Aviseringar hjälper till att säkerställa att systemet förblir hälsosamt, dynamiskt och säkert. Det är en viktig del av alla system som ger användarna garantier för prestanda, tillgänglighet och sekretess. Aviseringar kan också meddela dig om händelser som utlöser aviseringar. Använd aviseringar för att anropa systemfunktioner som autoskalning.

Aviseringar beror på följande instrumentationsdata:

• Säkerhetshändelser: Om händelseloggarna anger att upprepade autentiserings- eller auktoriseringsfel inträffar. I det här scenariot bör en avisering informera dig om att systemet kan vara under attack.

• Prestandamått: Systemet måste snabbt svara om ett prestandamått överskrider ett angivet tröskelvärde.

• Tillgänglighetsinformation: Om ett fel upptäcks kan du snabbt behöva starta om ett eller flera undersystem eller redundansväxla till en säkerhetskopieringsresurs. Upprepade fel i ett undersystem kan tyda på allvarligare problem.

Du kan få aviseringsinformation via många kanaler, till exempel e-post, en sidsökare eller ett SMS. En avisering kan också innehålla en indikation på hur kritisk en situation är. Många aviseringssystem stöder prenumerantgrupper och alla operatörer som är medlemmar i samma grupp får samma uppsättning aviseringar.

Gör aviseringssystemet anpassningsbart och ange lämpliga värden från underliggande instrumentationsdata som parametrar. Med den här metoden kan du filtrera data för specifika tröskelvärden eller kombinationer av värden. I vissa fall kan du tillhandahålla rå instrumenteringsdata till aviseringssystemet. Eller så kan det vara lämpligare att ange aggregerade data. En avisering utlöses till exempel när CPU-användningen för en nod överskrider 90% under de senaste 10 minuterna. Ange lämplig sammanfattnings- och kontextinformation för aviseringssystemet för att minska risken för att falska positiva händelser utlöser en avisering.

Rapportering

Använd rapportering för att generera en övergripande vy över systemet. Den kan innehålla historiska data och aktuell information. Rapporteringskraven hör till drifts- och säkerhetskategorier.

Driftrapportering omfattar vanligtvis följande aspekter för det övergripande systemet eller specifika undersystem under en angiven tidsperiod:

• Sammanställd statistik som du kan använda för att förstå resursutnyttjande

• Trender i resursanvändning

• Undantagsövervakning

• Programeffektivitet när det gäller distribuerade resurser och om du kan minska mängden resurser utan att påverka prestanda

Säkerhetsrapportering spårar hur kunder använder systemet. Den innehåller vanligtvis följande aspekter:

• Granska användaråtgärder. Registrera enskilda begäranden som varje användare utför tillsammans med datum och tider. Strukturera data så att du snabbt kan rekonstruera sekvensen med åtgärder som en användare utför under en angiven period.

• Spåra resursanvändning för varje användare. Registrera hur varje användarförfrågan får tillgång till systemresurser och hur länge. Använd dessa data för att generera en användningsrapport för varje användare under en angiven period, eventuellt i faktureringssyfte.

Ofta kan batchprocesser generera rapporter enligt ett definierat schema. Rapportgenereringen ökar vanligtvis inte svarstiden, så du kan generera rapporter på begäran om det behövs. Om du lagrar data i en relationsdatabas, till exempel Azure SQL Database, kan du använda ett verktyg som SQL Server Reporting Services för att extrahera och formatera data och presentera dem som en uppsättning rapporter.

Nästa steg

• Azure Monitor-översikt
• Övervaka, diagnostisera och felsöka Lagring
• Översikt över aviseringar i Azure
• Översikt över Application Insights
• Performance-diagnostik för Azure virtuella datorer

Relaterade resurser

• Vägledning för automatisk skalning beskriver hur du minskar hanteringskostnaderna genom att minska behovet av att kontinuerligt övervaka systemets prestanda och fatta beslut om att lägga till eller ta bort resurser.

• Hälsoslutpunktsövervakningsmönster beskriver hur du implementerar funktionella kontroller i ett program som externa verktyg kan komma åt via exponerade slutpunkter med jämna mellanrum.

• Mönster för prioritetskö beskriver hur du prioriterar köade meddelanden så att system tar emot och bearbetar brådskande begäranden före mindre brådskande meddelanden.