Dela via

Rekommendationer för instrumentering av ett program

  • Artikel

Gäller för denna checklista för Azure Well-Architected Framework Operational Excellence:

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

Om du vill optimera telemetrin för din arbetsbelastning kan du instrumentera programmet 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 färdas genom olika tjänster och komponenter.

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

Kommentar

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

Använda strukturerade loggar och spårning

Använd strukturerad loggning för att enkelt integrera loggar i övervaknings- och analysplattformar. Instrumentera programmet så att nivåerna av verbositet kan ändras. Konstant utförlig loggning kan slösa lagringsresurser, så den bör slås på och 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 kunna läsas 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ökning av data, till samma logg.

Kommentar

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.

Samla in programmått

Mått, eller exempel, är ett antal 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 i isolering, mått bör samlas in över tid. Tänk på vilka mått du bör registrera och hur ofta. Data som genereras för ofta kan medföra en hög belastning på systemet, men sällan samlad data kan göra att du missar de omständigheter som leder till en betydande händelse. Lämplig frekvens för insamling av data kan variera 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 konsekvent under många minuter.

Underlätta korrelation mellan komponenter

Du kan enkelt övervaka prestandaräknare på individuell och 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 diagnostikfasen 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 saker och ting 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: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. Du skapar konsekvens genom att registrera alla datum och tidpunkter med hjälp av Koordinerad universell tid.

Kommentar

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

Samla in relevanta data

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 information som samlas in av spårningshändelser är både maskin- och mänsklig läsbar. Anta 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. Viktig 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 kontextuell 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 när de implementerar olika delar av systemet.

Samla in data, till exempel in- och 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.
  • Transaktionsfrekvensen.
  • 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 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 instrumenteringsinformationen 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 för att tillåta data som anländer från olika plattformar och enheter. 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 generera 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 skapar 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 instrumentation.

Optimera instrumentationskod

I följande lista sammanfattas metodtips för instrumentering av 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 källan till loggen.

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

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

  • Kategorisera loggar och skriva 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 för å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.

Använda programprofilering

  • 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:e sekund eller frekvensbaserade, till exempel en gång varje 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 ditt program 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 driftskvalitet

Se den fullständiga uppsättningen rekommendationer.

Checklista för driftskvalitet