Udostępnij za pośrednictwem

Co to jest rozproszone śledzenie i korelacja telemetrii?

Uwaga

Zalecamy użycie dystrybucji Azure Monitor OpenTelemetry dla nowych aplikacji lub klientów, w celu wsparcia działania Azure Monitor Application Insights. Dystrybucja OpenTelemetry usługi Azure Monitor zapewnia podobną funkcjonalność i środowisko jako zestaw SDK usługi Application Insights. Migracja z zestawu SDK usługi Application Insights jest możliwa przy użyciu przewodników migracji dla platformy .NET, Node.js i języka Python, ale nadal pracujemy nad dodaniem kilku dodatkowych funkcji w celu zapewnienia zgodności z poprzednimi wersjami.

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 całościowe systemy stały się trudniejsze do rozumienia i debugowania. Ś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, pakiet SDK lub biblioteki 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 SDK Application Insights, informacje dotyczące śledzenia są automatycznie zbierane dla popularnych frameworków, bibliotek i technologii przez autokolektory zależności SDK. Pełna lista obsługiwanych technologii jest dostępna w dokumentacji automatycznego zbierania 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. OpenTelemetry zapewnia neutralną od dostawcy instrumentację do wysyłania śladów, metryk i dzienników do usługi Application Insights. Początkowo społeczność OpenTelemetry zajęła się śledzeniem rozproszonym. Metryki i logi 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 dzieli się tym identyfikatorem. 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, który identyfikuje go jednoznacznie i globalnie. Wszystkie elementy telemetrii (takie jak ślady i wyjątki), które są skojarzone z żądaniem, powinny mieć ustawioną wartość zgodnie z wartością żądania operation_parentId.

Telemetria zależności reprezentuje każdą operację wychodzącą, na przykład wywołanie HTTP do innego składnika. Definiuje też własną id, która jest globalnie unikatowa. Żądanie telemetrii, zainicjowane przez to wywołanie zależności, używa tego id 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ładowych mogą przechodzić do różnych elementów pamięci masowej. 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 dzielą główny operation_Id. Po wykonaniu wywołania Ajax ze strony przypisuje się nowy, unikalny identyfikator (qJSXU) do telemetrii zależności, a identyfikator widoku strony jest używany jako operation_ParentId. Następnie żądanie serwera używa identyfikatora Ajax jako operation_ParentId.

typ elementu nazwa identyfikator operation_ParentId identyfikator_operacji
widok strony Strona zapasów STYz STYz
zależność GET /Home/Stock qJSXU STYz STYz
żądanie GET Strona główna/Zapas 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, target zawiera tożsamość usługi, która umożliwia aplikacji Application Insights tworzenie rozproszonego śledzenia poprzez wykonywanie zapytań dotyczących danych telemetrycznych z tej usługi.

Nagłówki korelacji zgodnie z W3C TraceContext

Usługa Application Insights przechodzi na W3C Trace-Context, który definiuje:

  • traceparent: Zawiera globalnie unikalny identyfikator operacji i unikalny identyfikator wywołania.
  • tracestate: zawiera 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. (Zachowano zgodność z poprzednim protokołem korelacji obsługiwanym przez zestaw SDK Application Insights.)

Protokół HTTP korelacji, nazywany również Request-Id, jest wycofywany. Ten protokół definiuje dwa nagłówki:

  • Request-Id: niesie globalny, unikatowy ID wywołania.
  • Correlation-Context: zawiera kolekcję par klucz-wartość rozproszonych właściwości śledzenia.

Usługa Application Insights definiuje również rozszerzenie dla protokołu HTTP korelacji. Używa Request-Context par nazwa-wartość do propagowania kolekcji właściwości używanych przez bezpośredniego wywołującego lub wywoływanego. Zestaw SDK usługi Application Insights używa tego nagłówka do ustawiania pól dependency.target i request.source.

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

Application Insights W3C TraceContext
Idi RequestDependency identyfikator rodzica
Operation_Id trace-id
Operation_ParentId parent-id nadrzędnego zakresu tego fragmentu. 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 najnowszych wersjach SDK .NET Framework/.NET Core, wraz z wsteczną kompatybilnością 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.

Java SDK

  • 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 do pliku 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 dostarczane w celu zapewnienia zgodności wstecznej z wszelkimi starszymi usługami zainstrumentowanymi przez Application Insights.

Jeśli żądania XMLHttpRequest lub Fetch albo Ajax są wysyłane do innego hosta domeny, w tym do poddomen, nagłówki korelacji nie są domyślnie uwzględniane. Aby włączyć tę funkcję, ustaw pole konfiguracji enableCorsCorrelation na true. Jeśli ustawisz enableCorsCorrelation na true, wszystkie żądania XMLHttpRequest i Ajax Fetch będą zawierać nagłówki korelacyjne. 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 dodawania nagłówka korelacji między składnikami. Na przykład można użyć correlationHeaderExcludedDomains: ['*.auth0.com'], 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

Biblioteka OpenCensus Python obsługuje W3C Trace-Context 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

OpenCensus Python powiązuje nagłówki W3C Trace-Context z żądań przychodzących z odcinkami generowanymi z tych żądań. OpenCensus automatycznie integruje się z popularnymi frameworkami 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ę Flask na komputerze lokalnym, nasłuchując portu 8080. Aby skorelować kontekst śledzenia, należy wysłać żądanie do punktu końcowego. W tym przykładzie możesz użyć polecenia curl.

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.

Zrzut ekranu przedstawiający telemetrię żądania w dziennikach (Analytics).

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

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ł przesłany w żądaniu.

Korelacja logów

OpenCensus Python umożliwia skorelowanie dzienników poprzez dodanie identyfikatora ścieżki, identyfikatora zakresu i flagi próbkowania do rekordów dziennikó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 są wyświetlane następujące komunikaty.

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 uzyskać dzienniki zarówno z module1, 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ą Activity i DiagnosticSource.

Zestaw SDK platformy .NET dla usługi Application Insights korzysta z DiagnosticSource 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 korelacyjne, które zostały opisane wcześniej dla wywołań między usługami za pośrednictwem protokołu HTTP, jeśli skonfigurowano agenta Java SDK.

Uwaga

Agent Java usługi Application Insights automatycznie zbiera żą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 usługi Application Insights Java, 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.

  • Używając Java SDK 2.5.0 lub nowszego dla Application Insights, można określić cloud_RoleName poprzez dodanie <RoleName> do pliku ApplicationInsights.xml:

    Zrzut ekranu przedstawiający przegląd i parametry połączenia usługi Application Insights. 

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