Vägledning för övervakning och diagnostik

Distribuerade program och tjänster som körs i molnet är till sin natur komplexa delar av programvara som består av många rörliga delar. I en produktionsmiljö är det viktigt att kunna spåra hur användarna använder systemet, spåra resursutnyttjande och i allmänhet övervaka systemets hälsa och prestanda. Du kan använda den här informationen som diagnostiskt stöd för att identifiera och åtgärda problem samt för att upptäcka potentiella problem och förebygga att de uppstår.

Scenarier för övervakning och diagnostik

Du kan använda övervakning för att få en inblick i hur väl ett system fungerar. Övervakning är en viktig del av upprätthållandet av tjänstkvalitetsmål. Vanliga scenarier för insamling av övervakningsdata är:

• Se till att systemet förblir hälsosamt.
• Spåra tillgängligheten för systemet och dess komponentelement.
• Upprätthålla 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 alla serviceavtal (SLA) som upprättats med kunder.
• Skydda systemets, användarnas och deras datas integritet och säkerhet.
• Spåra de åtgärder som utförs i gransknings- eller regelsyfte.
• Övervaka den dagliga användningen av systemet och upptäcka trender som kan leda till problem om de inte åtgärdas.
• Spårningsproblem som uppstår, från den första rapporten till analys av möjliga orsaker, korrigering, efterföljande programuppdateringar och distribution.
• Spårningsåtgärder och felsökning av programvaruversioner.

I följande avsnitt beskrivs dessa scenarier mer detaljerat. Informationen för varje scenario beskrivs i följande format:

1. En kort översikt över scenariot.
2. De typiska kraven i det här scenariot.
3. Rådata för instrumentation som krävs för att stödja scenariot och möjliga källor till den här informationen.
4. Hur dessa rådata kan analyseras och kombineras för att generera meningsfull diagnostisk information.

Hälsoövervakning

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

Krav för hälsoövervakning

En operatör bör aviseras snabbt (inom några sekunder) om någon del av systemet bedöms vara skadad. Operatören bör kunna fastställa vilka delar av systemet som fungerar normalt och vilka delar som har problem. Systemhälsa kan markeras via ett trafikljussystem:

• Rött för fel (systemet har stoppats)
• Gult för delvis felfri (systemet körs med nedsatt funktionalitet)
• Grön för helt felfri

Ett omfattande hälsoövervakningssystem gör det möjligt för en operatör att öka detaljnivån genom systemet för att visa hälsostatusen för undersystem och komponenter. Om det övergripande systemet till exempel visas som delvis felfritt bör operatorn kunna zooma in och avgöra vilka funktioner som för närvarande inte är tillgängliga.

Krav för datakällor, instrumentation och datainsamling

Rådata som krävs för att stödja hälsoövervakning kan genereras som ett resultat av:

• Spårningskörning av användarbegäranden. Den här informationen kan användas för att avgöra vilka begäranden som har lyckats, vilka som har misslyckats och hur lång tid varje begäran tar.
• Syntetisk användarövervakning. Den här processen simulerar de steg som utförs av en användare och följer en fördefinierad serie steg. Resultatet av varje steg ska samlas in.
• Loggningsfel, fel och varningar. Den här informationen kan samlas in som ett resultat av spårningsinstruktioner som är inbäddade i programkoden och som hämtar information från händelseloggarna för alla tjänster som systemet refererar till.
• Övervaka hälsotillståndet för tjänster från tredje part som systemet använder. Den här övervakningen kan kräva hämtning och parsning av hälsodata som dessa tjänster tillhandahåller. Den här informationen kan ha en mängd olika format.
• Slutpunktsövervakning. Den här mekanismen beskrivs mer detaljerat i avsnittet "Tillgänglighetsövervakning".
• Samla in information om omgivande prestanda, till exempel cpu-användning i bakgrunden eller I/O-aktivitet (inklusive nätverk).

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 identifieras som felaktig. (Det går inte att svara på en rad pingar i följd, till exempel.) Operatorn kan sedan vidta lämpliga korrigerande åtgärder.

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 upptäcka trender och avgöra om systemet sannolikt kommer att förbli felfritt eller om systemet kommer att behöva ytterligare resurser. Det här prediktiva elementet bör baseras på kritiska prestandamått, till exempel:

• 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 till och från 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 göra det möjligt för en operator eller autoskalning (om tillgängligt) att vidta de förebyggande åtgärder som krävs för att upprätthålla systemets hälsa. Dessa åtgärder kan innebära att lägga till resurser, starta om en eller flera tjänster som misslyckas eller tillämpa begränsning på begäranden med lägre prioritet.

Tillgänglighetsövervakning

Ett verkligt felfritt system kräver att de komponenter och undersystem som utgör systemet är tillgängliga. Tillgänglighetsövervakning är nära relaterat till hälsoövervakning. Men medan hälsoövervakning ger en omedelbar bild av systemets nuvarande hälsa, handlar tillgänglighetsövervakningen om att spåra systemets tillgänglighet och dess komponenter för att generera statistik om systemets drifttid.

I många system är vissa komponenter (till exempel en databas) konfigurerade med inbyggd redundans för att möjliggöra snabb redundans i händelse av ett allvarligt fel eller förlust av anslutning. Helst bör användarna inte vara medvetna om att ett sådant fel har inträffat. Men ur ett tillgänglighetsövervakningsperspektiv är det nödvändigt att samla in så mycket information som möjligt om sådana fel för att fastställa orsaken och vidta korrigerande åtgärder för att förhindra att de upprepas.

Vilka data som krävs för att spåra tillgängligheten kan bero på ett antal faktorer på lägre nivå. Många av dessa faktorer kan vara specifika för programmet, systemet och miljön. Ett effektivt övervakningssystem samlar in tillgänglighetsdata som motsvarar dessa lågnivåfaktorer och sammanställer 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å lagringsplatsen där orderinformation lagras och det betalningssystem som hanterar de monetära transaktionerna för att betala för dessa beställningar. Tillgängligheten för beställningsplaceringsdelen i systemet är därför en funktion av tillgängligheten för lagringsplatsen och betalningsundersystemet.

Krav för tillgänglighetsövervakning

En operatör bör också kunna visa den historiska tillgängligheten för varje system och undersystem och använda den här informationen för att upptäcka eventuella trender som kan orsaka att ett eller flera undersystem regelbundet misslyckas. (Börjar tjänsterna att misslyckas vid en viss tidpunkt på dagen som motsvarar högsta bearbetningstid?)

En övervakningslösning bör ge en omedelbar och historisk vy över tillgängligheten eller otillgängligheten för varje undersystem. Den bör också kunna varna en operatör snabbt när en eller flera tjänster misslyckas eller när användarna inte kan ansluta till tjänster. Det handlar inte bara om att övervaka varje tjänst, utan även att undersöka de åtgärder som varje användare utför om dessa åtgärder misslyckas när de försöker kommunicera med en tjänst. I viss utsträckning är en viss grad av anslutningsfel normalt och kan bero på tillfälliga fel. Men det kan vara användbart att låta systemet skapa en avisering om antalet anslutningsfel till ett angivet undersystem som inträffar under en viss period.

Krav för datakällor, instrumentation och datainsamling

Precis som med hälsoövervakning kan rådata som krävs för tillgänglighetsövervakning genereras som ett resultat av syntetisk användarövervakning och loggning av eventuella undantag, fel och varningar som kan inträffa. Dessutom kan tillgänglighetsdata hämtas från slutpunktsövervakning. Programmet kan exponera en eller flera hälsoslutpunkter, varje teståtkomst till ett funktionellt område i systemet. Övervakningssystemet kan pinga varje slutpunkt genom att följa ett definierat schema och samla in resultaten (lyckades eller misslyckades).

Alla timeouter, nätverksanslutningsfel och återförsök av anslutningar måste registreras. Alla data ska tidsstämplas.

Analysera tillgänglighetsdata

Instrumentationsdata måste aggregeras och korreleras för att stödja följande typer av analys:

• Systemets och undersystemens omedelbara tillgänglighet.
• Tillgänglighetsfelfrekvensen för systemet och undersystemen. Helst bör en operatör kunna korrelera fel med specifika aktiviteter: vad hände när systemet misslyckades?
• En historisk vy över systemets felfrekvens eller eventuella undersystem under en angiven period och belastningen på systemet (till exempel antalet användarbegäranden) när ett fel inträffade.
• Orsakerna till att systemet eller några undersystem inte är tillgängliga. Orsaken kan till exempel vara att tjänsten inte körs, att anslutningen går förlorad, att anslutningen är ansluten men tidsgränsen är slut och att den är ansluten men returnerar fel.

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

Detta är användbart för serviceavtal. (Serviceavtalsövervakning beskrivs mer detaljerat senare i den här vägledningen.) Definitionen av stilleståndstid beror på tjänsten. Visual Studio Team Services Build Service definierar till exempel stilleståndstid som den period (totalt ackumulerade minuter) under vilken Byggtjänsten inte är tillgänglig. En minut anses vara otillgänglig om alla kontinuerliga HTTP-begäranden till Build Service för att utföra kundinitierade åtgärder under minuten antingen resulterar i en felkod eller inte returnerar något svar.

Prestandaövervakning

Eftersom systemet utsätts för mer och mer stress (genom att öka antalet användare) ökar storleken på de datauppsättningar som dessa användare har åtkomst till och risken för fel på en eller flera komponenter blir mer sannolik. Ofta föregås komponentfel av en minskning av prestanda. Om du kan identifiera en sådan minskning kan du vidta proaktiva åtgärder för att åtgärda situationen.

Systemprestanda beror på ett antal faktorer. Varje faktor mäts vanligtvis 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 kan härledas från en kombination av mått.

Krav för prestandaövervakning

För att undersöka systemprestanda behöver en operatör vanligtvis se information som innehåller:

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

Det kan också vara användbart att tillhandahålla verktyg som gör det möjligt för en operatör att hjälpa till att upptäcka korrelationer, till exempel:

• Antalet samtidiga användare jämfört med svarstider för begäran (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 (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å bör en operatör kunna få en detaljerad vy över prestanda för varje komponent i systemet. Dessa data tillhandahålls vanligtvis via prestandaräknare på låg nivå som spårar information, till exempel:

• Minnesanvändning.
• Antal trådar.
• Processorbearbetningstid.
• Begärandekölängd.
• Disk- eller nätverks-I/O-priser och -fel.
• Antal byte som skrivits eller lästs.
• Indikatorer för mellanprogram, till exempel kölängd.

Alla visualiseringar bör göra det möjligt för en operatör att ange en tidsperiod. De data som visas kan vara en ögonblicksbild av den aktuella situationen eller en historisk vy över prestandan.

En operator bör kunna skapa en avisering baserat på eventuella prestandamått för ett angivet värde under ett angivet tidsintervall.

Krav för datakällor, instrumentation och datainsamling

Du kan samla in prestandadata på hög nivå (dataflöde, antal samtidiga användare, antal affärstransaktioner, felfrekvenser och så vidare) genom att övervaka förloppet för användarnas begäranden när de anländer och passera genom systemet. Det handlar om att införliva spårningsinstruktioner vid viktiga punkter i programkoden, tillsammans med tidsinformation. Alla fel, undantag och varningar bör samlas in med tillräckliga data för att korrelera dem med de begäranden som orsakade dem. IIS-loggen (Internet Information Services) är en annan användbar källa.

Om möjligt bör du också samla 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 detta inte är möjligt registrerar du information, till exempel starttid och sluttid för varje begäran som görs till ett externt system, tillsammans med åtgärdens status (lyckades, misslyckades eller varningen). Du kan till exempel använda en stoppursmetod för tidsbegäranden: starta en timer när begäran startar och stoppa sedan timern när begäran är klar.

Prestandadata på låg nivå för enskilda komponenter i ett system kan vara tillgängliga via funktioner och tjänster som Prestandaräknare för Windows och Azure Diagnostics.

Analysera prestandainformation

En stor del av analysarbetet består av att aggregera prestandadata efter typ av användarbegäran eller 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 utföra utcheckningsprocessen i ett e-handelssystem.

Ett annat vanligt krav är att sammanfatta prestandadata i valda percentiler. En operatör kan till exempel fastställa svarstiderna för 99 procent av begäranden, 95 procent av begäranden och 70 procent av begäranden. Det kan finnas SLA-mål eller andra mål för varje percentil. De pågående resultaten bör rapporteras i nära realtid för att identifiera omedelbara problem. Resultaten bör också aggregeras över längre tid för statistiska ändamål.

Om svarstidsproblem påverkar prestandan bör en operator snabbt kunna identifiera orsaken till flaskhalsen genom att undersöka svarstiden för varje steg som varje begäran utför. Prestandadata måste därför tillhandahålla ett sätt att korrelera prestandamått för varje steg för att koppla dem till en specifik begäran.

Beroende på visualiseringskraven 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 ad hoc-frågor och analyser av prestandainformationen.

Säkerhetsövervakning

Alla kommersiella system som innehåller känsliga data måste implementera en säkerhetsstruktur. Komplexiteten i säkerhetsmekanismen är vanligtvis en funktion av datakänsligheten. I ett system som kräver att användare autentiseras bör du registrera:

• Alla inloggningsförsök, oavsett om de misslyckas eller lyckas.
• Alla åtgärder som utförs av – och information om alla resurser som nås av – en autentiserad användare.
• När en användare avslutar en session och loggar ut.

Övervakning kanske kan hjälpa till att identifiera attacker på systemet. Ett stort antal 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 (Distributed Denial-of-Service). Du måste vara beredd att övervaka alla begäranden till alla resurser oavsett källan för dessa begäranden. Ett system som har en inloggningsrisk kan oavsiktligt exponera resurser för omvärlden utan att kräva att en användare faktiskt loggar in.

Krav för säkerhetsövervakning

De mest kritiska aspekterna av säkerhetsövervakning bör göra det möjligt för en operatör att snabbt:

• 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 beviljats åtkomst till.
• Avgör om systemet, eller någon del av systemet, är under attack utifrån eller inuti. (En illasinnad autentiserad användare kan till exempel försöka få ner systemet.)

För att stödja dessa krav bör en operatör meddelas 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.

Den information som tillhandahålls till en operatör bör innehålla källans värdadress för varje begäran. Om säkerhetsöverträdelser regelbundet uppstår från ett visst adressintervall kan dessa värdar blockeras.

En viktig del i att upprätthålla säkerheten i ett system är att snabbt kunna identifiera åtgärder som avviker från det vanliga mönstret. Information som antalet misslyckade eller lyckade inloggningsbegäranden kan visas visuellt för att identifiera om det finns en aktivitetstoppar vid en ovanlig tidpunkt. (Ett exempel på den här aktiviteten är användare som loggar in kl. 03:00 och utför ett stort antal åtgärder när deras arbetsdag börjar kl. 09:00). Den här informationen kan också användas för att konfigurera tidsbaserad autoskalning. Om till exempel en operatör observerar att ett stort antal användare regelbundet loggar in vid en viss tidpunkt på dagen kan operatören ordna att starta ytterligare autentiseringstjänster för att hantera arbetsvolymen och sedan stänga av dessa ytterligare tjänster när toppen har passerat.

Krav för datakällor, instrumentation och datainsamling

Säkerhet är en heltäckande aspekt av de flesta distribuerade system. Relevanta data kommer sannolikt att genereras vid flera punkter i ett system. Du bör överväga att använda en SIEM-metod (Security Information and Event Management) för att samla in säkerhetsrelaterad information som härrör från 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 som inte ingår i ditt program. Dessa verktyg kan omfatta verktyg som identifierar portgenomsökningsaktiviteter av externa byråer eller nätverksfilter som identifierar försök att få oautentiserad åtkomst till ditt program och dina data.

I samtliga fall måste insamlade data göra det möjligt för en administratör att fastställa typen av angrepp och vidta lämpliga motåtgärder.

Analysera säkerhetsdata

En funktion i säkerhetsövervakning är de olika källor som data uppstår från. De olika formaten och detaljnivån kräver ofta komplex analys av insamlade data för att koppla samman dem i en sammanhängande informationstråd. Förutom de enklaste fallen (till exempel identifiering av ett stort antal misslyckade inloggningar eller upprepade försök att få obehörig åtkomst till kritiska resurser) kanske det inte går att utföra någon komplex automatiserad bearbetning av säkerhetsdata. I stället kan det vara bättre att skriva dessa data, tidsstämplade men i övrigt i sin ursprungliga form, till en säker lagringsplats för att möjliggöra manuell expertanalys.

SLA-övervakning

Många kommersiella system som stöder betalande kunder ger garantier om systemets prestanda i form av serviceavtal. I princip anger serviceavtal att systemet kan hantera en definierad mängd arbete inom en överenskommen tidsram och utan att förlora viktig information. SLA-övervakning handlar om att säkerställa att systemet kan uppfylla mätbara serviceavtal.

Serviceavtal definieras ofta i termer av:

• Övergripande systemtillgänglighet. En organisation kan till exempel garantera att systemet är tillgängligt 99,9 procent av tiden. Detta motsvarar högst 9 timmars stilleståndstid per år, eller cirka 10 minuter i veckan.
• Driftdataflöde. Den här aspekten uttrycks ofta som en eller flera högvattenmärken, som att garantera att systemet kan stödja upp till 100 000 samtidiga användarförfrågningar eller hantera 10 000 samtidiga affärstransaktioner.
• Driftsvarstid. Systemet kan också ge garantier för den hastighet med vilken begäranden bearbetas. Ett exempel är att 99 procent av alla affärstransaktioner slutförs inom 2 sekunder och att ingen enskild transaktion tar längre tid än 10 sekunder.

Krav för SLA-övervakning

På den högsta nivån bör en operatör snabbt kunna avgöra om systemet uppfyller de överenskomna serviceavtalen eller inte. Och om inte bör operatorn kunna öka detaljnivån och undersöka de underliggande faktorerna för att fastställa orsakerna till undermåliga prestanda.

Vanliga indikatorer på hög nivå som kan avbildas visuellt är:

• Procentandelen drifttid för tjänsten.
• Programmets dataflöde (mätt i termer av lyckade transaktioner eller åtgärder per sekund).
• Antalet lyckade/misslyckade programbegäranden.
• Antalet program- och systemfel, undantag och varningar.

Alla dessa indikatorer bör kunna filtreras efter en angiven tidsperiod.

Ett molnprogram kommer sannolikt att bestå av ett antal undersystem och komponenter. En operator bör kunna välja en indikator på hög nivå och se hur den består av hälsotillståndet för de underliggande elementen. Om drifttiden för det övergripande systemet till exempel understiger ett acceptabelt värde bör en operator kunna zooma in och avgöra vilka element som bidrar till det här felet.

I aviseringssyfte bör systemet kunna skapa en händelse om någon av de övergripande indikatorerna överskrider ett angivet tröskelvärde. Informationen på den lägre nivån för de olika faktorer som utgör indikatorn på hög nivå bör vara tillgänglig som kontextuella data för aviseringssystemet.

Krav för datakällor, instrumentation och datainsamling

Rådata som krävs för att stödja SLA-övervakning liknar de rådata som krävs för prestandaövervakning, tillsammans med vissa aspekter av hälso- och tillgänglighetsövervakning. (Mer information finns i avsnitten.) Du kan samla in dessa data genom att:

• Utföra slutpunktsövervakning.
• Loggningsfel, fel och varningar.
• Spåra körningen av användarbegäranden.
• Övervaka tillgängligheten för tjänster från tredje part som systemet använder.
• Använda prestandamått och räknare.

Alla data måste vara tidsstämplade och tidsstämplade.

Analysera SLA-data

Instrumentationsdata måste aggregeras för att generera en bild av systemets övergripande prestanda. Aggregerade data måste också ha stöd för ökad detaljnivå för att möjliggöra undersökning av de underliggande undersystemens prestanda. Du bör till exempel kunna:

• 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 för en begäran i svarstiderna för de enskilda arbetsobjekten i begäran.
• Fastställa systemets övergripande tillgänglighet som en procentandel av drifttiden för en viss period.
• Analysera procentandelen tidstillgänglighet för de enskilda komponenterna och tjänsterna i systemet. Detta kan innebära parsning av loggar som tjänster från tredje part har genererat.

Många kommersiella system krävs för att rapportera verkliga prestandasiffror mot överenskomna serviceavtal för en angiven period, vanligtvis en månad. Den här informationen kan användas för att beräkna krediter eller andra former av återbetalningar för kunder om serviceavtalen inte uppfylls under den perioden. Du kan beräkna tillgängligheten för en tjänst med hjälp av den teknik som beskrivs i avsnittet Analysera tillgänglighetsdata.

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

Granskning

Beroende på programmets art kan det finnas lagstadgade eller andra juridiska föreskrifter som anger 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 många e-affärssystem för att upprätthålla förtroende mellan en kund och den organisation som ansvarar för programmet eller tjänsten.

Krav för granskning

En analytiker måste kunna spåra sekvensen av affärsåtgärder som användarna utför så att du kan rekonstruera användarnas åtgärder. Detta kan vara nödvändigt helt enkelt som en fråga om register, eller som en del av en kriminalteknisk undersökning.

Granskningsinformationen är mycket känslig. Det kommer sannolikt att innehålla data som identifierar systemets användare, tillsammans med de uppgifter som de utför. Därför kommer granskningsinformation troligen att ha formen av rapporter som endast är tillgängliga för betrodda analytiker i stället för som ett interaktivt system som stöder ökad detaljnivå för grafiska åtgärder. En analytiker bör kunna generera ett antal rapporter. Rapporter kan till exempel visa en lista över alla användares aktiviteter som inträffar under en angiven tidsram, beskriva aktivitetskronologin för en enskild användare eller visa en lista över de åtgärder som utförs mot en eller flera resurser.

Krav för datakällor, instrumentation och datainsamling

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

• 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.

Formatet på granskningsdata och hur de lagras kan styras av regelkrav. Det kanske till exempel inte går att rensa data på något sätt. (Den måste registreras i sitt ursprungliga format.) Åtkomst till lagringsplatsen där den lagras måste skyddas för att förhindra manipulering.

Analysera granskningsdata

En analytiker måste kunna komma åt rådata i sin helhet, i sin ursprungliga form. Förutom kravet på att generera vanliga granskningsrapporter kommer verktygen för att analysera dessa data sannolikt att vara specialiserade och hållas utanför systemet.

Övervakning av användning

Användningsövervakning spårar hur funktioner och komponenter i ett program används. En operator kan använda insamlade data för att:

• Ta reda på vilka funktioner som används i hög grad och fastställa eventuella hotspots i systemet. Högtrafikelement kan dra nytta av funktionell partitionering eller till och med replikering för att sprida belastningen jämnare. En operatör kan också använda den här informationen för att fastställa vilka funktioner som sällan används 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. Den här informationen kan användas för kapacitetsplanering när antalet kunder växer.

• Identifiera (eventuellt indirekt) användarnöjdhet med systemets prestanda eller funktionalitet. Om till exempel ett stort antal kunder i ett e-handelssystem regelbundet överger sina kundvagnar kan det bero på ett 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 system med flera klientorganisationer överskrider sin betalda kvot för bearbetningstid eller resursanvändning under en angiven period kan deras åtkomst begränsas eller bearbetningen kan begränsas.

Krav för användningsövervakning

För att undersöka systemanvändningen behöver en operatör vanligtvis se information som innehåller:

• Antalet begäranden som bearbetas av varje undersystem och dirigeras 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 har åtkomst till.

En operator bör också kunna generera grafer. Ett diagram kan till exempel visa de mest resurskrävande användarna eller de resurser eller systemfunktioner som används oftast.

Krav för datakällor, instrumentation och datainsamling

Användningsspårning kan utföras på en relativt hög nivå. Den kan notera start- och sluttiderna för varje begäran och typen av begäran (läsa, skriva och så vidare, beroende på resursen i fråga). Du kan hämta den här informationen genom att:

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

I avläsningssyfte måste du också kunna identifiera vilka användare som ansvarar för att utföra vilka åtgärder och vilka resurser som dessa åtgärder använder. Den insamlade informationen bör vara tillräckligt detaljerad för att möjliggöra 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 handlar om att hantera dessa problem, associera dem med insatser för att lösa eventuella underliggande problem i systemet och informera kunderna om möjliga lösningar.

Krav för problemspårning

Operatörer utför ofta problemspårning med hjälp av ett separat system som gör det möjligt för dem att registrera och rapportera information om problem som användarna rapporterar. Den här informationen kan omfatta uppgifter som användaren försökte utföra, symptom på problemet, händelsesekvensen och eventuella fel- eller varningsmeddelanden som utfärdades.

Krav för datakällor, instrumentation och datainsamling

Den första datakällan för problemspårningsdata är den användare som rapporterade problemet från början. Användaren kanske kan tillhandahålla ytterligare data, till exempel:

• 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, tillsammans med annan miljöinformation, till exempel användarens plats.

Den här informationen kan användas för att hjälpa till med felsökningen och för att skapa en kvarvarande information för framtida versioner av programvaran.

Analysera problemspårningsdata

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

Förloppet för felsökningen bör registreras mot varje ärenderapport. När problemet är löst kan kunden informeras om lösningen.

Om en användare rapporterar ett problem som har en känd lösning i systemet för problemspårning bör operatören kunna 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 användaren ofta bara medveten om den omedelbara effekt som det har på deras åtgärder. Användaren kan bara rapportera resultatet av sin egen upplevelse tillbaka till en operatör som ansvarar för att underhålla systemet. Dessa upplevelser är vanligtvis bara ett synligt symptom på ett eller flera grundläggande problem. I många fall måste en analytiker gå igenom kronologin för de underliggande åtgärderna för att fastställa rotorsaken till problemet. Den här processen kallas rotorsaksanalys.

Krav för spårning och felsökning

För att spåra oväntade händelser och andra problem är det viktigt att övervakningsdata ger tillräckligt med information för att en analytiker ska kunna spåra tillbaka till ursprunget till dessa problem och rekonstruera sekvensen av händelser som inträffade. Den här informationen måste vara tillräcklig för att en analytiker ska kunna diagnostisera rotorsaken till eventuella problem. En utvecklare kan sedan göra de ändringar som krävs för att förhindra att de upprepas.

Krav för datakällor, instrumentation och datainsamling

Felsökning kan omfatta spårning av alla metoder (och deras parametrar) som anropas som en del av en åtgärd för att bygga upp ett träd som visar det logiska flödet genom systemet när en kund gör en specifik begäran. Undantag och varningar som systemet genererar till följd av det här flödet måste registreras och loggas.

För att stödja felsökning kan systemet tillhandahålla krokar som gör det möjligt för en operatör att samla in tillståndsinformation vid viktiga punkter i systemet. Eller så kan systemet leverera detaljerad steg-för-steg-information när valda åtgärder förlopp. Att samla in data på den här detaljnivån kan medföra ytterligare belastning på systemet och bör vara en tillfällig process. En operator använder den här processen främst när en mycket ovanlig serie händelser inträffar och är svår att replikera, eller när en ny version av ett eller flera element i ett system 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. Var och en av scenarierna som beskrivs i föregående avsnitt bör inte nödvändigtvis betraktas isolerat. Det kommer sannolikt att finnas en betydande överlappning i de övervaknings- och diagnostikdata som krävs för varje situation, även om dessa data kan behöva bearbetas och presenteras på olika sätt. Därför bör du ha en holistisk syn på övervakning och diagnostik.

Du kan se hela övervaknings- och diagnostikprocessen som en pipeline som omfattar de steg som visas i bild 1.

Bild 1 – Stegen i pipelinen för övervakning och diagnostik.

Bild 1 visar hur data för övervakning och diagnostik kan komma från en mängd olika datakällor. Instrumenterings- och insamlingsstegen handlar om att identifiera de källor där data behöver samlas in, fastställa vilka data som ska samlas in, hur de ska avbildas och hur dessa data ska formateras så att de enkelt kan undersökas. Analys-/diagnossteget tar rådata och använder dem för att generera meningsfull information som en operatör kan använda för att fastställa systemets tillstånd. Operatören kan använda den här informationen för att fatta beslut om möjliga åtgärder och sedan mata in resultaten i instrumentations- och insamlingsstegen igen. Fasen visualisering/aviseringssteg visar en förbrukningsvy över systemtillståndet. Den kan visa information nästan i realtid med hjälp av en serie instrumentpaneler. Och det kan generera rapporter, diagram och diagram för att ge en historisk vy över de data som kan hjälpa dig att identifiera långsiktiga trender. Om information anger att en KPI sannolikt överskrider acceptabla gränser kan den här fasen också utlösa en avisering till en operatör. I vissa fall kan en avisering också användas för att utlösa en automatiserad process som försöker vidta korrigerande åtgärder, till exempel autoskalning.

Observera att dessa steg utgör en kontinuerlig flödesprocess där stegen sker 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 det vara nödvändigt att samla in utökade data oftare. Vid andra tillfällen bör det vara möjligt att återgå till att samla in en grundläggande nivå av viktig information för att kontrollera att systemet fungerar korrekt.

Dessutom bör hela övervakningsprocessen betraktas som en aktiv, pågående lösning som är föremål för finjustering och förbättringar som ett resultat av feedback. Du kan till exempel börja med att mäta många faktorer för att fastställa systemets hälsa. Analys över tid kan leda till en förfining eftersom du tar bort mått som inte är relevanta, vilket gör att du kan fokusera mer exakt på de data som du behöver samtidigt som du minimerar bakgrundsbruset.

Källor för övervakning och diagnostikdata

Den information som används i övervakningsprocessen kan komma från flera källor, enligt bild 1. På programnivå kommer information från spårningsloggar som ingår i systemets kod. 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. Det kan också vara användbart att registrera in- och utgående tider.

Du bör logga alla undantag och varningar och se till att du behåller en fullständig spårning av kapslade undantag och varningar. Helst bör du också samla in information som identifierar den användare som kör koden, tillsammans med aktivitet korrelationsinformation (för att spåra begäranden när de passerar genom systemet). Och du bör logga försök att komma åt alla resurser, till exempel meddelandeköer, databaser, filer och andra beroende tjänster. Den här informationen kan användas för mätning och granskning.

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. Dessa ramverk kan konfigureras för att tillhandahålla egna spårningsmeddelanden och rå diagnostikinformation, till exempel transaktionshastigheter och lyckade och misslyckade dataöverföringar.

Operativsystemet där programmet körs kan vara en källa till systemomfattande information på låg nivå, till exempel prestandaräknare som anger I/O-priser, minnesanvändning och CPU-användning. Operativsystemfel (till exempel misslyckandet med att öppna en fil korrekt) kan också rapporteras.

Du bör också ta hänsyn till den underliggande infrastruktur och de komponenter 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 ett databashanteringssystem, kan dessa tjänster publicera sin egen spårningsinformation, loggar och prestandaräknare. Exempel är SQL Server Dynamic Management Views för spårningsåtgärder som utförs mot en SQL Server-databas och IIS-spårningsloggar för inspelningsbegäranden som görs till en webbserver.

När komponenterna i ett system ändras och nya versioner distribueras är det viktigt att kunna tillskriva problem, händelser och mått till varje version. Den här informationen bör kopplas tillbaka till versionspipelinen så att problem med en specifik version av en komponent kan spåras snabbt och åtgärdas.

Säkerhetsproblem kan uppstå när som helst i systemet. En användare kan till exempel försöka logga in med ett ogiltigt användar-ID eller lösenord. En autentiserad användare kan försöka få obehörig åtkomst till en resurs. Eller så kan en användare ange en ogiltig eller inaktuell nyckel för åtkomst till krypterad information. Säkerhetsrelaterad information för lyckade och misslyckade begäranden bör alltid loggas.

Avsnittet Instrumentering av ett program innehåller mer vägledning om den information som du bör samla in. Men du kan använda en mängd olika strategier för att samla in den här informationen:

• Program-/systemövervakning. Den här strategin 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 kan vara selektivt aktiverade eller inaktiverade enligt omständigheterna. Det kan också vara möjligt att mata in diagnostik dynamiskt med hjälp av ett diagnostikramverk. Dessa ramverk tillhandahåller vanligtvis plugin-program som kan anslutas till olika instrumentationspunkter i koden och samla in spårningsdata på dessa platser.

  Dessutom kan din kod eller den underliggande infrastrukturen generera händelser vid kritiska punkter. Övervakningsagenter som är konfigurerade för att lyssna efter dessa händelser kan registrera händelseinformationen.

• Verklig användarövervakning. Den här metoden registrerar interaktionerna mellan en användare och programmet och observerar flödet för varje begäran och svar. Den här informationen kan ha två syften: den kan användas för mätningsanvändning av varje användare och kan användas för att avgöra om användarna får en lämplig tjänstkvalitet (till exempel snabba svarstider, låg svarstid och minimala fel). Du kan använda insamlade data för att identifiera problemområden där fel inträffar oftast. Du kan också använda data för att identifiera element där systemet saktar ner, eventuellt på grund av hotspots i programmet eller någon annan form av flaskhals. Om du implementerar den här metoden noggrant kan det vara möjligt att rekonstruera användarnas flöden via programmet för felsökning och testning.

  Viktigt!

  Du bör överväga att de data som samlas in genom övervakning av verkliga användare är 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 ska du först ta bort alla personuppgifter.

• Syntetisk användarövervakning. I den här metoden skriver du 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 vilken typ av övervakningsutdata som genereras under dessa förhållanden.

  Anmärkning

  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. Den här metoden är främst inriktad på att övervaka och förbättra programprestanda. I stället för att fungera på den funktionella nivån för verklig och syntetisk användarövervakning samlar den in information på lägre nivå när programmet körs. Du kan implementera profilering med hjälp av regelbunden sampling av körningstillståndet för ett program (avgöra vilken kod som programmet kör vid en viss tidpunkt). Du kan också använda instrumentation som infogar avsökningar i koden vid viktiga tidpunkter (till exempel början och slutet av ett metodanrop) och registrerar vilka metoder som anropades, vid vilken tidpunkt och hur lång tid varje anrop tog. Du kan sedan analysera dessa data för att avgöra vilka delar av programmet som kan orsaka prestandaproblem.

• Slutpunktsövervakning. Den här tekniken 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 assimilera svaren. Mer information finns i mönstret Hälsoslutpunktsövervakning.

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 kan bara fatta meningsfulla beslut om prestanda och hälsa för ett system om du först samlar in de data som gör att du kan fatta dessa beslut. Den information som du samlar in med hjälp av instrumentation bör vara tillräcklig för att du ska kunna utvärdera prestanda, diagnostisera problem och fatta beslut utan att kräva att du loggar in på en fjärrproduktionsserver för att utföra spårning (och felsökning) manuellt. Instrumentationsdata består vanligtvis av mått och information som skrivs till spårningsloggar.

Innehållet i en spårningslogg kan vara resultatet av textdata som skrivs av programmet eller binära data som skapas till följd av en spårningshändelse, om programmet använder händelsespårning för Windows (ETW). De kan också genereras från systemloggar som registrerar händelser som uppstår från delar av infrastrukturen, till exempel en webbserver. Textloggmeddelanden är ofta utformade för att vara läsbara för människor, men de bör också skrivas i ett format som gör att ett automatiserat system enkelt kan parsa dem.

Du bör också kategorisera loggar. Skriv inte alla spårningsdata till en enda logg, men 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 behöva 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 (kallas ibland ett exempel). En enskild instans av ett mått är vanligtvis inte användbar isolerat. I stället måste mått samlas in över tid. Det viktigaste problemet att tänka på är vilka mått du bör registrera och hur ofta. Att generera data för mått för ofta kan medföra en betydande ytterligare belastning på systemet, medan insamling av mått sällan kan 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 avsevärt från sekund till sekund, men hög användning blir bara ett problem om den är långlivad under ett antal 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 diagnostiksteget i övervakningspipelinen för att korrelera data som hämtas från flera källor. Dessa data kan ha flera former i rådata, och analysprocessen måste tillhandahållas tillräckligt med instrumentationsdata för att kunna mappa dessa olika formulär. På programramverksnivå kan till exempel en uppgift identifieras av ett tråd-ID. I ett program kan samma arbete associeras med användar-ID:t för den användare som utför uppgiften.

Dessutom är det osannolikt att det finns en 1:1-mappning 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 mer än en användares räkning. För att ytterligare komplicera saker och ting kan en enskild begäran hanteras av mer än en tråd när körningen flödar 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:er i spårningsinformation beror på vilken teknik som används för att samla in spårningsdata.)

Alla övervakningsdata ska tidsstämplas på samma sätt. För konsekvens registrerar du alla datum och tider med hjälp av Coordinated Universal Time (Samordnad universell tid). Detta hjälper dig att lättare spåra sekvenser av händelser.

Information som ska ingå i instrumentationsdata

Tänk på följande när du bestämmer vilka instrumentationsdata du behöver samla in:

• Se till att information som samlas in av spårningshändelser är maskin- och läsbar. 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 drifts- och teknikpersonal 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 medföra betydande omkostnader för 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. Markeringen kan vara tidsbaserad (en gång var n sekund) eller frekvensbaserad (en gång var n begäranden). Om händelser inträffar mycket ofta kan profilering efter instrumentation orsaka för mycket av en börda och i sig påverka den övergripande prestandan. I det här fallet kan samplingsmetoden vara 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 för att göra det möjligt för en utvecklare eller administratör att fastställa källan för varje begäran. Detta kan innehålla någon form av aktivitets-ID som identifierar en specifik instans av en begäran. Den kan också innehålla information som kan användas för att korrelera den här aktiviteten med det beräkningsarbete som utförts och de resurser som används. Observera att 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 kunden som orsakade begäran. Den här kontexten ger värdefull information om programtillståndet vid den tidpunkt då övervakningsdata hämtades.

• 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 några platsspecifika hotspots. Den här informationen kan också vara användbar för att avgöra om ett program eller de data som används ska partitioneras om.

• 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 din programinsamling innehåller, eftersom detta 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 volymen av I/O som utförs, nätverksanvändning, antal begäranden, minnesanvändning och CPU-användning. Vissa infrastrukturtjänster kan tillhandahålla sina egna specifika prestandaräknare, till exempel antalet anslutningar till en databas, den hastighet med vilken transaktioner utförs 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 anropets framgång eller misslyckande. Samla om möjligt in information om alla återförsöksförsök och fel för 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 ett specifikt program eller teknik, men det förväntar sig att information följer ett specifikt format som vanligtvis definieras av ett schema. Schemat anger effektivt ett kontrakt som definierar de datafält och typer som telemetrisystemet kan mata in. Schemat bör generaliseras för att tillåta data som kommer från en rad olika plattformar och enheter.

Ett vanligt schema bör innehålla fält som är gemensamma för alla instrumentationshändelser, till exempel händelsenamnet, händelsetiden, avsändarens IP-adress och 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. 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. Detta kan vara information om undantag, programstart- och sluthändelser samt lyckade eller misslyckade API-anrop för webbtjänsten. Alla program som använder samma uppsättning domänfält bör generera samma uppsättning händelser, vilket gör att en uppsättning vanliga rapporter och analyser kan skapas.

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 att instrumentera ett distribuerat program som körs i molnet.

• Gör loggarna lätta att läsa och enkla att 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. Detta 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 den loggas, men se till att relevant information behålls. Ta till exempel bort ID och lösenord från alla databasanslutningssträngar, men skriv återstående information till loggen så att en analytiker kan fastställa att systemet har åtkomst till rätt databas. Logga alla kritiska undantag, men gör det möjligt för 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. Dessa data kan vara användbara för att övervaka systemets tillfälliga hälsa.

• Spåra utgående processanrop, 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.

• Med undantag för granskningshändelser kontrollerar du att alla loggningsanrop är åtgärder som inte blockerar förloppet för affärsåtgärder. Granskningshändelser är exceptionella eftersom de är viktiga för verksamheten och kan klassificeras som en grundläggande del av verksamheten.

• Kontrollera 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 kan implementeras på alla lämpliga sätt.

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

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

Samla in och lagra data

Insamlingssteget i övervakningsprocessen handlar om att hämta den information som instrumentation genererar, formatera dessa data för att göra det enklare för analys-/diagnossteget att förbruka och spara transformerade data i tillförlitlig lagring. Instrumentationsdata som du samlar in från olika delar av ett distribuerat system kan lagras på en mängd olika platser och med varierande format. Programkoden kan till exempel generera spårningsloggfiler och generera loggdata för programhändelser, medan prestandaräknare som övervakar viktiga aspekter av infrastrukturen som programmet använder kan samlas in via andra tekniker. Alla komponenter och tjänster från tredje part 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.

Datainsamling utförs ofta via en samlingstjänst som kan köras autonomt från programmet som genererar instrumentationsdata. Bild 2 illustrerar ett exempel på den här arkitekturen med undersystemet instrumentation datainsamling.

Bild 2 – Samla in instrumentationsdata.

Observera att det här är en förenklad vy. Insamlingstjänsten är inte nödvändigtvis en enda process och kan bestå av många komponenter som körs på olika datorer, enligt beskrivningen i följande avsnitt. Om analysen av vissa telemetridata måste utföras snabbt (snabb analys, enligt beskrivningen i avsnittet Stöd för varm, varm och kall analys senare i det här dokumentet), kan lokala komponenter som körs utanför insamlingstjänsten utföra analysuppgifterna omedelbart. Bild 2 visar den här situationen för valda händelser. Efter analysbearbetningen kan resultaten skickas direkt till delsystemet visualisering och avisering. Data som utsätts för varm eller kall analys lagras i lagringen i väntan på bearbetning.

För Azure-program och -tjänster tillhandahåller Azure Diagnostics en möjlig lösning för att samla in data. Azure Diagnostics samlar in data från följande källor för varje beräkningsnod, aggregerar dem och laddar sedan upp dem till Azure Storage:

• IIS-loggar
• IIS-misslyckade begärandeloggar
• Windows-händelseloggar
• Prestandaräknare
• Kraschdumpar
• Azure Diagnostics-infrastrukturloggar
• Skräddarsydda felloggar
• .NET EventSource
• Manifestbaserad ETW

Mer information finns i artikeln Azure: Grunderna för telemetri och felsökning.

Strategier för insamling av instrumentationsdata

Med tanke på molnets elastiska karaktär och för att undvika behovet av att manuellt hämta telemetridata från varje nod i systemet bör du se till att data överförs till en central plats och konsolideras. I ett system som omfattar flera datacenter kan det vara användbart att först samla in, konsolidera och lagra data region för region och sedan aggregera regionala data till ett enda centralt system.

För att optimera användningen av bandbredd kan du välja att överföra mindre brådskande data i segment som batchar. Data får dock inte fördröjas på obestämd tid, särskilt om de innehåller tidskänslig information.

Hämta och push-överföra instrumentationsdata

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

En metod för att implementera 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 (hämtar) telemetridata som samlas in på den lokala noden och skriver den här informationen direkt till centraliserad lagring som alla instanser av programresursen. Det här är den mekanism som Azure Diagnostics implementerar. Varje instans av en Azure-webb- eller arbetsroll kan konfigureras för att samla in diagnostikinformation och annan spårningsinformation som lagras lokalt. Övervakningsagenten som körs tillsammans med varje instans kopierar angivna data till Azure Storage. Artikeln Enabling Diagnostics in Azure Cloud Services and Virtual Machines (Aktivera diagnostik i Azure Cloud Services och virtuella datorer ) innehåller mer information om den här processen. Vissa element, till exempel IIS-loggar, kraschdumpar och anpassade felloggar, skrivs till bloblagring. Data från Windows-händelseloggen, ETW-händelser och prestandaräknare registreras i tabelllagring. Bild 3 illustrerar den här mekanismen.

Bild 3 – Använda en övervakningsagent för att hämta information och skriva till delad lagring.

Det är möjligt att använda metoden som beskrivs 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 dock generera enorma mängder data från hundratals webb- och arbetsroller, databasskärvor och andra tjänster. Den här dataströmmasen kan enkelt överbelasta I/O-bandbredden som är tillgänglig med en enda central plats. Därför måste telemetrilösningen vara skalbar för att förhindra att den fungerar som en flaskhals när systemet expanderar. I bästa fall bör lösningen innehålla en viss redundans för att minska riskerna med att förlora viktig övervakningsinformation (till exempel gransknings- eller faktureringsdata) om en del av systemet misslyckas.

För att lösa dessa problem kan du implementera köer, enligt bild 4. I den här arkitekturen publicerar den lokala övervakningsagenten (om den kan konfigureras på rätt sätt) eller en anpassad datainsamlingstjänst (om inte) data till en kö. En separat process som körs asynkront (tjänsten för lagringsskrivning i bild 4) tar data i den här kön och skriver dem till delad lagring. En meddelandekö är lämplig för det här scenariot eftersom den innehåller "minst en gång" semantik 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 arbetsroll.

Bild 4 – Använda en kö för att buffra instrumentationsdata.

Den lokala datainsamlingstjänsten kan lägga till data i en kö omedelbart efter att den har tagits emot. 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 måste hanteras snabbare. Mer information finns i mönstret Prioritetskö. Du kan också använda olika kanaler (till exempel Service Bus-ämnen) för att dirigera data till olika mål beroende på vilken form av analysbearbetning som krävs.

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

Konsolidera instrumentationsdata

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. För att utvärdera systemets övergripande hälsa är det nödvändigt att konsolidera vissa aspekter av data i de lokala vyerna. Du kan utföra detta när data har lagrats, men i vissa fall kan du också uppnå det när data samlas in. I stället för att skrivas direkt till delad lagring kan instrumentationsdata passera genom en separat datakonsolideringstjänst som kombinerar data och fungerar som en filter- och rensningsprocess. Instrumentationsdata som innehåller samma korrelationsinformation, till exempel ett aktivitets-ID, kan till exempel amalgameras. (Det är möjligt att en användare börjar utföra en affärsåtgärd på en nod och sedan överförs till en annan nod i händelse av nodfel, eller beroende på hur belastningsutjämning har konfigurerats.) Den här processen kan också identifiera och ta bort duplicerade data (alltid en möjlighet om telemetritjänsten använder meddelandeköer för att skicka ut instrumentationsdata till lagring). Bild 5 illustrerar ett exempel på den här strukturen.

Bild 5 – Använda en separat tjänst för att konsolidera och rensa instrumentationsdata.

Lagra instrumentationsdata

De tidigare diskussionerna har illustrerat en ganska förenklad syn på hur instrumentationsdata lagras. I verkligheten kan det vara klokt att lagra de olika typerna av information med hjälp av tekniker som är mest lämpliga för det sätt på vilket varje typ sannolikt kommer att användas.

Till exempel har Azure Blob och Table Storage vissa likheter i hur de används. Men de har begränsningar i de åtgärder som du kan utföra med hjälp av dem, och kornigheten för de data som de har är helt annorlunda. Om du behöver utföra mer analytiska åtgärder eller kräver sökfunktioner för fullständig text på dina data kan det vara mer användbart att använda datalagring med funktioner som är optimerade för specifika typer av frågor och dataåtkomst. Till exempel:

• Prestandaräknardata kan lagras i en SQL-databas för att aktivera ad hoc-analyser.
• Spårningsloggar kan lagras bättre i Azure Cosmos DB.
• Säkerhetsinformation kan skrivas till HDFS.
• Information som kräver fulltextsökning kan lagras via Elasticsearch (som också kan påskynda sökningar med hjälp av omfattande indexering).

Du kan implementera ytterligare en 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 enligt bild 6. En annan metod är att inkludera den här funktionen i konsoliderings- och rensningsprocessen och skriva data direkt till lagringsplatserna när de hämtas, istället för att spara dem i en mellanliggande delad lagringsplats. Varje metod har sina för- och nackdelar. Om du implementerar en separat partitioneringstjänst minskar belastningen på konsoliderings- och rensningstjänsten, och det gör att åtminstone en del av de partitionerade data kan återskapas om det behövs (beroende på hur mycket data som behålls i delad lagring). Den förbrukar dock ytterligare resurser. Dessutom kan det vara en fördröjning mellan mottagandet av instrumentationsdata från varje programinstans och konverteringen av data till tillämplig information.

Bild 6 – Partitionera data enligt analys- och lagringskrav.

Samma instrumentationsdata kan krävas för flera ändamål. Prestandaräknare kan till exempel användas för att ge en historisk vy över systemprestanda över tid. Genom att kombinera den här informationen med andra användningsdata kan du generera kundens faktureringsinformation. I dessa situationer kan samma data skickas till fler än ett mål, till exempel en dokumentdatabas som kan fungera som ett långsiktigt lager för att lagra faktureringsinformation och ett flerdimensionellt lager för hantering av komplexa prestandaanalyser.

Du bör också överväga hur snabbt data krävs. Data som tillhandahåller information för aviseringar måste nås snabbt, så de bör lagras i snabb datalagring och indexeras eller struktureras för att optimera de frågor som aviseringssystemet utför. I vissa fall kan det vara nödvändigt för telemetritjänsten som samlar in data på varje nod för att formatera och spara data lokalt så att en lokal instans av aviseringssystemet snabbt kan meddela dig om eventuella problem. Samma data kan skickas till tjänsten för att skriva till lager, som visas i tidigare diagram, och lagras centralt om det krävs av andra orsaker.

Information som används för mer övervägd analys, för rapportering och för att upptäcka historiska trender är mindre brådskande och kan lagras på ett sätt som stöder datautvinning och ad hoc-frågor. Mer information finns i avsnittet Stöd för varm, varm och kall analys senare i det här dokumentet.

Loggrotation och datakvarhållning

Instrumentation kan generera stora mängder data. Dessa data kan lagras på flera platser, från och med rådataloggfiler, spårningsfiler och annan information som samlas in på varje nod till den konsoliderade, rensade och partitionerade vyn av dessa data som lagras i delad lagring. I vissa fall kan de ursprungliga rådata tas bort från varje nod när data har bearbetats och överförts. I andra fall kan det vara nödvändigt eller helt enkelt användbart att spara rådata. Till exempel kan data som genereras i felsökningssyfte vara bäst tillgängliga i dess råa form men sedan ignoreras snabbt efter att eventuella buggar har åtgärdats.

Prestandadata har ofta en längre livslängd så att de kan användas för att upptäcka prestandatrender och för kapacitetsplanering. Samlad vy över dessa data lagras vanligtvis online under en begränsad period för snabb åtkomst. Efteråt kan den arkiveras eller tas bort. Data som samlas in för mätning och fakturering av kunder kan behöva sparas på obestämd tid. Dessutom kan regelkrav kräva att information som samlas in för gransknings- och säkerhetsändamål också måste arkiveras och sparas. Dessa data är också känsliga och kan behöva krypteras eller på annat sätt skyddas för att förhindra manipulering. Du bör aldrig registrera användarnas lösenord eller annan information som kan användas för att begå identitetsbedrägerier. Sådan information bör rensas från data innan den lagras.

Nedsampling

Det är användbart att lagra historiska data så att du kan upptäcka långvariga trender. I stället för att spara gamla data i sin helhet kan det vara möjligt att minska urvalet av data för att minska dess upplösning och spara lagringskostnader. 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 bör 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. Du kan till exempel generera information i ett självbeskrivande format som JSON, MessagePack eller Protobuf i stället för ETL/ETW. Med ett standardformat kan systemet konstruera bearbetningspipelines. komponenter som läser, transformerar och skickar data i överenskommet format kan enkelt integreras.

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

• I händelse av ett tillfälligt fel när information skickas till en datamottagare bör övervakningsagenten eller datainsamlingstjänsten förberedas för att ordna om telemetridata så att den senaste informationen skickas först. (Övervakningsagenten/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 övervaknings- och diagnostikprocessen är att analysera insamlade data för att få en bild av systemets övergripande välbefinnande. Du bör ha definierat dina egna KPI:er och prestandamått, och det är viktigt att förstå hur du kan strukturera de data som har samlats in för att uppfylla dina analyskrav. Det är också viktigt att förstå hur data som samlas in i olika mått och loggfiler korreleras, eftersom den här informationen kan vara nyckeln till att spåra en sekvens av händelser och hjälpa till att diagnostisera problem som uppstår.

Som beskrivs i avsnittet Konsolidera instrumentationsdata samlas data för varje del av systemet vanligtvis in lokalt, men de måste vanligtvis kombineras med data som genereras på andra platser som deltar i systemet. Den här informationen kräver noggrann korrelation för att säkerställa att data kombineras korrekt. Till exempel kan användningsdata för en åtgärd sträcka sig över 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 och datalagring som lagras på en annan nod. Den här informationen måste kopplas samman för att ge en övergripande vy över resursen och bearbetningsanvändningen för åtgärden. Viss förbearbetning och filtrering av data kan ske på noden där data samlas in, medan aggregering och formatering är mer benägna att ske på en central nod.

Stöd för varm, 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 är tidskritiska och kräver omedelbar analys av data för att vara effektiva. Detta kallas frekvent analys. Exempel är de analyser som krävs för aviseringar och vissa aspekter av säkerhetsövervakning (till exempel att identifiera ett angrepp på systemet). Data som krävs för dessa ändamål måste vara snabbt tillgängliga och strukturerade för effektiv bearbetning. I vissa fall kan det vara nödvändigt att flytta analysbearbetningen till de enskilda noder där data lagras.

Andra former av analys är mindre tidskritiska och kan kräva viss beräkning och aggregering när rådata har tagits emot. Detta kallas varm analys. Prestandaanalys ingår ofta i den här kategorin. I det här fallet är det osannolikt att en isolerad, enskild prestandahändelse är statistiskt signifikant. (Det kan bero på en plötslig topp eller ett plötsligt fel.) Data från en serie händelser bör ge en mer tillförlitlig bild av systemets prestanda.

Varm analys kan också användas för att diagnostisera hälsoproblem. En hälsohändelse bearbetas vanligtvis via frekvent analys och kan generera en avisering omedelbart. En operator bör kunna granska orsakerna till hälsohändelsen genom att undersöka data från den varma sökvägen. Dessa data bör innehålla information om de händelser som ledde fram till problemet som orsakade hälsohändelsen.

Vissa typer av övervakning genererar mer långsiktiga data. Den här analysen kan utföras vid ett senare tillfälle, eventuellt enligt ett fördefinierat schema. I vissa fall kan analysen behöva utföra komplex filtrering av stora mängder data som samlas in under en viss tidsperiod. Detta kallas kall analys. Det viktigaste kravet är att data lagras på ett säkert sätt när de har avbildats. Användningsövervakning och granskning kräver till exempel en korrekt bild av systemets tillstånd vid regelbundna tidpunkter, men den här tillståndsinformationen behöver inte vara tillgänglig för bearbetning omedelbart efter att den har samlats in.

En operator kan också använda kall analys för att tillhandahålla data för förutsägelsehälsoanalys. Operatorn kan samla in historisk information under en angiven period och använda den tillsammans med aktuella hälsodata (hämtas från den heta sökvägen) för att upptäcka trender som snart kan orsaka hälsoproblem. I dessa fall kan det vara nödvändigt att skapa en avisering så att korrigerande åtgärder kan vidtas.

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. Till exempel:

• Vad har orsakat en intensiv I/O-inläsning på systemnivå vid en viss tidpunkt?
• Är det resultatet av ett stort antal databasåtgärder?
• Återspeglas detta i databassvarstiderna, antalet transaktioner per sekund och programsvarstiderna vid samma tidpunkt?

I så fall kan en åtgärd som kan minska belastningen vara att fragmentera data över fler servrar. Dessutom kan undantag uppstå till följd av ett fel på alla nivåer i systemet. Ett undantag på en nivå utlöser ofta ett annat fel på nivån ovan.

Därför måste du kunna korrelera de olika typerna av övervakningsdata på varje nivå för att skapa en övergripande vy över systemets tillstånd och de program som körs på den. Du kan sedan använda den här informationen för att fatta beslut om huruvida systemet fungerar acceptabelt eller inte, och avgöra vad som kan göras för att förbättra systemets kvalitet.

Enligt beskrivningen i avsnittet Information för korrelering av data måste du se till att rådata innehåller tillräcklig kontext- och aktivitets-ID-information för att stödja nödvändiga aggregeringar för korrelering av händelser. Dessutom kan dessa data lagras i olika format, och det kan vara nödvändigt att parsa den här informationen för att konvertera den till ett standardiserat format för analys.

Felsökning och diagnostisera problem

Diagnos kräver möjligheten att fastställa orsaken till fel eller oväntat beteende, inklusive att utföra rotorsaksanalys. Den information som krävs omfattar vanligtvis:

• Detaljerad information från händelseloggar och spårningar, antingen för hela systemet eller för ett angivet undersystem under en angiven tidsperiod.
• Slutför stackspårningar till följd av undantag och fel på en angiven nivå som inträffar i systemet eller ett angivet undersystem under en angiven period.
• Kraschdumpar för misslyckade processer var som helst i systemet eller för ett angivet undersystem under ett angivet tidsfönster.
• Aktivitetsloggar som registrerar de åtgärder som utförs antingen av alla användare eller för valda användare under en angiven period.

Att analysera data i felsökningssyfte kräver ofta en djup teknisk förståelse av systemarkitekturen och de olika komponenter som utgör lösningen. Därför krävs ofta en stor grad av manuella åtgärder för att tolka data, fastställa orsaken till problem och rekommendera en lämplig strategi för att korrigera dem. Det kan vara lämpligt att helt enkelt 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 höja aviseringar

En viktig aspekt av alla övervakningssystem är möjligheten att presentera data på ett sådant sätt att en operatör snabbt kan upptäcka trender eller problem. Också viktigt är möjligheten att snabbt informera en operatör om en betydande händelse har inträffat som kan kräva uppmärksamhet.

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 kan visa information som en serie diagram, diagram eller någon annan bild. Dessa objekt kan parametriseras och en analytiker bör kunna välja viktiga parametrar (till exempel tidsperioden) för en viss situation.

Instrumentpaneler kan ordnas hierarkiskt. Instrumentpaneler på den översta nivån kan ge en övergripande vy över varje aspekt av systemet, men göra det möjligt för en operatör att öka detaljnivån för informationen. En instrumentpanel som visar systemets övergripande disk-I/O bör till exempel göra det möjligt för en analytiker att visa I/O-priserna för varje enskild disk för att fastställa om en eller flera specifika enheter står för en oproportionerlig trafikvolym. Helst bör instrumentpanelen också visa relaterad information, till exempel källan för varje begäran (användaren eller aktiviteten) som genererar denna I/O. Den här informationen kan sedan användas för att avgöra om (och hur) belastningen ska spridas jämnare mellan enheter och om systemet skulle fungera bättre om fler enheter lades till.

En instrumentpanel kan också använda färgkodning eller andra visuella tips för att ange värden som visas som avvikande eller som ligger utanför ett förväntat intervall. Använd föregående exempel:

• En disk med en I/O-hastighet som närmar sig sin maximala kapacitet under en längre period (en frekvent disk) kan markeras i rött.
• En disk med en I/O-hastighet som regelbundet körs med sin maximala gräns under korta perioder (en varm disk) kan markeras i gult.
• En disk som uppvisar normal användning kan visas i grönt.

Observera att för att ett instrumentpanelssystem ska fungera effektivt måste det ha rådata att arbeta med. 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 de ska formateras för att instrumentpanelen ska kunna användas.

En bra instrumentpanel visar inte bara information, den gör det också möjligt för en analytiker att ställa ad hoc-frågor om den informationen. Vissa system tillhandahåller hanteringsverktyg som en operatör kan använda för att utföra dessa uppgifter och utforska underliggande data. Beroende på vilken lagringsplats som används för att lagra den här informationen kan det också vara möjligt att köra frågor mot dessa data direkt eller importera dem till verktyg som Microsoft Excel för ytterligare analys och rapportering.

Höja aviseringar

Aviseringar är processen att analysera övervaknings- och instrumentationsdata och generera ett meddelande om en betydande händelse identifieras.

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 garantier för prestanda, tillgänglighet och sekretess för de användare där data kan behöva åtgärdas omedelbart. En operatör kan behöva meddelas om händelsen som utlöste aviseringen. Aviseringar kan också användas för att anropa systemfunktioner som autoskalning.

Aviseringar beror vanligtvis på följande instrumentationsdata:

• Säkerhetshändelser. Om händelseloggarna anger att upprepade autentiserings- eller auktoriseringsfel inträffar kan systemet vara under attack och en operatör bör informeras.
• Prestandamått. Systemet måste snabbt svara om ett visst prestandamått överskrider ett angivet tröskelvärde.
• Tillgänglighetsinformation. Om ett fel upptäcks kan det vara nödvändigt att snabbt starta om ett eller flera undersystem eller redundansväxla till en säkerhetskopieringsresurs. Upprepade fel i ett undersystem kan tyda på allvarligare problem.

Operatörer kan få aviseringsinformation med hjälp av många leveranskanaler, till exempel e-post, en pager-enhet 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 kan få samma uppsättning aviseringar.

Ett aviseringssystem bör vara anpassningsbart och lämpliga värden från underliggande instrumentationsdata kan anges som parametrar. Med den här metoden kan en operatör filtrera data och fokusera på de tröskelvärden eller kombinationer av värden som är av intresse. Observera att rådata i vissa fall kan tillhandahållas till aviseringssystemet. I andra situationer kan det vara lämpligare att tillhandahålla aggregerade data. (En avisering kan till exempel utlösas om CPU-användningen för en nod har överskridit 90 procent under de senaste 10 minuterna). Informationen som tillhandahålls till aviseringssystemet bör också innehålla lämplig sammanfattning och kontextinformation. Dessa data kan bidra till att minska risken för att falska positiva händelser kommer att skicka en avisering.

Rapportering

Rapportering används för att skapa en övergripande vy av systemet. Den kan innehålla historiska data utöver aktuell information. Själva rapporteringskraven tillhör två breda kategorier: verksamhetsrapportering och säkerhetsrapportering.

Driftrapportering omfattar vanligtvis följande aspekter:

• Aggregeringsstatistik som du kan använda för att förstå resursutnyttjandet av det övergripande systemet eller angivna undersystem under ett angivet tidsfönster.
• Identifiera trender i resursanvändningen för det övergripande systemet eller angivna undersystem under en angiven period.
• Övervaka de undantag som har inträffat i hela systemet eller i angivna undersystem under en angiven period.
• Fastställa programmets effektivitet när det gäller distribuerade resurser och förstå om mängden resurser (och deras associerade kostnad) kan minskas utan att prestandan påverkas i onödan.

Säkerhetsrapportering handlar om att spåra kundernas användning av systemet. Den kan omfatta:

• Granska användaråtgärder. Detta kräver att du registrerar de enskilda begäranden som varje användare utför, tillsammans med datum och tider. Data bör struktureras så att en administratör snabbt kan rekonstruera den åtgärdssekvens som en användare utför under en angiven period.
• Spåra resursanvändning av användare. Detta kräver att du registrerar hur varje begäran för en användare kommer åt de olika resurser som utgör systemet och hur länge. En administratör måste kunna använda dessa data för att generera en användningsrapport av användaren under en angiven period, eventuellt i faktureringssyfte.

Ofta kan batchprocesser generera rapporter enligt ett definierat schema. (Svarstiden är normalt inte ett problem.) Men de bör också vara tillgängliga för generering på ad hoc-basis om det behövs. Om du till exempel 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

• Översikt över Azure Monitor
• Övervaka, diagnostisera och felsöka Microsoft Azure Storage
• Översikt över aviseringar i Microsoft Azure
• Visa aviseringar om hälsotillståndet för tjänsten med hjälp av Azure Portal
• Vad är Application Insights?
• Prestandadiagnostik för virtuella Azure-datorer
• Ladda ned och installera SQL Server Data Tools (SSDT) för Visual Studio

Relaterade resurser

• Vägledning för automatisk skalning beskriver hur du minskar hanteringskostnaderna genom att minska behovet av att en operatör kontinuerligt övervakar systemets prestanda och fattar 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ö visar hur du prioriterar köade meddelanden så att brådskande begäranden tas emot och kan bearbetas före mindre brådskande meddelanden.