Telemetriecorrelatie in Application Insights

Artikel
11/03/2021
10 minuten om te lezen

In de wereld van microservices moet voor elke logische bewerking werk worden uitgevoerd in verschillende onderdelen van de service. U kunt elk van deze onderdelen afzonderlijk bewaken met behulp van Application Insights. Application Insights ondersteuning voor gedistribueerde telemetriecorrelatie, die u gebruikt om te detecteren welk onderdeel verantwoordelijk is voor fouten of prestatievermindering.

In dit artikel wordt het gegevensmodel uitgelegd dat wordt gebruikt door Application Insights telemetrie die door meerdere onderdelen wordt verzonden, te correleren. Dit omvat technieken en protocollen voor het doorgeven van context. Het bevat ook de implementatie van correlatietactieken in verschillende talen en platforms.

Gegevensmodel voor telemetriecorrelatie

Application Insights definieert een gegevensmodel voor gedistribueerde telemetriecorrelatie. Als u telemetrie wilt koppelen aan een logische bewerking, heeft elk telemetrie-item een contextveld met de naam operation_Id . Deze id wordt gedeeld door elk telemetrie-item in de gedistribueerde trace. Dus zelfs als u telemetrie van één laag verliest, kunt u nog steeds telemetrie koppelen die door andere onderdelen wordt gerapporteerd.

Een gedistribueerde logische bewerking bestaat doorgaans uit een set kleinere bewerkingen die aanvragen zijn die worden verwerkt door een van de onderdelen. Deze bewerkingen worden gedefinieerd door de telemetrie van de aanvraag. Elk telemetrie-item voor aanvragen heeft een eigen id telemetrie-item dat het uniek en wereldwijd identificeert. En alle telemetrie-items (zoals traceringen en uitzonderingen) die aan de aanvraag zijn gekoppeld, moeten de instellen op de operation_parentId waarde van de aanvraag id .

Elke uitgaande bewerking, zoals een HTTP-aanroep naar een ander onderdeel, wordt vertegenwoordigd door afhankelijkheids-telemetrie. Telemetrie van afhankelijkheden definieert ook een eigen id telemetrie die wereldwijd uniek is. Telemetrie van aanvragen, geïnitieerd door deze afhankelijkheidsoproep, gebruikt id deze als operation_parentId de .

U kunt een weergave van de gedistribueerde logische bewerking maken met operation_Id behulp van , en met operation_parentId request.id dependency.id . Deze velden definiëren ook de causaliteitsorde van telemetrie-aanroepen.

In een microservicesomgeving kunnen traceringen van onderdelen naar verschillende opslagitems gaan. Elk onderdeel kan een eigen instrumentatiesleutel hebben in Application Insights. Application Insights query's uitvoeren op gegevens uit elk opslagitem om telemetrie voor de logische bewerking op te halen. Wanneer het aantal opslagitems groot is, hebt u een hint nodig over waar u vervolgens moet kijken. Het Application Insights-gegevensmodel definieert twee velden om dit probleem op te request.source lossen: en dependency.target . Het eerste veld identificeert het onderdeel dat de afhankelijkheidsaanvraag heeft gestart. Het tweede veld geeft aan welk onderdeel het antwoord van de afhankelijkheidsoproep heeft geretourneerd.

Voorbeeld

We kijken naar een voorbeeld. Een toepassing met de naam Stock Prices toont de huidige marktprijs van een aandeel met behulp van een externe API met de naam Stock. De toepassing Stock Prices heeft een pagina met de naam Stock page die de clientwebbrowser opent met behulp van GET /Home/Stock . De toepassing vraagt de Stock-API op met behulp van de HTTP-aanroep GET /api/stock/value .

U kunt de resulterende telemetrie analyseren door een query uit te voeren:

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

Houd er rekening mee dat in de resultaten alle telemetrie-items de hoofdmap operation_Id delen. Wanneer een Ajax-aanroep wordt gedaan vanaf de pagina, wordt een nieuwe unieke id ( ) toegewezen aan de qJSXU afhankelijkheids-telemetrie en wordt de id van de pageView gebruikt als operation_ParentId . De serveraanvraag gebruikt vervolgens de Ajax-id als operation_ParentId .

itemType	naam	Id	operation_ParentId	operation_Id
Paginaweergave	Voorraadpagina	STYz		STYz
Afhankelijkheid	GET /Home/Stock	qJSXU	STYz	STYz
Verzoek	GET Home/Stock	KqKwlrSt9PA=	qJSXU	STYz
Afhankelijkheid	GET /api/stock/value	bBrf2L7mm2g =	KqKwlrSt9PA=	STYz

Wanneer de aanroep naar een externe service wordt uitgevoerd, moet u de identiteit van die server weten, zodat u het veld op de juiste manier GET /api/stock/value dependency.target kunt instellen. Wanneer de externe service geen ondersteuning biedt voor bewaking, target wordt ingesteld op de hostnaam van de service (bijvoorbeeld stock-prices-api.com ). Maar als de service zichzelf identificeert door een vooraf gedefinieerde HTTP-header te retourneren, bevat de service-identiteit waarmee Application Insights een gedistribueerde trace kan bouwen door telemetrie op te vragen bij die target service.

Correlatieheaders met W3C TraceContext

Application Insights wordt overge zetten naar W3C Trace-Context,waarmee het volgende wordt bepaald:

traceparent: Bevat de wereldwijd unieke bewerkings-id en de unieke id van de aanroep.
tracestate: Voert systeemspecifieke traceringscontext uit.

De nieuwste versie van de Application Insights SDK ondersteunt het Trace-Context-protocol, maar mogelijk moet u zich hier wel voor kiezen. (Achterwaartse compatibiliteit met het vorige correlatieprotocol dat wordt ondersteund door de Application Insights SDK blijft behouden.)

Het HTTP-correlatieprotocol, ook wel Request-Idgenoemd, wordt afgeschaft. Dit protocol definieert twee headers:

Request-Id: Bevat de wereldwijd unieke id van de aanroep.
Correlation-Context: Bevat de verzameling naam-waardeparen van de gedistribueerde traceereigenschappen.

Application Insights definieert ook de extensie voor het HTTP-correlatieprotocol. Er worden naam-waardeparen gebruikt om de verzameling eigenschappen door te geven die worden gebruikt door de directe Request-Context aanroeper of aanroeper. De Application Insights SDK gebruikt deze header om de velden en dependency.target in te request.source stellen.

De W3C-modellen Trace-Context en Application Insights worden op de volgende manier weergegeven:

Application Insights	W3C TraceContext
`Id` van `Request` en `Dependency`	parent-id
`Operation_Id`	trace-id
`Operation_ParentId`	parent-id van het bovenliggende bereik van dit bereik. Als dit een hoofdmap is, moet dit veld leeg zijn.

Zie Application Insights telemetry data model (Toepassingsgegevensmodel voor telemetriegegevens) voor meer informatie.

Ondersteuning voor gedistribueerde tracering van W3C inschakelen voor .NET-apps

Gedistribueerde tracering op basis van W3C TraceContext is standaard ingeschakeld in alle recente .NET Framework/.NET Core SDK's, samen met achterwaartse compatibiliteit met het verouderde Request-Id-protocol.

Ondersteuning voor gedistribueerde tracering van W3C inschakelen voor Java-apps

Java 3.0-agent

De Java 3.0-agent biedt standaard ondersteuning voor W3C en er is geen aanvullende configuratie nodig.

Java-SDK

Binnenkomende configuratie
- Voeg voor Java EE-apps het volgende toe aan de <TelemetryModules> tag in ApplicationInsights.xml:
```
<Add type="com.microsoft.applicationinsights.web.extensibility.modules.WebRequestTrackingTelemetryModule>
   <Param name = "W3CEnabled" value ="true"/>
   <Param name ="enableW3CBackCompat" value = "true" />
</Add>
```
- Voeg Spring Boot volgende eigenschappen toe voor Spring Boot apps:
  - azure.application-insights.web.enable-W3C=true
  - azure.application-insights.web.enable-W3C-backcompat-mode=true
Uitgaande configuratie

Voeg het volgende toe aan AI-Agent.xml:
```
<Instrumentation>
  <BuiltIn enabled="true">
    <HTTP enabled="true" W3C="true" enableW3CBackCompat="true"/>
  </BuiltIn>
</Instrumentation>
```
Notitie

Achterwaartse compatibiliteitsmodus is standaard ingeschakeld en de enableW3CBackCompat parameter is optioneel. Gebruik deze alleen als u compatibiliteit met eerdere gegevens wilt uitschakelen.

In het ideale moment kunt u dit uitschakelen wanneer al uw services zijn bijgewerkt naar nieuwere versies van SDK's die ondersteuning bieden voor het W3C-protocol. We raden u ten zeerste aan om zo snel mogelijk over te gaan op deze nieuwere SDK's.

Belangrijk

Zorg ervoor dat de binnenkomende en uitgaande configuraties exact hetzelfde zijn.

Ondersteuning voor gedistribueerde tracering van W3C inschakelen voor web-apps

Deze functie is in Microsoft.ApplicationInsights.JavaScript . Deze is standaard uitgeschakeld. Als u dit wilt inschakelen, gebruikt distributedTracingMode u config. AI_AND_W3C wordt geleverd voor achterwaartse compatibiliteit met verouderde services die zijn instrumenteerd door Application Insights.

Installatie op basis van npm

Voeg de volgende configuratie toe:

  distributedTracingMode: DistributedTracingModes.W3C

Installatie op basis van codefragmenten

Voeg de volgende configuratie toe:

    distributedTracingMode: 2 // DistributedTracingModes.W3C

Belangrijk

Zie de JavaScript-correlatiedocumentatie voor alle configuraties die vereist zijn voor het inschakelen van correlatie.

Telemetriecorrelatie in OpenCensus Python

OpenCensus Python ondersteunt W3C Trace-Context zonder extra configuratie.

Ter referentie vindt u hier het OpenCensus-gegevensmodel.

Correlatie van binnenkomende aanvraag

OpenCensus Python correleert W3C-Trace-Context headers van binnenkomende aanvragen tot de spans die worden gegenereerd op basis van de aanvragen zelf. OpenCensus doet dit automatisch met integraties voor deze populaire webtoepassings frameworks: Flask, Django en Pyramid. U hoeft alleen de W3C-headers Trace-Context met de juiste indeling te vullen en ze met de aanvraag te verzenden. Hier is een Flask-voorbeeldtoepassing die dit laat zien:

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)

Met deze code wordt een Flask-voorbeeldtoepassing uitgevoerd op uw lokale computer, die luistert naar poort 8080 . Als u de traceercontext wilt correleren, verzendt u een aanvraag naar het eindpunt. In dit voorbeeld kunt u een opdracht curl gebruiken:

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

Door de headerindeling Trace-Context te zien,kunt u de volgende informatie afleiden:

version: 00

trace-id: 4bf92f3577b34da6a3ce929d0e0e4736

parent-id/span-id: 00f067aa0ba902b7

trace-flags: 01

Als u de aanvraaginvoer bekijkt die naar de Azure Monitor, ziet u velden die zijn gevuld met de informatie over de traceerheader. U vindt deze gegevens onder Logboeken (Analytics) in de Azure Monitor Application Insights resource.

Telemetrie aanvragen in logboeken (Analytics)

Het veld heeft de notatie , waarbij de wordt overgenomen uit de traceerheader die is doorgegeven in de aanvraag en de een gegenereerde matrix van id <trace-id>.<span-id> trace-id span-id 8 byte is voor dit bereik.

Het veld heeft de indeling , waarbij zowel de als de worden overgenomen uit de operation_ParentId <trace-id>.<parent-id> trace-id parent-id traceerheader die in de aanvraag is doorgegeven.

Logboekcorrelatie

Met OpenCensus Python kunt u logboeken correleren door een traceer-id, een span-id en een samplingvlag toe te voegen aan logboekrecords. U voegt deze kenmerken toe door de integratie van OpenCensus-logboekregistratie te installeren. De volgende kenmerken worden toegevoegd aan LogRecord Python-objecten: traceId , en spanId traceSampled . Houd er rekening mee dat dit alleen van kracht is voor logboeken die zijn gemaakt na de integratie.

Hier is een voorbeeldtoepassing die dit laat zien:

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')

Wanneer deze code wordt uitgevoerd, wordt het volgende afgedrukt in de console:

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

U ziet dat er een spanId aanwezig is voor het logboekbericht binnen de periode. Dit is hetzelfde als spanId het bereik met de naam hello .

U kunt de logboekgegevens exporteren met behulp van AzureLogHandler . Raadpleeg dit artikel voor meer informatie.

We kunnen ook traceergegevens van het ene naar het andere onderdeel doorgeven voor een juiste correlatie. Denk bijvoorbeeld aan een scenario waarin er twee onderdelen zijn module1 en module2 . Module1 roept functies in Module2 aan en om logboeken op te halen uit zowel als in één module1 module2 trace, kunnen we de volgende benadering gebruiken:

# 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")

Telemetriecorrelatie in .NET

.NET-runtime ondersteunt gedistribueerd met behulp van Activiteit en DiagnosticSource

De Application Insights .NET SDK gebruikt en om DiagnosticSource Activity telemetrie te verzamelen en correleren.

Telemetriecorrelatie in Java

De Java-agent ondersteunt automatische correlatie van telemetrie. Deze wordt automatisch ingevuld operation_id voor alle telemetrie (zoals traceringen, uitzonderingen en aangepaste gebeurtenissen) die zijn uitgegeven binnen het bereik van een aanvraag. Ook worden de correlatieheaders (eerder beschreven) doorgegeven voor service-naar-service-aanroepen via HTTP, als de Java SDK-agent is geconfigureerd.

Notitie

Application Insights Java-agent verzamelt automatisch aanvragen en afhankelijkheden voor JMS, Kafka, Netty/Webfieën en meer. Voor Java SDK worden alleen aanroepen die via Apache HttpClient worden gedaan, ondersteund voor de correlatiefunctie. Automatische context doorgeven aan berichtentechnologieën (zoals Kafka, RabbitMQ en Azure Service Bus) wordt niet ondersteund in de SDK.