Co to jest rozproszone śledzenie i korelacja telemetrii?

Artykuł
11/05/2024

Uwaga

Poniższa dokumentacja opiera się na klasycznym interfejsie API usługi Application Insights. Długoterminowy plan usługi Application Insights polega na zbieraniu danych przy użyciu technologii OpenTelemetry. Aby uzyskać więcej informacji, zobacz Enable Azure Monitor OpenTelemetry for .NET, Node.js, Python and Java applications and our OpenTelemetry Roadmap (Włączanie usługi Azure Monitor OpenTelemetry dla platformy .NET, Node.js, python i Java) oraz our OpenTelemetry Roadmap (Harmonogram działania openTelemetry). Wskazówki dotyczące migracji są dostępne dla platformy .NET, Node.js i języka Python.

Nowoczesne architektury chmury i mikrousług umożliwiają proste, niezależne wdrażanie usług, które zmniejszają koszty przy jednoczesnym zwiększeniu dostępności i przepływności. Jednak ogólne systemy utrudniły rozumowanie i debugowanie. Śledzenie rozproszone rozwiązuje ten problem, udostępniając profiler wydajności, który działa jak stosy wywołań dla architektur chmury i mikrousług.

Usługa Azure Monitor udostępnia dwa środowiska korzystania z rozproszonych danych śledzenia: widok diagnostyki transakcji dla pojedynczej transakcji/żądania i widok mapy aplikacji, aby pokazać, jak systemy współdziałają.

Usługa Application Insights może monitorować poszczególne składniki oddzielnie i wykrywać, który składnik jest odpowiedzialny za awarie lub obniżenie wydajności przy użyciu korelacji rozproszonej telemetrii. W tym artykule wyjaśniono model danych, techniki propagacji kontekstu, protokoły i implementację taktyki korelacji na różnych językach i platformach używanych przez usługę Application Insights.

Włączanie śledzenia rozproszonego

Aby włączyć śledzenie rozproszone dla aplikacji, dodaj odpowiedniego agenta, zestawu SDK lub bibliotekę do każdej usługi na podstawie języka programowania.

Włączanie za pośrednictwem usługi Application Insights za pomocą autoinstrumentacji lub zestawów SDK

Agenci usługi Application Insights i zestawy SDK dla platform .NET, .NET Core, Java, Node.js i JavaScript obsługują natywnie rozproszone śledzenie. Dostępne są instrukcje dotyczące instalowania i konfigurowania każdego zestawu SDK usługi Application Insights:

Po zainstalowaniu i skonfigurowaniu odpowiedniego zestawu SDK usługi Application Insights informacje śledzenia są automatycznie zbierane dla popularnych struktur, bibliotek i technologii przez autokollectory zależności zestawu SDK. Pełna lista obsługiwanych technologii jest dostępna w dokumentacji autocollection zależności.

Każda technologia może być również śledzona ręcznie za pomocą wywołania funkcji TrackDependency w obiekcie TelemetryClient.

Włączanie za pośrednictwem platformy OpenTelemetry

Usługa Application Insights obsługuje teraz śledzenie rozproszone za pośrednictwem biblioteki OpenTelemetry. Funkcja OpenTelemetry zapewnia instrumentację neutralną od dostawcy w celu wysyłania śladów, metryk i dzienników do usługi Application Insights. Początkowo społeczność OpenTelemetry wzięła udział w śledzeniu rozproszonym. Metryki i dzienniki są nadal w toku.

Kompletna historia obserwacji obejmuje wszystkie trzy filary. Sprawdź stan naszych ofert opartych na usłudze Azure Monitor OpenTelemetry, aby zobaczyć najnowszy stan uwzględnionych ofert , które oferty są ogólnie dostępne i opcje pomocy technicznej.

Poniższe strony składają się ze wskazówek dotyczących języka według języka w celu włączenia i skonfigurowania ofert opartych na protokole OpenTelemetry firmy Microsoft. Co ważne, udostępniamy dostępne funkcje i ograniczenia każdej oferty, aby określić, czy usługa OpenTelemetry jest odpowiednia dla twojego projektu.

Włączanie za pośrednictwem interfejsu OpenCensus

Oprócz zestawów SDK usługi Application Insights usługa Application Insights obsługuje również śledzenie rozproszone za pośrednictwem biblioteki OpenCensus. OpenCensus to niezależna od dostawcy platforma open source, pojedyncza dystrybucja bibliotek w celu zapewnienia zbierania metryk i rozproszonego śledzenia usług. Umożliwia również społeczności open source włączanie śledzenia rozproszonego za pomocą popularnych technologii, takich jak Redis, Memcached lub MongoDB. Firma Microsoft współpracuje z firmą OpenCensus z kilkoma innymi partnerami monitorowania i chmury.

Aby uzyskać więcej informacji na temat biblioteki OpenCensus dla języka Python, zobacz Konfigurowanie usługi Azure Monitor dla aplikacji języka Python.

Witryna internetowa OpenCensus obsługuje dokumentację referencyjną interfejsu API dla języków Python, Go i różne przewodniki dotyczące korzystania z biblioteki OpenCensus.

Model danych dla korelacji telemetrii

Usługa Application Insights definiuje model danych dla korelacji rozproszonej telemetrii. Aby skojarzyć dane telemetryczne z operacją logiczną, każdy element telemetrii ma pole kontekstu o nazwie operation_Id. Każdy element telemetrii w rozproszonym śladzie współudzieli ten identyfikator. Nawet jeśli utracisz dane telemetryczne z jednej warstwy, nadal można skojarzyć dane telemetryczne zgłaszane przez inne składniki.

Rozproszona operacja logiczna zwykle składa się z zestawu mniejszych operacji, które są żądaniami przetwarzanymi przez jeden ze składników. Telemetria żądania definiuje te operacje. Każdy element telemetrii żądania ma swój własny id element, który identyfikuje go unikatowo i globalnie. Wszystkie elementy telemetrii (takie jak ślady i wyjątki), które są skojarzone z żądaniem, powinny ustawić operation_parentId wartość na wartość żądania id.

Telemetria zależności reprezentuje każdą operację wychodzącą, taką jak wywołanie HTTP do innego składnika. Definiuje również własną id , która jest globalnie unikatowa. Żądanie telemetrii zainicjowanej przez to wywołanie zależności używa tej id metody jako operation_parentId.

Widok rozproszonej operacji logicznej można utworzyć przy użyciu elementów operation_Id, operation_parentIdi request.id .dependency.id Te pola definiują również kolejność przyczynowości wywołań telemetrycznych.

W środowisku mikrousług ślady ze składników mogą przechodzić do różnych elementów magazynu. Każdy składnik może mieć własne parametry połączenia w usłudze Application Insights. Aby uzyskać dane telemetryczne dla operacji logicznej, usługa Application Insights wysyła zapytania o dane z każdego elementu magazynu.

Gdy liczba elementów magazynu jest duża, potrzebujesz wskazówki dotyczącej tego, gdzie szukać dalej. Model danych usługi Application Insights definiuje dwa pola, aby rozwiązać ten problem: request.source i dependency.target. Pierwsze pole identyfikuje składnik, który zainicjował żądanie zależności. Drugie pole identyfikuje, który składnik zwrócił odpowiedź wywołania zależności.

Aby uzyskać informacje na temat wykonywania zapytań z wielu różnych wystąpień przy użyciu app wyrażenia zapytania, zobacz wyrażenie app() w zapytaniu usługi Azure Monitor.

Przykład

Spójrzmy na przykład. Aplikacja o nazwie Ceny akcji pokazuje bieżącą cenę rynkową akcji przy użyciu zewnętrznego interfejsu API o nazwie Stock. Aplikacja Stock Prices ma stronę o nazwie Stock page (Strona giełdowa), która zostanie otwarta w przeglądarce internetowej klienta przy użyciu polecenia GET /Home/Stock. Aplikacja wysyła zapytanie do interfejsu API stock przy użyciu wywołania GET /api/stock/valueHTTP .

Możesz przeanalizować wynikową telemetrię, uruchamiając zapytanie:

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

W wynikach wszystkie elementy telemetrii współużytkuje główny operation_Idelement . Po wywołaniu Ajax ze strony zostanie przypisany nowy unikatowy identyfikator (qJSXU) do telemetrii zależności, a identyfikator pageView jest używany jako operation_ParentId. Następnie żądanie serwera używa identyfikatora Ajax jako operation_ParentId.

itemType	name	Identyfikator	operation_ParentId	operation_Id
pageView	Strona zapasów	`STYz`		`STYz`
zależność	GET /Home/Stock	`qJSXU`	`STYz`	`STYz`
żądanie	GET Home/Stock	`KqKwlrSt9PA=`	`qJSXU`	`STYz`
zależność	GET /api/stock/value	`bBrf2L7mm2g=`	`KqKwlrSt9PA=`	`STYz`

Po wywołaniu GET /api/stock/value usługi zewnętrznej należy znać tożsamość tego serwera, aby można było odpowiednio ustawić dependency.target pole. Jeśli usługa zewnętrzna nie obsługuje monitorowania, target jest ustawiona na nazwę hosta usługi. Może to być na przykład stock-prices-api.com. Jeśli jednak usługa identyfikuje się, zwracając wstępnie zdefiniowany nagłówek HTTP, zawiera tożsamość usługi, target która umożliwia usłudze Application Insights tworzenie rozproszonego śledzenia przez wykonywanie zapytań dotyczących danych telemetrycznych z tej usługi.

Nagłówki korelacji przy użyciu elementu TraceContext W3C

Usługa Application Insights przechodzi do kontekstu śledzenia W3C, który definiuje:

traceparent: prowadzi globalnie unikatowy identyfikator operacji i unikatowy identyfikator wywołania.
tracestate: przenosi kontekst śledzenia specyficzny dla systemu.

Najnowsza wersja zestawu SDK usługi Application Insights obsługuje protokół Trace-Context, ale może być konieczne jego wybranie. (Zgodność z poprzednim protokołem korelacji obsługiwanym przez zestaw SDK usługi Application Insights jest obsługiwana).

Protokół HTTP korelacji, nazywany również identyfikatorem żądania, jest przestarzały. Ten protokół definiuje dwa nagłówki:

Request-Id: prowadzi globalnie unikatowy identyfikator wywołania.
Correlation-Context: zawiera kolekcję par name-value właściwości rozproszonego śledzenia.

Usługa Application Insights definiuje również rozszerzenie dla protokołu HTTP korelacji. Używa Request-Context par name-value do propagowania kolekcji właściwości używanych przez natychmiastowe wywołanie lub wywoływanie. Zestaw SDK usługi Application Insights używa tego nagłówka do ustawiania dependency.target pól i request.source .

Modele danych Trace-Context i Application Insights W3C są mapowe w następujący sposób:

Szczegółowe dane dotyczące aplikacji	W3C TraceContext
`Id`i `RequestDependency`	identyfikator elementu nadrzędnego
`Operation_Id`	trace-id
`Operation_ParentId`	parent-id tego zakresu nadrzędnego. To pole musi być puste, jeśli jest to zakres główny.

Aby uzyskać więcej informacji, zobacz Model danych telemetrycznych usługi Application Insights.

Włączanie obsługi śledzenia rozproszonego W3C dla aplikacji platformy .NET

Śledzenie rozproszone oparte na protokole W3C TraceContext jest domyślnie włączone we wszystkich ostatnich zestawach SDK .NET Framework/.NET Core wraz ze zgodnością z poprzednimi wersjami ze starszym protokołem Request-Id.

Włączanie obsługi śledzenia rozproszonego W3C dla aplikacji Java

Agent java 3.0

Agent java 3.0 obsługuje gotowe środowisko W3C i nie jest wymagana żadna konfiguracja.

Zestaw SDK Java

Konfiguracja przychodząca

W przypadku aplikacji Java EE dodaj następujący kod do tagu <TelemetryModules> w ApplicationInsights.xml:
```
<Add type="com.microsoft.applicationinsights.web.extensibility.modules.WebRequestTrackingTelemetryModule>
   <Param name = "W3CEnabled" value ="true"/>
   <Param name ="enableW3CBackCompat" value = "true" />
</Add>
```
W przypadku aplikacji Spring Boot dodaj następujące właściwości:
- azure.application-insights.web.enable-W3C=true
- azure.application-insights.web.enable-W3C-backcompat-mode=true
Konfiguracja wychodząca

Dodaj następujący kod, aby AI-Agent.xml:
```
<Instrumentation>
  <BuiltIn enabled="true">
    <HTTP enabled="true" W3C="true" enableW3CBackCompat="true"/>
  </BuiltIn>
</Instrumentation>
```
Uwaga

Tryb zgodności z poprzednimi wersjami jest domyślnie włączony, a enableW3CBackCompat parametr jest opcjonalny. Używaj jej tylko wtedy, gdy chcesz wyłączyć zgodność z poprzednimi wersjami.

W idealnym przypadku wyłączysz ten tryb, gdy wszystkie usługi zostaną zaktualizowane do nowszych wersji zestawów SDK obsługujących protokół W3C. Zdecydowanie zalecamy jak najszybsze przejście do tych nowszych zestawów SDK.

Ważne jest, aby upewnić się, że konfiguracje przychodzące i wychodzące są dokładnie takie same.

Włączanie obsługi śledzenia rozproszonego W3C dla aplikacji internetowych

Ta funkcja jest domyślnie włączona dla języka JavaScript, a nagłówki są automatycznie dołączane, gdy domena strony hostingu jest taka sama jak domena, do której są wysyłane żądania (na przykład strona hostingu, example.com a żądania Ajax są wysyłane do example.comusługi ). Aby zmienić tryb śledzenia rozproszonego, użyj distributedTracingMode pola konfiguracji. AI_AND_W3C jest domyślnie zapewniana w celu zapewnienia zgodności z poprzednimi wersjami ze wszystkimi starszymi usługami instrumentowanych przez usługę Application Insights.

Konfiguracja oparta na programie npm

Dodaj następującą konfigurację:
```
  distributedTracingMode: DistributedTracingModes.W3C
```
Konfiguracja oparta na skrypcie zestawu SDK języka JavaScript (internetowego) modułu ładującego

Dodaj następującą konfigurację:
```
    distributedTracingMode: 2 // DistributedTracingModes.W3C
```

Jeśli żądania XMLHttpRequest lub Ajax pobierania są wysyłane do innego hosta domeny, w tym poddomeny, nagłówki korelacji nie są domyślnie uwzględniane. Aby włączyć tę funkcję, ustaw enableCorsCorrelation pole konfiguracji na truewartość . Jeśli ustawiono wartość enableCorsCorrelation true, wszystkie żądania XMLHttpRequest i Ajax pobierania zawierają nagłówki korelacji. W związku z tym, jeśli aplikacja na serwerze, który jest wywoływany, nie obsługuje traceparent nagłówka, żądanie może zakończyć się niepowodzeniem, w zależności od tego, czy przeglądarka / wersja może zweryfikować żądanie na podstawie nagłówków, które akceptuje serwer. Za pomocą correlationHeaderExcludedDomains pola konfiguracji można wykluczyć domenę serwera z iniekcji nagłówka korelacji między składnikami. Na przykład można użyć correlationHeaderExcludedDomains: ['*.auth0.com'] polecenia , aby wykluczyć nagłówki korelacji z żądań wysyłanych do dostawcy tożsamości Auth0.

Ważne

Aby wyświetlić wszystkie konfiguracje wymagane do włączenia korelacji, zobacz dokumentację korelacji języka JavaScript.

Korelacja telemetrii w języku OpenCensus Python

Język OpenCensus Python obsługuje kontekst śledzenia W3C bez konieczności dodatkowej konfiguracji.

Aby zapoznać się z dokumentacją, możesz znaleźć model danych OpenCensus na tej stronie usługi GitHub.

Korelacja żądań przychodzących

Język OpenCensus Python koreluje nagłówki W3C Trace-Context z żądań przychodzących do zakresów generowanych na podstawie samych żądań. Rozwiązanie OpenCensus jest skorelowane automatycznie z integracją dla tych popularnych struktur aplikacji internetowych: Flask, Django i Pyramid. Wystarczy wypełnić nagłówki W3C Trace-Context prawidłowym formatem i wysłać je za pomocą żądania.

Zapoznaj się z tą przykładową aplikacją platformy Flask. Zainstaluj platformę Flask, openCensus oraz rozszerzenia platformy Flask i platformy Azure.


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

Musisz dodać parametry połączenia usługi Application Insights do zmiennej środowiskowej.

APPLICATIONINSIGHTS_CONNECTION_STRING=<appinsights-connection-string>

Przykładowa aplikacja platformy Flask

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)

Ten kod uruchamia przykładową aplikację Platformy Flask na komputerze lokalnym, nasłuchując na porcie 8080. Aby skorelować kontekst śledzenia, należy wysłać żądanie do punktu końcowego. W tym przykładzie curl można użyć polecenia :

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

Patrząc na format nagłówka Trace-Context, można uzyskać następujące informacje:

version: 00

trace-id: 4bf92f3577b34da6a3ce929d0e0e4736

parent-id/span-id: 00f067aa0ba902b7

trace-flags: 01

Jeśli spojrzysz na wpis żądania, który został wysłany do usługi Azure Monitor, możesz zobaczyć pola wypełnione informacjami nagłówka śledzenia. Dane można znaleźć w obszarze Dzienniki (analiza) w zasobie usługi Azure Monitor Application Insights.

Pole id jest w formacie <trace-id>.<span-id>, gdzie trace-id jest pobierane z nagłówka śledzenia, który został przekazany w żądaniu i span-id jest wygenerowaną tablicą 8-bajtową dla tego zakresu.

Pole operation_ParentId jest w formacie <trace-id>.<parent-id>, gdzie zarówno trace-id , jak i parent-id są pobierane z nagłówka śledzenia, który został przekazany w żądaniu.

Korelacja dzienników

Język OpenCensus w języku Python umożliwia skorelowanie dzienników przez dodanie identyfikatora śledzenia, identyfikatora zakresu i flagi próbkowania w celu rejestrowania rekordów. Te atrybuty można dodać, instalując integrację rejestrowania openCensus. Następujące atrybuty są dodawane do obiektów języka Python LogRecord : traceId, spanIdi traceSampled (dotyczy tylko rejestratorów utworzonych po integracji).

Zainstaluj integrację rejestrowania OpenCensus:

python -m pip install opencensus-ext-logging

Przykładowa aplikacja

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

Po uruchomieniu tego kodu w konsoli programu są wyświetlane następujące elementy:

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

Zwróć uwagę, że istnieje spanId komunikat dziennika, który znajduje się w obrębie zakresu. Wartość spanId jest taka sama jak ta, która należy do zakresu o nazwie hello.

Dane dziennika można wyeksportować przy użyciu polecenia AzureLogHandler. Aby uzyskać więcej informacji, zobacz Konfigurowanie usługi Azure Monitor dla aplikacji języka Python.

Możemy również przekazać informacje śledzenia z jednego składnika do drugiego w celu uzyskania odpowiedniej korelacji. Rozważmy na przykład scenariusz, w którym istnieją dwa składniki: module1 i module2. Moduł 1 wywołuje funkcje w module 2. Aby pobrać dzienniki zarówno z module1 jednego śladu, jak i module2 w jednym śladzie, możemy użyć następującego podejścia:

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

Korelacja telemetrii na platformie .NET

Korelacja jest domyślnie obsługiwana podczas dołączania aplikacji. Nie są wymagane żadne akcje specjalne.

Środowisko uruchomieniowe platformy .NET obsługuje dystrybucję za pomocą działania i źródła diagnostycznego

Zestaw .NET SDK usługi Application Insights używa DiagnosticSource funkcji i Activity do zbierania i korelowania danych telemetrycznych.

Korelacja telemetrii w języku Java

Agent języka Java obsługuje automatyczną korelację danych telemetrycznych. Jest on automatycznie wypełniany operation_id dla wszystkich danych telemetrycznych (takich jak ślady, wyjątki i zdarzenia niestandardowe) wystawionych w zakresie żądania. Propaguje również nagłówki korelacji, które zostały opisane wcześniej dla wywołań między usługami za pośrednictwem protokołu HTTP, jeśli agent zestawu JAVA SDK jest skonfigurowany.

Uwaga

Agent Java usługi Application Insights automatycznie wykonuje żądania i zależności dla JMS, Kafka, Netty/Webflux i nie tylko. W przypadku zestawu JAVA SDK obsługiwane są tylko wywołania wykonywane za pośrednictwem klienta Apache HttpClient dla funkcji korelacji. Automatyczna propagacja kontekstu między technologiami obsługi komunikatów, takimi jak Kafka, RabbitMQ i Azure Service Bus, nie jest obsługiwana w zestawie SDK.

Aby zbierać niestandardowe dane telemetryczne, należy instrumentować aplikację przy użyciu zestawu JAVA 2.6 SDK.

Nazwy ról

Możesz dostosować sposób wyświetlania nazw składników w mapie aplikacji. W tym celu można ręcznie ustawić cloud_RoleName , wykonując jedną z następujących akcji:

W przypadku języka Java usługi Application Insights ustaw nazwę roli w chmurze w następujący sposób:
```
{
  "role": {
    "name": "my cloud role name"
  }
}
```
Nazwę roli chmury można również ustawić przy użyciu zmiennej środowiskowej APPLICATIONINSIGHTS_ROLE_NAME.

Zestaw Java SDK 2.5.0 lub nowszy usługi Application Insights można określić cloud_RoleName , dodając <RoleName> do pliku ApplicationInsights.xml :

<?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>

Jeśli używasz platformy Spring Boot z szablonem startowym Application Insights Spring Boot, ustaw niestandardową nazwę aplikacji w pliku application.properties :

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

Możesz również ustawić nazwę roli chmury za pomocą zmiennej środowiskowej lub właściwości systemowej. Aby uzyskać szczegółowe informacje, zobacz Konfigurowanie nazwy roli w chmurze.

Następne kroki

Mapa aplikacji
Pisanie niestandardowych danych telemetrycznych.
Aby uzyskać zaawansowane scenariusze korelacji w programie ASP.NET Core i ASP.NET, zobacz Śledzenie operacji niestandardowych.
Dowiedz się więcej o ustawianiu cloud_RoleName dla innych zestawów SDK.
Dołącz wszystkie składniki mikrousługi w usłudze Application Insights. Zapoznaj się z obsługiwanymi platformami.
Zobacz model danych dla typów usługi Application Insights.
Dowiedz się, jak rozszerzać i filtrować dane telemetryczne.
Zapoznaj się z dokumentacją konfiguracji usługi Application Insights.

Udostępnij za pośrednictwem