Share via

Rekommendationer för instrumentering av ett program

  • Artikel

Gäller för den här rekommendationen om checklista för driftseffektivitet i Azure Well-Architected Framework:

OE:07 Utforma och implementera ett övervakningssystem för att validera designval och informera om framtida design- och affärsbeslut. Det här systemet samlar in och exponerar drifttelemetri, mått och loggar som genererar från arbetsbelastningens infrastruktur och kod.

Relaterad guide: Rekommendationer för att utforma och skapa ett övervakningssystem

Den här guiden beskriver rekommendationerna för att aktivera observerbarhet för ditt program med hjälp av instrumentation. Generera meningsfull telemetri som kan matas in och integreras i ditt övervakningssystem. Genom att använda instrumentation kan du samla in information utan att logga in på en fjärrproduktionsserver för att manuellt utföra spårning eller felsökning. Instrumentationsdata innehåller mått och loggar som du kan använda för att utvärdera prestanda, diagnostisera problem och fatta arbetsbelastningsbeslut.

Viktiga designstrategier

För att optimera telemetrin för din arbetsbelastning instrumentera ditt program för att generera följande data:

  • Loggar är tidsstämplade poster för diskreta händelser. Det finns tre typer av loggar: oformaterad text, strukturerad och binär.

  • Med distribuerade spårningsloggar kan du se sökvägen till en begäran när den skickas genom olika tjänster och komponenter.

  • Mått är numeriska värden som beskriver en aspekt av ett system vid en viss tidpunkt.

Anteckning

Du kan använda verktyg som Application Insights, Dynatrace och Elastic Application Performance Monitoring för att automatiskt instrumentera ditt program. De här verktygen gör instrumentationen enklare, men de kan också begränsas. Om du använder ett verktyg för automatisk instrumentering kan du lägga till fler funktioner via manuell instrumentering efter behov.

Loggar och distribuerade spårningsloggar

Använd strukturerad loggning för att enkelt integrera loggar i övervaknings- och analysplattformar. Instrumentera programmet så att detaljnivån kan ändras. Konstant utförlig loggning kan slösa lagringsresurser, så den bör slås på och stängas av efter behov för felsökning.

Spårningsloggar innehåller textdata eller binära data som skapas från en spårningshändelse, om programmet använder händelsespårning för Windows (ETW). Systemloggar genererar spårningslogginnehåll från händelser i infrastrukturen, till exempel webbservern. Textlogginnehåll är utformat för att vara läsbart av människor, men du bör se till att det är skrivet i ett format som även ett automatiserat system kan parsa.

Kategorisera loggar och använd separata loggar för att registrera spårningsutdata från varje driftsaspekt i systemet. Om du kategoriserar loggarna kan du snabbt filtrera loggmeddelanden 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ökningsdata, till samma logg.

Anteckning

En logg kan implementeras som en fil i filsystemet eller lagras i något annat format, till exempel en blob i Blob Storage. Logginformation kan också lagras i strukturerad lagring, till exempel rader i en tabell.

Mått

Mått, eller exempel, räknas av någon aspekt eller resurs i systemet vid en viss tidpunkt, med en eller flera associerade taggar eller dimensioner. En enskild instans av ett mått är inte användbar isolerat. Mått bör samlas in över tid. Överväg vilka mått du bör registrera och hur ofta. Data som genereras för ofta kan medföra en tung belastning på systemet, men infångade data som inträffar sällan kan göra att du missar de omständigheter som leder till en betydande händelse. Lämplig frekvens för att samla in data kan variera från mått till mått. Cpu-anvä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 konsekvent under många minuter.

Information för att korrelera data

Du kan enkelt övervaka enskilda prestandaräknare och prestandaräknare på systemnivå, samla in mått för resurser och hämta programspårningsinformation från olika loggfiler. Viss övervakning kräver datakorrelation under analys- och diagnostiksteget i övervakningspipelinen. Dessa data kan ha flera former och analysprocessen måste tillhandahållas tillräckligt med instrumentationsdata för att 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 slutför uppgiften.

Det är osannolikt att det är en 1:1-karta mellan trådar och användarbegäranden, eftersom asynkrona åtgärder kan återanvända samma trådar för mer än en användare. För att ytterligare komplicera saken kan en enskild begäran korrelera med mer än en tråd när den flödar genom systemet. Om det är möjligt ska du associera ett begärande med ett unikt aktivitets-ID som sprids i systemet som en del av begärandets kontext. Tekniken för att generera och inkludera aktivitets-ID:t i spårningsinformation beror på vilken teknik som används för att samla in spårningsdata.

Alla övervakningsdata bör tidsstämplas på samma sätt. Du skapar konsekvens genom att registrera alla datum och tidpunkter med hjälp av Koordinerad universell tid.

Anteckning

Datorer som körs i olika tidszoner och nätverk kanske inte synkroniseras. Var inte beroende av tidsstämplar enbart för korrelering av instrumentationsdata som sträcker sig över flera datorer.

Information som ska ingå i instrumentationsdata

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

Läsbara data för människor

Se till att informationen som samlas in av spårningshändelser är både maskin- och läsbar. Använd väldefinierade scheman för den här informationen för att implementera automatiserad bearbetning av loggdata mellan system och för att ge konsekvens för drift- och ingenjörspersonal som läser loggarna.

Inkludera följande miljöinformation i dina data:

  • Distributionsmiljö
  • Bearbetningsdator
  • Information om processen
  • Anropsstack

Investera i spårbarhet och korrelation

Ge tillräcklig kontext, till exempel ett aktivitets-ID som är associerat med en specifik instans av en begäran, så att utvecklaren eller administratören kan fastställa källan för varje begäran.

Datakontexten kan också innehålla information som används för att korrelera 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 direkt eller indirekt innehålla en referens till kunden som orsakade begäran. Den här kontexten ger värdefull information om programmets hälsa vid tillfället då dina övervakningsdata lästes in.

Samla in alla relevanta data

Registrera alla begäranden och de platser eller regioner där de görs. Du kan använda den här informationen för att identifiera 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 hämta noggrant information om undantag. Kritisk felsökningsinformation går ofta förlorad på grund av dålig undantagshantering. Samla in all undantagsinformation som programmet genererar, inklusive eventuella inre undantag eller annan sammanhangsbaserad information, till exempel anropsstacken, om möjligt.

Sträva efter datakonsekvens

Konsekventa data 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. Loggningspaket kan hjälpa dig att undvika beroende av utvecklare att använda din metod eftersom de implementerar olika delar av systemet.

Samla in data, till exempel indata-/utdatavolym, antal begäranden och minne, nätverk och CPU-användning, från viktiga prestandaräknare. Vissa infrastrukturtjänster tillhandahåller egna prestandaräknare, till exempel:

  • Antalet anslutningar till en databas.
  • Transaktionshastigheten.
  • Antalet transaktioner som lyckas eller misslyckas.

Program kan också definiera sina egna prestandaräknare.

Överväg externa beroenden

Logga alla externa tjänstanrop. Externa anrop kan göras till:

  • Databassystem.
  • Webbtjänster.
  • Andra tjänster på systemnivå som ingår i infrastrukturen.

Registrera information om varaktigheten för varje anrop och om anropets framgång eller misslyckande. Hämta möjligt in information om alla nya försök och fel för tillfälliga fel som uppstår.

Se till att telemetrisystemet är kompatibelt

I många fall genereras instrumentationsinformationen som en serie händelser och skickas till ett separat telemetrisystem för bearbetning och analys. Ett telemetrisystem är vanligtvis oberoende av alla specifika program eller tekniker.

Telemetrisystem använder definierade scheman för att parsa information. Schemat anger ett kontrakt som definierar de datafält och typer som telemetrisystemet kan mata in. Generalisera schemat så att data som kommer från olika plattformar och enheter tillåts. Ett gemensamt schema bör innehålla fält som är relevanta för alla instrumentationshändelser, till exempel:

  • Händelsenamn.
  • Händelsetid.
  • Avsändarens IP-adress.
  • Information som krävs för händelsekorrelation, inklusive:
    • Användar-ID
    • Enhets-ID
    • Program-ID:t

Kom ihåg att många enheter kan skapa händelser för samma program, så schemat bör inte vara beroende av enhetstypen. Programmet bör ha stöd för roaming eller distribution mellan enheter. Schemat kan också innehålla relevanta domänfält för ett visst scenario som är vanligt i olika program, till exempel:

  • Information om undantag.
  • Start- och sluthändelser för program.
  • Lyckade eller misslyckade API-anrop för webbtjänsten.

Upprätta domänfält som producerar samma uppsättning händelser för att skapa en uppsättning vanliga rapporter och analyser i olika program. Du kan behöva konfigurera ett schema så att det innehåller anpassade fält för att samla in information om programspecifika händelser.

OpenTelemetry är en leverantörsneutral samling API:er, SDK:er och andra verktyg. Du kan använda OpenTelemetry för att instrumentera program och generera meningsfull telemetri konsekvent mellan olika språk. OpenTelemetry är verktygsoberoende, så det är kompatibelt med många observerbarhetsplattformar, inklusive erbjudanden med öppen källkod och kommersiella erbjudanden. Microsoft använder OpenTelemetry som standardverktyg för instrumentering.

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 loggar lätta att läsa och enkla att parsa. Använd om möjligt strukturerad loggning.

  • Var kort och beskrivande i loggmeddelanden.

  • Identifiera loggkällan.

  • Lägg till tidsstämpelinformation när varje loggpost skrivs.

  • Använd samma tidszon och format för alla tidsstämplar.

  • Kategorisera loggar och skriv meddelanden på rätt plats.

  • Avslöja inte känslig information om systemet eller personlig information om användare. Rensa den här informationen innan den loggas, men behåll all relevant information.

  • Logga alla kritiska undantag men gör det möjligt för administratören att aktivera och inaktivera loggning efter behov för färre undantag och varningar.

  • Samla in och logga all logikinformation om återförsök. Dessa data är användbara för att övervaka systemets tillfälliga hälsa.

  • Spåra processanrop, till exempel begäranden till externa webbtjänster eller databaser.

  • Blanda inte loggmeddelanden med olika säkerhetskrav i samma loggfil.

  • Se till att alla loggningsanrop är brand-och-glöm-åtgärder som inte blockerar förloppet för affärsåtgärder. Undanta granskningshändelser från den här regeln eftersom de är viktiga för verksamheten.

  • Se till att loggningen är utökningsbar och inte har några direkta beroenden för ett konkret mål.

  • Kontrollera att all loggning är felsäker och inte utlöser sammanhängande fel.

  • Behandla instrumentation som en pågående iterativ process och granska loggar regelbundet.

Överväganden

  • Implementera profilering endast när det behövs eftersom det kan medföra betydande omkostnader för systemet. Genom att använda instrumentation registrerar profilering en händelse, till exempel ett metodanrop, varje gång den inträffar. Sampling registrerar dock endast valda händelser.

  • Profileringsval kan vara tidsbaserade, till exempel en gång var n sekund eller frekvensbaserad, till exempel en gång var n begäranden. Om händelser inträffar ofta kan profilering orsaka för stor belastning på systemet och påverka den övergripande prestandan. I det här fallet är samplingsmetoden att föredra. Om frekvensen för händelser däremot är låg kan sampling gå miste om dem. I det här fallet kan profilering vara den bättre metoden.

Azure-underlättande

Automatisk instrumentering är tillgängligt för många typer av Azure- och lokala program som övervakas med Application Insights. Funktionen autoinstrumentation konfigurerar automatiskt programmet så att det ger omfattande telemetri till Application Insights och ger enkel åtkomst till funktioner som programinstrumentpanelen och programkartan. Information om vilka värdplattformar och utvecklingsspråk som stöds finns i Miljöer, språk och resursprovidrar som stöds.

Checklista för utmärkt drift

Se den fullständiga uppsättningen rekommendationer.

Checklista för utmärkt drift