Was sind verteilte Ablaufverfolgung und Telemetriekorrelation?

  • Artikel

Hinweis

Die folgende Dokumentation basiert auf der klassischen Application Insights-API. Der langfristige Plan für Application Insights besteht darin, Daten mithilfe von OpenTelemetry zu sammeln. Weitere Informationen finden Sie unter Aktivieren von Azure Monitor OpenTelemetry für .NET-, Node.js-, Python- und Java-Anwendungen.

Moderne Cloud- und Microservices-Architekturen haben einfache, unabhängig einsetzbare Dienste ermöglicht, die die Kosten senken und gleichzeitig die Verfügbarkeit und den Durchsatz erhöhen. Allerdings ist es dadurch schwieriger geworden, über Systeme nachzudenken und sie zu debuggen. Die verteilte Ablaufverfolgung löst dieses Problem, indem sie einen Leistungsprofiler bereitstellt, der wie Aufrufstapel für Cloud- und Microservices-Architekturen funktioniert.

Azure Monitor stellt zwei Möglichkeiten zur Nutzung verteilter Tracedaten zur Verfügung: die Transaktionsdiagnoseansicht für eine einzelne Transaktion/Abfrage und die Anwendungsübersicht, die zeigt, wie die Systeme interagieren.

Application Insights kann jede Komponente separat überwachen und ermitteln, welche Komponente für Fehler oder Leistungseinbußen verantwortlich ist, indem sie verteilte Telemetriekorrelation verwendet. In diesem Artikel werden das Datenmodell, die Techniken zur Kontextweitergabe, die Protokolle und die Implementierung von Korrelationstaktiken auf verschiedenen Sprachen und Plattformen erläutert, die von Application Insights verwendet werden.

Aktivieren der verteilten Ablaufverfolgung

Um die verteilte Ablaufverfolgung für eine Anwendung zu aktivieren, fügen Sie jedem Dienst basierend auf seiner Programmiersprache den richtigen Agent, das richtige SDK oder die richtige Bibliothek hinzu.

Aktivieren über Application Insights per automatischer Instrumentierung oder SDKs

Die verteilte Ablaufverfolgung wird von den Application Insights-Agents und/oder SDKs für .NET, .NET Core, Java, Node.js und JavaScript bereits nativ unterstützt. Anweisungen zum Installieren und Konfigurieren der einzelnen Application Insights SDKs finden Sie unter:

Wenn das richtige Application Insights SDK installiert und konfiguriert ist, werden Ablaufverfolgungsinformationen für gängige Frameworks, Bibliotheken und Technologien automatisch von der automatischen Erfassung (Autocollectors) für SDK-Abhängigkeiten gesammelt. Die vollständige Liste der unterstützten Technologien finden Sie unter Automatisches Sammeln von Abhängigkeiten.

Darüber hinaus kann jede beliebige Technologie manuell durch einen Aufruf von TrackDependency auf dem TelemetryClient überwacht werden.

Aktivieren über OpenTelemetry

Application Insights unterstützt jetzt die verteilte Ablaufverfolgung via OpenTelemetry. OpenTelemetry bietet eine anbieterneutrale Instrumentierung zum Senden von Ablaufverfolgungen, Metriken und Protokollen an Application Insights. Zunächst hat sich die OpenTelemetry-Gemeinschaft dem Distributed Tracing angenommen. Metriken und Protokolle sind noch in Bearbeitung.

Eine vollständige Beobachtbarkeitsgeschichte umfasst alle drei Säulen. Sehen Sie sich den Status unserer OpenTelemetry-basierten Azure Monitor-Angebote an, um die neuesten Informationen dazu zu erhalten, was enthalten ist, welche Angebote allgemein verfügbar sind und welche Supportoptionen es gibt.

Auf den folgenden Seiten finden Sie für jede Sprache eine Anleitung zur Aktivierung und Konfiguration der OpenTelemetry-basierten Angebote von Microsoft. Wichtig ist, dass wir die verfügbaren Funktionen und Einschränkungen der einzelnen Angebote erläutern, damit Sie entscheiden können, ob OpenTelemetry für Ihr Projekt geeignet ist.

Aktivieren über OpenCensus

Zusätzlich zu den Application Insights SDKs unterstützt Application Insights auch die verteilte Ablaufverfolgung durch OpenCensus. OpenCensus ist eine herstellerunabhängige, Open Source-Einzelverteilung von Bibliotheken, mit denen Funktionen für das Sammeln von Metriken und für die verteilte Ablaufverfolgung für Dienste bereitgestellt werden. Es ermöglicht der Open-Source-Community auch, verteiltes Tracing mit gängigen Technologien wie Redis, Memcached oder MongoDB zu ermöglichen. Microsoft arbeitet bei OpenCensus mit mehreren anderen Überwachungs- und Cloud-Partnern zusammen.

Weitere Informationen zu OpenCensus für Python finden Sie unter Einrichten von Azure Monitor für Ihre Python-Anwendung.

Auf der OpenCensus-Website finden Sie API-Referenzdokumentation für Python und Go, sowie verschiedene andere Anleitungen für die Verwendung von OpenCensus.

Datenmodell für Telemetriekorrelation

Application Insights definiert ein Datenmodell für die verteilte Telemetriekorrelation. Um die Telemetrie mit einem logischen Vorgang zu verknüpfen, ist jedes Telemetrieelement mit einem Kontextfeld namens operation_Id versehen. Jedes Telemetrieelement in der verteilten Ablaufverfolgung teilt diesen Identifikator. Selbst wenn Ihnen Telemetriedaten von einer einzelnen Ebene verloren gehen, können Sie weiterhin Telemetriedaten zuordnen, die von anderen Komponenten gemeldet wurden.

Der verteilte logische Vorgang besteht in der Regel aus einem Satz von kleineren Vorgängen, nämlich den Anforderungen, die von einer der Komponenten verarbeitet werden. Anforderungtelemetrie definiert diese Vorgänge. Jedes Anforderungstelemetrieelement verfügt über eine eigene id, die es eindeutig und global identifiziert. Für sämtliche Telemetrieelemente (z.B. Ablaufverfolgungen und Ausnahmen), die der Anforderung zugeordnet sind, sollte die operation_parentId auf den Wert der Anforderungs-id festgelegt werden.

Abhängigkeitstelemetrie repräsentiert jede ausgehende Operation, wie z. B. einen HTTP-Aufruf an eine andere Komponente. Es definiert auch sein eigenes id, das weltweit einzigartig ist. Anforderungsabhängigkeiten, die durch diese Anforderungstelemetrie initiiert werden, verwenden diese id als operation_parentId.

Sie können eine Ansicht des verteilten logischen Vorgangs mit operation_Id, operation_parentId und request.id mit dependency.id erstellen. Diese Felder definieren auch die Kausalitätsreihenfolge der Telemetrieaufrufe.

In Microserviceumgebungen können Ablaufverfolgungen von Komponenten an unterschiedliche Speicherelemente weitergeleitet werden. Jede Komponente kann eine eigene Verbindungszeichenfolge in Application Insights aufweisen. Um Telemetriedaten für den logischen Vorgang abzurufen, ruft Application Insights Daten von jedem Speicherelement ab.

Wenn die Anzahl der Speicherelemente groß ist, benötigen Sie einen Hinweis, wo Sie als Nächstes suchen sollen. Zur Behebung dieses Problems definiert das Application Insights-Datenmodell zwei Felder: request.source und dependency.target. Das erste Feld identifiziert die Komponente, die die Abhängigkeitsanforderung initiiert hat. Das zweite Feld identifiziert die Komponente, die die Antwort des Abhängigkeitsaufrufs zurückgegeben hat.

Informationen zum Abfragen aus mehreren verschiedenen Instanzen mithilfe des Abfrageausdrucks app finden Sie unter app()-Ausdruck in Azure Monitor-Abfragen.

Beispiel

Schauen wir uns ein Beispiel an. Eine Anwendung namens Stock Prices gibt den aktuellen Marktpreis einer Aktie mithilfe einer externen API mit dem Namen Stock an. Die Anwendung Stock Prices enthält die Seite „Stock“, die vom Clientwebbrowser mit GET /Home/Stock geöffnet wird. Die Anwendung fragt die Stock-API mit dem HTTP-Aufruf GET /api/stock/value ab.

Sie können die daraus resultierenden Telemetriedaten durch Ausführen einer Abfrage analysieren:

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

In den Ergebnissen nutzen alle Telemetrieelemente die Stamm-operation_Id. Wenn ein Ajax-Aufruf über die Seite erfolgt, wird der Abhängigkeitstelemetrie eine neue eindeutige ID (qJSXU) zugewiesen, und die ID der pageView dient als operation_ParentId. Die Serveranforderung verwendet dann die Ajax-ID als operation_ParentId.

itemType name id operation_ParentId operation_Id
pageView Stock page STYz STYz
dependency GET /Home/Stock qJSXU STYz STYz
request GET Home/Stock KqKwlrSt9PA= qJSXU STYz
dependency GET /api/stock/value bBrf2L7mm2g= KqKwlrSt9PA= STYz

Wenn der Aufruf GET /api/stock/value an einen externen Dienst erfolgt, müssen Sie die Identität dieses Servers kennen, damit Sie das Feld dependency.target entsprechend festlegen können. Wenn der externe Dienst keine Überwachung unterstützt, wird target auf den Hostnamen des Diensts festgelegt. z. B. stock-prices-api.com. Wenn sich dieser Dienst jedoch durch Zurückgeben eines vordefinierten HTTP-Headers identifiziert, enthält target die Dienstidentität, mit der Application Insights verteilte Ablaufverfolgungen durch Abfragen von Telemetriedaten von diesem Dienst erstellen kann.

Korrelationsheader mit W3C TraceContext

Application Insights geht zum W3C Trace-Context über, der Folgendes definiert:

  • traceparent: Trägt die global eindeutige Vorgangs-ID und den eindeutigen Bezeichner des Aufrufs.
  • tracestate: Trägt einen systemspezifischen Ablaufverfolgungskontext.

Die neueste Version des Application Insights SDK unterstützt das Trace-Context-Protokoll, aber möglicherweise müssen Sie sich explizit dafür entscheiden. (Abwärtskompatibilität mit dem vorherigen Korrelationsprotokoll, das vom Application Insights SDK unterstützt wird, bleibt erhalten.)

Das Korrelations-HTTP-Protokoll, das auch als „Request-ID“ bezeichnet wird, ist veraltet. Dieses Protokoll definiert zwei Header:

  • Request-Id: Enthält die global eindeutige ID des Aufrufs.
  • Correlation-Context: Enthält die Sammlung von Name/Wert-Paaren der Eigenschaften von verteilten Ablaufverfolgungen.

Application Insights definiert ferner die Erweiterung für das Korrelations-HTTP-Protokoll. Er verwendet Name/Wert-Paare für Request-Context, die die vom unmittelbaren Aufrufer oder Aufgerufenen verwendete Sammlung von Eigenschaften propagieren. Das Application Insights SDK legt mithilfe dieses Headers die Felder dependency.target und request.source fest.

Der W3C Trace-Context und Application Insights-Datenmodelle sind in folgender Weise zugeordnet:

Application Insights W3C TraceContext
Id der Request und Dependency parent-id
Operation_Id trace-id
Operation_ParentId parent-id der übergeordneten Spanne dieser Spanne. Dieses Feld muss leer sein, wenn es sich um einen Stammspanne handelt.

Weitere Informationen finden Sie unter Application Insights-Telemetriedatenmodell.

Aktivieren der Unterstützung der verteilten W3C-Ablaufverfolgung für .NET-Apps

Die W3C TraceContext-basierte verteilte Ablaufverfolgung ist in allen aktuellen .NET Framework/.NET Core SDKs standardmäßig aktiviert, zusammen mit Abwärtskompatibilität mit dem „Request-Id“-Legacyprotokoll.

Aktivieren der Unterstützung für die verteilte Ablaufverfolgung von W3C für Java-Apps

Java 3.0-Agent

Der Java 3.0-Agent unterstützt standardmäßig W3C. Es ist keine weitere Konfiguration erforderlich.

Java-SDK

  • Eingangskonfiguration

    Fügen Sie für Java EE-Apps dem Tag <TelemetryModules> in ApplicationInsights.xml den folgenden Code hinzu:

    <Add type="com.microsoft.applicationinsights.web.extensibility.modules.WebRequestTrackingTelemetryModule>
   <Param name = "W3CEnabled" value ="true"/>
   <Param name ="enableW3CBackCompat" value = "true" />
</Add>

    Für Spring Boot-Apps fügen Sie die folgenden Eigenschaften hinzu:

    • azure.application-insights.web.enable-W3C=true
    • azure.application-insights.web.enable-W3C-backcompat-mode=true

  • Ausgangskonfiguration

    Fügen Sie der Datei AI-Agent.xml den folgenden Code hinzu:

    <Instrumentation>
  <BuiltIn enabled="true">
    <HTTP enabled="true" W3C="true" enableW3CBackCompat="true"/>
  </BuiltIn>
</Instrumentation>

    Hinweis

    Der Abwärtskompatibilitätsmodus ist standardmäßig aktiviert, und der Parameter enableW3CBackCompat ist optional. Verwenden sie ihn nur, wenn Sie die Abwärtskompatibilität deaktivieren möchten.

    Idealerweise deaktivieren Sie diesen Modus, wenn alle Dienste auf neuere Versionen von SDKs aktualisiert wurden, die das W3C-Protokoll unterstützen. Es wird dringend empfohlen, so bald wie möglich zu diesen neueren SDKs zu wechseln.

Stellen Sie unbedingt sicher, dass die Eingangs- und Ausgangskonfiguration genau gleich sind.

Aktivieren der Unterstützung von verteilter W3C-Ablaufverfolgung für Web-Apps

Dieses Feature ist standardmäßig für JavaScript aktiviert, und die Header werden automatisch eingeschlossen, wenn die Domäne der Hostingseite mit der Domäne identisch ist, an welche die Anforderungen gesendet werden (z. B. die Hostingseite example.com, und die Ajax-Anforderungen werden an example.com gesendet). Um den Modus für verteilte Ablaufverfolgung zu ändern, verwenden Sie das distributedTracingMode Konfigurationsfeld. AI_AND_W3C wird standardmäßig für Abwärtskompatibilität mit allen Legacy-Diensten bereitgestellt, die von Application Insights instrumentiert werden.

Wenn die XMLHttpRequest- oder Fetch Ajax-Anforderungen an einen anderen Domänenhost gesendet werden, einschließlich Unterdomänen, sind die Korrelationsheader nicht standardmäßig enthalten. Um dieses Feature zu aktivieren, legen Sie das enableCorsCorrelation Konfigurationsfeld auf true fest. Wenn Sie enableCorsCorrelation auf true festlegen, enthalten alle XMLHttpRequest- und Fetch Ajax-Anforderungen die Korrelationsheader. Wenn die Anwendung auf dem aufgerufenen Server den traceparent-Header nicht unterstützt, schlägt die Anforderung daher möglicherweise fehl, je nachdem, ob der Browser/die Version die Anforderung basierend auf den vom Server akzeptierten Headern validieren kann. Sie können das Konfigurationsfeld correlationHeaderExcludedDomains verwenden, um die Domäne des Servers von Header Injection für komponentenübergreifende Korrelationen auszuschließen. Sie können z. B. correlationHeaderExcludedDomains: ['*.auth0.com'] verwenden, um Korrelationsheader von Anforderungen auszuschließen, die an den Auth0-Identitätsanbieter gesendet werden.

Wichtig

Alle Konfigurationen, die zum Aktivieren der Korrelation erforderlich sind, finden Sie in der Dokumentation zur JavaScript-Korrelation.

Telemetriekorrelation in OpenCensus Python

OpenCensus Python unterstützt W3C Trace-Context, ohne dass eine zusätzliche Konfiguration erforderlich ist.

Verwenden Sie als Referenz für das OpenCensus-Datenmodell diese GitHub-Seite.

Korrelation eingehender Anforderungen

OpenCensus Python korreliert W3C Trace-Context-Header von eingehenden Anforderungen mit den Spannen, die aus den Anforderungen selbst generiert werden. OpenCensus korreliert automatisch mit Integrationen für die folgenden gängigen Webanwendungsframeworks: Flask, Django und Pyramid. Sie müssen lediglich die W3C Trace-Context-Header mit dem korrekten Format auffüllen und mit der Anforderung senden.

Machen Sie sich mit dieser Flask-Beispielanwendung vertraut. Installieren Sie Flask, OpenCensus und die Erweiterungen für Flask und Azure.


pip install flask opencensus opencensus-ext-flask opencensus-ext-azure

Sie müssen die Application Insights-Verbindungszeichenfolge der Umgebungsvariablen hinzufügen.

APPLICATIONINSIGHTS_CONNECTION_STRING=<appinsights-connection-string>

Flask-Beispielanwendung

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(
        connection_string='<appinsights-connection-string>', # or set environment variable APPLICATION_INSIGHTS_CONNECTION_STRING
    ), 
    sampler=ProbabilitySampler(rate=1.0),
)

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

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

Mit diesem Code wird eine Flask-Beispielanwendung auf dem lokalen Computer ausgeführt, der an Port 8080 lauscht. Zum Korrelieren des Ablaufverfolgungskontexts senden Sie eine Anforderung an den Endpunkt. In diesem Beispiel können Sie einen curl-Befehl verwenden:

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

Durch einen Blick auf das Format des Kontextheaders für die Ablaufverfolgung können Sie die folgenden Informationen ableiten:

version: 00

trace-id: 4bf92f3577b34da6a3ce929d0e0e4736

parent-id/span-id: 00f067aa0ba902b7

trace-flags: 01

Wenn Sie sich den Anforderungseintrag ansehen, der an Azure Monitor gesendet wurde, sind dort Felder enthalten, die mit den Informationen des Ablaufverfolgungsheaders aufgefüllt wurden. Die Daten sind in der Azure Monitor Application Insights-Ressource unter Protokolle (Analytics) zu finden.

Screenshot that shows Request telemetry in Logs (Analytics).

Das Feld id hat das Format <trace-id>.<span-id>. Hierbei wird trace-id aus dem in der Anforderung übergebenen Ablaufverfolgungsheader entnommen, und span-id ist ein generiertes 8-Byte-Array für diese Spanne.

Das Feld operation_ParentId hat das Format <trace-id>.<parent-id>. Hierbei werden sowohl trace-id als auch parent-id aus dem in der Anforderung übergebenen Ablaufverfolgungsheader entnommen.

Protokollkorrelation

Mit OpenCensus Python können Sie Protokolle korrelieren, indem Sie Protokolldatensätzen eine Ablaufverfolgungs-ID, eine Spannen-ID und ein Stichprobenflag hinzufügen. Sie fügen diese Attribute hinzu, indem Sie die OpenCensus-Protokollintegration installieren. Die folgenden Attribute werden LogRecord-Objekten von Python hinzugefügt: traceId, spanId und traceSampled (gilt nur für Protokollierungen, die nach der Integration erstellt werden).

Installieren Sie die OpenCensus-Protokollierungsintegration:

python -m pip install opencensus-ext-logging

Beispielanwendung

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

Bei Ausführung dieses Codes wird Folgendes in der Konsole ausgegeben:

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

Beachten Sie, dass für die Protokollnachricht, die innerhalb der Spanne liegt, eine spanId vorhanden ist. Die spanId entspricht derjenigen, die zur Spanne mit dem Namen hello gehört.

Sie können die Protokolldaten mithilfe von AzureLogHandlerexportieren. Weitere Informationen finden Sie unter Einrichten von Azure Monitor für Ihre Python-Anwendung.

Wir können auch Ablaufverfolgungsinformationen zur ordnungsgemäßen Korrelation von einer Komponente an eine andere übergeben. Stellen Sie sich beispielsweise ein Szenario mit zwei Komponenten module1 und module2 vor. Modul 1 ruft Funktionen in Modul 2 auf. Um Protokolle von module1 und module2 in einer einzelnen Ablaufverfolgung zu erhalten, können wir den folgenden Ansatz verwenden:

# module1.py
import logging

from opencensus.trace import config_integration
from opencensus.trace.samplers import AlwaysOnSampler
from opencensus.trace.tracer import Tracer
from module_2 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(logger, tracer)
logger.warning("After the span")

# module_2.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"
)
logger = logging.getLogger(__name__)
tracer = Tracer(sampler=AlwaysOnSampler())


def function_1(logger=logger, 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")

Telemetriekorrelation in .NET

Die Korrelation wird standardmäßig beim Onboarding einer App vorgenommen. Es sind keine speziellen Aktionen erforderlich.

.NET-Runtime unterstützt die verteilte Telemetriekorrelation mithilfe von Activity und DiagnosticSource.

Das Application Insights .NET SDK verwendet DiagnosticSource und Activity , um Telemetriedaten zu sammeln und zu korrelieren.

Telemetriekorrelation in Java

Der Java-Agent unterstützt die automatische Korrelation von Telemetriedaten. Das SDK füllt operation_id automatisch für alle Telemetriedaten (z.B. Ablaufverfolgungen, Ausnahmen und benutzerdefinierte Ereignisse) auf, die im Zusammenhang mit einer Anforderung ausgegeben werden. Es gibt außerdem die Korrelationsheader (weiter oben beschrieben) für Dienst-zu-Dienst-Aufrufe über HTTP weiter, wenn der Java SDK-Agent konfiguriert ist.

Hinweis

Der Java-Agent von Application Insights erfasst automatisch Anforderungen und Abhängigkeiten für JMS, Kafka, Netty/Webflux usw. Beim Java SDK werden für die Korrelationsfunktion nur Aufrufe unterstützt, die über Apache HttpClient erfolgen. Die automatische Kontextweitergabe über verschiedene Messagingtechnologien (z. B. Kafka, RabbitMQ und Azure Service Bus) wird im SDK nicht unterstützt.

Um benutzerdefinierte Telemetriedaten zu erfassen, müssen Sie die Anwendung mit dem Java 2.6 SDK instrumentieren.

Rollennamen

Sie möchten möglicherweise die Art und Weise anpassen, wie Komponentennamen in der Anwendungsübersicht angezeigt werden. Dazu können Sie cloud_RoleName manuell festlegen, indem Sie eine der folgenden Aktionen ausführen:

  • Legen Sie für Application Insights Java den Cloudrollennamen wie folgt fest:

    {
  "role": {
    "name": "my cloud role name"
  }
}

    Sie können den Namen der Cloudrolle auch mithilfe der Umgebungsvariablen APPLICATIONINSIGHTS_ROLE_NAME festlegen.

  • Mit dem Application Insights Java SDK 2.5.0 und höher können Sie cloud_RoleName angeben, indem Sie der Datei ApplicationInsights.xml den Eintrag <RoleName> hinzufügen:

    Screenshot that shows Application Insights overview and connection string. 

    <?xml version="1.0" encoding="utf-8"?>
<ApplicationInsights xmlns="http://schemas.microsoft.com/ApplicationInsights/2013/Settings" schemaVersion="2014-05-30">
   <ConnectionString>InstrumentationKey=00000000-0000-0000-0000-000000000000</ConnectionString>
   <RoleName>** Your role name **</RoleName>
   ...
</ApplicationInsights>

  • Bei Verwendung von Spring Boot mit Application Insights Spring Boot Starter legen Sie Ihren benutzerdefinierten Namen für die Anwendung in der Datei application.properties fest:

    spring.application.name=<name-of-app>

Sie können den Namen der Cloudrolle auch über eine Umgebungsvariable oder Systemeigenschaft festlegen. Weitere Informationen finden Sie unter Konfigurieren des Cloudrollennamens.

Nächste Schritte