Telemetrikorrelation i Application Insights

Artikel
11/03/2021
9 minuter för att läsa

I mikrotjänsters värld kräver varje logisk åtgärd att arbete utförs i olika komponenter i tjänsten. Du kan övervaka var och en av dessa komponenter separat med hjälp av Application Insights. Program Insights stöder distribuerad telemetrikorrelation, som du använder för att identifiera vilken komponent som ansvarar för fel eller prestandaförsämring.

Den här artikeln förklarar datamodellen som används av Application Insights korrelera telemetri som skickas av flera komponenter. Den omfattar tekniker och protokoll för kontextspridning. Den omfattar också implementeringen av korrelationstaktik på olika språk och plattformar.

Datamodell för telemetrikorrelation

Program Insights definierar en datamodell för distribuerad telemetrikorrelation. För att associera telemetri med en logisk åtgärd har varje telemetriobjekt ett kontextfält med namnet operation_Id . Den här identifieraren delas av varje telemetriobjekt i den distribuerade spårningen. Så även om du förlorar telemetri från ett enda lager kan du fortfarande associera telemetri som rapporteras av andra komponenter.

En distribuerad logisk åtgärd består vanligtvis av en uppsättning mindre åtgärder som är begäranden som bearbetas av en av komponenterna. Dessa åtgärder definieras av telemetribegäran. Varje begärandetelemetriobjekt id har ett eget objekt som identifierar det unikt och globalt. Och alla telemetriobjekt (till exempel spårningar och undantag) som är associerade med begäran ska ange till operation_parentId värdet för begäran id .

Varje utgående åtgärd, till exempel ett HTTP-anrop till en annan komponent, representeras av beroendetelemetri. Beroendetelemetri definierar också id sin egen som är globalt unik. Begärandetelemetri, som initieras av det här beroendeanropet, använder id detta som dess operation_parentId .

Du kan skapa en vy över den distribuerade logiska åtgärden med operation_Id hjälp av , och med operation_parentId request.id dependency.id . De här fälten definierar också kausalitetsordningen för telemetri-anrop.

I en mikrotjänstmiljö kan spårningar från komponenter gå till olika lagringsobjekt. Varje komponent kan ha en egen instrumentationsnyckel i Application Insights. För att få telemetri för den logiska åtgärden frågar Insights data från varje lagringsobjekt. När antalet lagringsobjekt är stort behöver du en ledtråd om var du ska leta härnäst. Datamodellen Application Insights definierar två fält för att lösa det här problemet: request.source och dependency.target . Det första fältet identifierar komponenten som initierade beroendebegäran. Det andra fältet identifierar vilken komponent som returnerade svaret från beroendeanropet.

Exempel

Låt oss ta en titt på ett exempel. Ett program som kallas Aktiekurser visar det aktuella priset för en aktie med hjälp av ett externt API som heter Stock. Programmet Aktiekurser har en sida med namnet Stock-sida som klientwebbläsaren öppnar med hjälp av GET /Home/Stock . Programmet frågar Lager-API:et med hjälp av HTTP-anropet GET /api/stock/value .

Du kan analysera den resulterande telemetrin genom att köra en fråga:

(requests | union dependencies | union pageViews)
| where operation_Id == "STYz"
| project timestamp, itemType, name, id, operation_ParentId, operation_Id

Observera att alla telemetriobjekt delar roten i operation_Id resultatet. När ett Ajax-anrop görs från sidan tilldelas ett nytt unikt ID ( ) till beroendetelemetrin och ID:t för qJSXU pageView används som operation_ParentId . Serverbegäran använder sedan Ajax-ID:t som operation_ParentId .

itemType	name	ID	operation_ParentId	operation_Id
Sidvisning	Sidan Aktie	STYz		STYz
Beroende	GET /Home/Stock	qJSXU	STYz	STYz
Begäran	GET Home/Stock	KqKwlrSt9PA=	qJSXU	STYz
Beroende	GET /api/stock/value	bBrf2L7mm2g=	KqKwlrSt9PA=	STYz

När anropet görs till en extern tjänst måste du känna till serverns GET /api/stock/value identitet så att du kan ange fältet på rätt dependency.target sätt. När den externa tjänsten inte stöder övervakning anges target till värdnamnet för tjänsten (till exempel stock-prices-api.com ). Men om tjänsten identifierar sig genom att returnera ett fördefinierat HTTP-huvud, innehåller den tjänstidentitet som gör att Application Insights kan skapa en distribuerad spårning genom att fråga telemetri från target den tjänsten.

Korrelationshuvuden med hjälp av W3C TraceContext

Program Insights övergår till W3C Trace-Context, som definierar:

traceparent: Innehåller det globalt unika åtgärds-ID:t och den unika identifieraren för anropet.
tracestate: Innehåller systemspecifik spårningskontext.

Den senaste versionen av Application Insights SDK stöder Trace-Context protokoll, men du kan behöva välja det. (Bakåtkompatibilitet med det tidigare korrelationsprotokollet som stöds av Application Insights SDK kommer att underhållas.)

HTTP-korrelationsprotokollet, som även kallas Request-Id,håller på att bli inaktuellt. Det här protokollet definierar två huvuden:

Request-Id: Innehåller det globalt unika ID:t för anropet.
Correlation-Context: Innehåller samlingen namn/värde-par för de distribuerade spårningsegenskaperna.

Program Insights definierar även tillägget för HTTP-korrelationsprotokollet. Den använder Request-Context namn/värde-par för att sprida samlingen med egenskaper som används av den omedelbara anroparen eller anroparen. Application Insights SDK använder det här huvudet för att ange dependency.target request.source fälten och .

W3C Trace-Context och Application Insights datamodeller mappar på följande sätt:

Application Insights	W3C TraceContext
`Id` av `Request` och `Dependency`	överordnat ID
`Operation_Id`	trace-id
`Operation_ParentId`	överordnat ID för det här intervallets överordnade intervall. Om det här är ett rotintervall måste det här fältet vara tomt.

Mer information finns i Application Insights telemetry data model.

Aktivera stöd för W3C-distribuerad spårning för .NET-appar

W3C TraceContext-baserad distribuerad spårning är aktiverat som standard i alla senaste .NET Framework/.NET Core-SDK:er, tillsammans med bakåtkompatibilitet med äldre Request-Id-protokoll.

Aktivera stöd för W3C-distribuerad spårning för Java-appar

Java 3.0-agent

Java 3.0-agenten stöder W3C från första hand och ingen ytterligare konfiguration krävs.

Java SDK

Inkommande konfiguration
- För Java EE-appar lägger du till följande i <TelemetryModules> taggen i ApplicationInsights.xml:
```
<Add type="com.microsoft.applicationinsights.web.extensibility.modules.WebRequestTrackingTelemetryModule>
   <Param name = "W3CEnabled" value ="true"/>
   <Param name ="enableW3CBackCompat" value = "true" />
</Add>
```
- För Spring Boot appar lägger du till följande egenskaper:
  - azure.application-insights.web.enable-W3C=true
  - azure.application-insights.web.enable-W3C-backcompat-mode=true
Utgående konfiguration

Lägg till följande i AI-Agent.xml:
```
<Instrumentation>
  <BuiltIn enabled="true">
    <HTTP enabled="true" W3C="true" enableW3CBackCompat="true"/>
  </BuiltIn>
</Instrumentation>
```
Anteckning

Bakåtkompatibilitetsläget är aktiverat som standard och enableW3CBackCompat parametern är valfri. Använd den bara när du vill inaktivera bakåtkompatibilitet.

Vi rekommenderar att du inaktiverar detta när alla dina tjänster har uppdaterats till nyare versioner av SDK:er som stöder W3C-protokollet. Vi rekommenderar starkt att du flyttar till dessa nyare SDK:er så snart som möjligt.

Viktigt

Kontrollera att de inkommande och utgående konfigurationerna är exakt desamma.

Aktivera stöd för W3C-distribuerad spårning för webbappar

Den här funktionen finns i Microsoft.ApplicationInsights.JavaScript . Den är inaktiverad som standard. Om du vill aktivera det använder distributedTracingMode du config. AI_AND_W3C för bakåtkompatibilitet med äldre tjänster som instrumenteras av Application Insights.

npm-baserad installation

Lägg till följande konfiguration:

  distributedTracingMode: DistributedTracingModes.W3C

Kodfragmentbaserad konfiguration

Lägg till följande konfiguration:

    distributedTracingMode: 2 // DistributedTracingModes.W3C

Viktigt

Om du vill se alla konfigurationer som krävs för att aktivera korrelation kan du läsa JavaScript-korrelationsdokumentationen.

Telemetrikorrelation i OpenCensus Python

OpenCensus Python stöder W3C Trace-Context utan ytterligare konfiguration.

Som referens finns OpenCensus-datamodellen här.

Korrelation för inkommande begäranden

OpenCensus Python korrelerar W3CTrace-Context huvuden från inkommande begäranden till de intervall som genereras från själva begärandena. OpenCensus gör detta automatiskt med integreringar för dessa populära webbprogramramverk: Flask, Django och Pyramid. Du behöver bara fylla i W3CTrace-Context huvuden med rätt format och skicka dem med begäran. Här är ett Flask-exempelprogram som visar detta:

from flask import Flask
from opencensus.ext.azure.trace_exporter import AzureExporter
from opencensus.ext.flask.flask_middleware import FlaskMiddleware
from opencensus.trace.samplers import ProbabilitySampler

app = Flask(__name__)
middleware = FlaskMiddleware(
    app,
    exporter=AzureExporter(),
    sampler=ProbabilitySampler(rate=1.0),
)

@app.route('/')
def hello():
    return 'Hello World!'

if __name__ == '__main__':
    app.run(host='localhost', port=8080, threaded=True)

Den här koden kör ett Flask-exempelprogram på den lokala datorn och lyssnar på port 8080 . Om du vill korrelera spårningskontexten skickar du en begäran till slutpunkten. I det här exemplet kan du använda ett curl kommando:

curl --header "traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01" localhost:8080

Genom att titta på rubrikformatet Trace-Contextkan du härleda följande information:

version: 00

trace-id: 4bf92f3577b34da6a3ce929d0e0e4736

parent-id/span-id: 00f067aa0ba902b7

trace-flags: 01

Om du tittar på begärandeposten som skickades till Azure Monitor kan du se fält som fyllts i med information om spårningsrubriken. Du hittar dessa data under Loggar (Analytics) i Azure Monitor Program Insights resurs.

Begära telemetri i loggar (analys)

Fältet har formatet , där tas från spårningshuvudet som skickades i begäran och är en genererad id <trace-id>.<span-id> matris på trace-id span-id 8 byte för det här intervallet.

Fältet operation_ParentId har formatet <trace-id>.<parent-id> , där både och tas trace-id från parent-id spårningshuvudet som skickades i begäran.

Loggkorrelation

Med OpenCensus Python kan du korrelera loggar genom att lägga till ett spårnings-ID, ett span-ID och en samplingsflagga för loggposter. Du lägger till dessa attribut genom att installera OpenCensus-loggningsintegrering . Följande attribut läggs till i LogRecord Python-objekt: traceId , och spanId traceSampled . Observera att detta endast gäller för loggare som skapas efter integreringen.

Här är ett exempelprogram som visar detta:

import logging

from opencensus.trace import config_integration
from opencensus.trace.samplers import AlwaysOnSampler
from opencensus.trace.tracer import Tracer

config_integration.trace_integrations(['logging'])
logging.basicConfig(format='%(asctime)s traceId=%(traceId)s spanId=%(spanId)s %(message)s')
tracer = Tracer(sampler=AlwaysOnSampler())

logger = logging.getLogger(__name__)
logger.warning('Before the span')
with tracer.span(name='hello'):
    logger.warning('In the span')
logger.warning('After the span')

När den här koden körs skriver följande ut i konsolen:

2019-10-17 11:25:59,382 traceId=c54cb1d4bbbec5864bf0917c64aeacdc spanId=0000000000000000 Before the span
2019-10-17 11:25:59,384 traceId=c54cb1d4bbbec5864bf0917c64aeacdc spanId=70da28f5a4831014 In the span
2019-10-17 11:25:59,385 traceId=c54cb1d4bbbec5864bf0917c64aeacdc spanId=0000000000000000 After the span

Observera att det finns en spanId present för loggmeddelandet inom intervallet. Det här är samma spanId som tillhör intervallet med namnet hello .

Du kan exportera loggdata med hjälp av AzureLogHandler . Mer information finns i den här artikeln.

Vi kan också skicka spårningsinformation från en komponent till en annan för korrekt korrelation. Tänk dig till exempel ett scenario där det finns två komponenter module1 och module2 . Module1 anropar funktioner i Module2 och för att hämta loggar från module1 både och i en enda spårning kan vi använda följande module2 metod:

# module1.py
import logging

from opencensus.trace import config_integration
from opencensus.trace.samplers import AlwaysOnSampler
from opencensus.trace.tracer import Tracer
from module2 import function_1

config_integration.trace_integrations(['logging'])
logging.basicConfig(format='%(asctime)s traceId=%(traceId)s spanId=%(spanId)s %(message)s')
tracer = Tracer(sampler=AlwaysOnSampler())

logger = logging.getLogger(__name__)
logger.warning('Before the span')
with tracer.span(name='hello'):
   logger.warning('In the span')
   function_1(tracer)
logger.warning('After the span')

# module2.py

import logging

from opencensus.trace import config_integration
from opencensus.trace.samplers import AlwaysOnSampler
from opencensus.trace.tracer import Tracer

config_integration.trace_integrations(['logging'])
logging.basicConfig(format='%(asctime)s traceId=%(traceId)s spanId=%(spanId)s %(message)s')
tracer = Tracer(sampler=AlwaysOnSampler())

def function_1(parent_tracer=None):
    if parent_tracer is not None:
        tracer = Tracer(
                    span_context=parent_tracer.span_context,
                    sampler=AlwaysOnSampler(),
                )
    else:
        tracer = Tracer(sampler=AlwaysOnSampler())

    with tracer.span("function_1"):
        logger.info("In function_1")

Telemetrikorrelation i .NET

.NET Runtime stöder distribution med hjälp av Activity och DiagnosticSource

Programprogrammet Insights .NET SDK använder DiagnosticSource och för att samla in och Activity korrelera telemetri.

Telemetrikorrelation i Java

Java-agenten stöder automatisk korrelation av telemetri. Den fylls automatiskt operation_id i för all telemetri (t.ex. spårningar, undantag och anpassade händelser) som utfärdats inom omfånget för en begäran. Den sprider också korrelationshuvudena (beskrivs ovan) för tjänst-till-tjänst-anrop via HTTP, om Java SDK-agenten har konfigurerats.

Anteckning

Program Insights Java-agenten samlar automatiskt in begäranden och beroenden för JMS, Kafka, Netty/Webflux med mera. För Java SDK stöds endast anrop som görs via Apache HttpClient för korrelationsfunktionen. Automatisk kontextspridning mellan meddelandetekniker (t.ex. Kafka, RabbitMQ och Azure Service Bus) stöds inte i SDK:n.