Śledzenie operacji niestandardowych za pomocą usługi Application Szczegółowe informacje .NET SDK

Zestawy SDK usługi Azure Application Szczegółowe informacje automatycznie śledzą przychodzące żądania HTTP i wywołania do usług zależnych, takich jak żądania HTTP i SQL zapytania. Śledzenie i korelacja żądań i zależności zapewniają wgląd w czas odpowiedzi i niezawodność całej aplikacji we wszystkich mikrousługach, które łączą tę aplikację.

Istnieje klasa wzorców aplikacji, które nie mogą być obsługiwane ogólnie. Prawidłowe monitorowanie takich wzorców wymaga ręcznej instrumentacji kodu. Ten artykuł zawiera kilka wzorców, które mogą wymagać ręcznej instrumentacji, takich jak niestandardowe przetwarzanie kolejek i uruchamianie długotrwałych zadań w tle.

Ten dokument zawiera wskazówki dotyczące śledzenia operacji niestandardowych przy użyciu zestawu SDK usługi Application Szczegółowe informacje. Ta dokumentacja dotyczy:

  • Pakiet Szczegółowe informacje dla platformy .NET (znany także jako podstawowy zestaw SDK) w wersji 2.4 lub nowszej.
  • Application Szczegółowe informacje for web applications (running ASP.NET) version 2.4+.
  • Application Szczegółowe informacje for ASP.NET Core version 2.1+.

Omówienie

Operacja to logiczny element pracy uruchamiany przez aplikację. Ma nazwę, czas rozpoczęcia, czas trwania, wynik i kontekst wykonywania, taki jak nazwa użytkownika, właściwości i wynik. Jeśli operacja A została zainicjowana przez operację B, operacja B zostanie ustawiona jako operacja nadrzędna dla operacji A. Operacja może mieć tylko jeden element nadrzędny, ale może mieć wiele operacji podrzędnych. Aby uzyskać więcej informacji na temat korelacji operacji i telemetrii, zobacz Korelacja telemetriiusługi Azure Application Szczegółowe informacje .

W zestawie SDK programu Application Szczegółowe informacje .NET operacja jest opisana przez klasę abstrakcyjną OperationTelemetry i jej elementy potomne RequestTelemetry i DependencyTelemetry.

Śledzenie operacji przychodzących

Zestaw SDK Szczegółowe informacje automatycznie zbiera żądania HTTP dla aplikacji ASP.NET uruchamianych w potoku usług IIS i wszystkich ASP.NET Core aplikacji. Istnieją rozwiązania obsługiwane przez społeczność dla innych platform i platform. Jeśli jednak aplikacja nie jest obsługiwana przez żadne standardowe lub wspierane przez społeczność rozwiązania, możesz instrumentować ją ręcznie.

Innym przykładem, który wymaga śledzenia niestandardowego, jest proces roboczy, który odbiera elementy z kolejki. W przypadku niektórych kolejek wywołanie dodawania komunikatu do tej kolejki jest śledzone jako zależność. Jednak operacja wysokiego poziomu opisującą przetwarzanie komunikatów nie jest automatycznie zbierana.

Zobaczmy, jak można śledzić takie operacje.

Na wysokim poziomie zadaniem jest utworzenie i RequestTelemetry ustawienie znanych właściwości. Po zakończeniu operacji możesz śledzić telemetrię. W poniższym przykładzie pokazano to zadanie.

Żądanie HTTP w aplikacji Owin (self-hosted)

W tym przykładzie kontekst śledzenia jest propagowany zgodnie z protokołem HTTP korelacji. Należy oczekiwać, że otrzymasz nagłówki opisane w tym miejscu.

public class ApplicationInsightsMiddleware : OwinMiddleware
{
    // you may create a new TelemetryConfiguration instance, reuse one you already have
    // or fetch the instance created by Application Insights SDK.
    private readonly TelemetryConfiguration telemetryConfiguration = TelemetryConfiguration.CreateDefault();
    private readonly TelemetryClient telemetryClient = new TelemetryClient(telemetryConfiguration);
    
    public ApplicationInsightsMiddleware(OwinMiddleware next) : base(next) {}

    public override async Task Invoke(IOwinContext context)
    {
        // Let's create and start RequestTelemetry.
        var requestTelemetry = new RequestTelemetry
        {
            Name = $"{context.Request.Method} {context.Request.Uri.GetLeftPart(UriPartial.Path)}"
        };

        // If there is a Request-Id received from the upstream service, set the telemetry context accordingly.
        if (context.Request.Headers.ContainsKey("Request-Id"))
        {
            var requestId = context.Request.Headers.Get("Request-Id");
            // Get the operation ID from the Request-Id (if you follow the HTTP Protocol for Correlation).
            requestTelemetry.Context.Operation.Id = GetOperationId(requestId);
            requestTelemetry.Context.Operation.ParentId = requestId;
        }

        // StartOperation is a helper method that allows correlation of 
        // current operations with nested operations/telemetry
        // and initializes start time and duration on telemetry items.
        var operation = telemetryClient.StartOperation(requestTelemetry);

        // Process the request.
        try
        {
            await Next.Invoke(context);
        }
        catch (Exception e)
        {
            requestTelemetry.Success = false;
            telemetryClient.TrackException(e);
            throw;
        }
        finally
        {
            // Update status code and success as appropriate.
            if (context.Response != null)
            {
                requestTelemetry.ResponseCode = context.Response.StatusCode.ToString();
                requestTelemetry.Success = context.Response.StatusCode >= 200 && context.Response.StatusCode <= 299;
            }
            else
            {
                requestTelemetry.Success = false;
            }

            // Now it's time to stop the operation (and track telemetry).
            telemetryClient.StopOperation(operation);
        }
    }
    
    public static string GetOperationId(string id)
    {
        // Returns the root ID from the '|' to the first '.' if any.
        int rootEnd = id.IndexOf('.');
        if (rootEnd < 0)
            rootEnd = id.Length;

        int rootStart = id[0] == '|' ? 1 : 0;
        return id.Substring(rootStart, rootEnd - rootStart);
    }
}

Protokół HTTP dla korelacji również deklaruje Correlation-Context nagłówek . Jednak pominięto ją w tym miejscu dla uproszczenia.

Instrumentacja kolejki

Chociaż istnieją kontekst śledzenia W3C i protokół HTTP korelacji do przekazania szczegółów korelacji z żądaniem HTTP, każdy protokół kolejki musi zdefiniować sposób przekazania tych samych szczegółów w komunikacie kolejki. Niektóre protokoły kolejek (takie jak AMQP) umożliwiają przekazywanie dodatkowych metadanych, a inne (takie jak Azure Storage Queue) wymagają zakodowania kontekstu do ładunku komunikatów.

Uwaga

  • Śledzenie między składnikami nie jest jeszcze obsługiwane w przypadku kolejek W przypadku protokołu HTTP, jeśli producent i użytkownik wysyłają dane telemetryczne do różnych zasobów usługi Application Szczegółowe informacje, środowisko diagnostyki transakcji i mapa aplikacji pokazują transakcje i mapowanie na wszystkich urządzeniach. W przypadku kolejek nie jest to jeszcze obsługiwane.

Kolejka usługi Service Bus

Usługa Application Szczegółowe informacje śledzi Service Bus komunikatów za pomocą nowego klienta Microsoft Azure ServiceBus dla programu .NET w wersji 3.0.0 lub nowszej. Jeśli używasz wzorca procedury obsługi komunikatów do przetwarzania komunikatów, wszystko jest gotowe: wszystkie wywołania Service Bus wykonywane przez usługę są automatycznie śledzone i skorelowane z innymi elementami telemetrii. Jeśli ręcznie przetwarzasz komunikaty, zapoznaj się Service Bus śledzeniem klientów za pomocą usługi Microsoft Application Szczegółowe informacje.

Jeśli używasz pakietu WindowsAzure.ServiceBus, przeczytaj więcej — w poniższych przykładach pokazano, jak śledzić (i korelować) wywołania do usługi Service Bus, ponieważ kolejka usługi Service Bus używa protokołu AMQP, a usługa Application Szczegółowe informacje nie śledzi automatycznie operacji kolejki. Identyfikatory korelacji są przekazywane we właściwościach komunikatu.

Kolejka

public async Task Enqueue(string payload)
{
    // StartOperation is a helper method that initializes the telemetry item
    // and allows correlation of this operation with its parent and children.
    var operation = telemetryClient.StartOperation<DependencyTelemetry>("enqueue " + queueName);
    
    operation.Telemetry.Type = "Azure Service Bus";
    operation.Telemetry.Data = "Enqueue " + queueName;

    var message = new BrokeredMessage(payload);
    // Service Bus queue allows the property bag to pass along with the message.
    // We will use them to pass our correlation identifiers (and other context)
    // to the consumer.
    message.Properties.Add("ParentId", operation.Telemetry.Id);
    message.Properties.Add("RootId", operation.Telemetry.Context.Operation.Id);

    try
    {
        await queue.SendAsync(message);
        
        // Set operation.Telemetry Success and ResponseCode here.
        operation.Telemetry.Success = true;
    }
    catch (Exception e)
    {
        telemetryClient.TrackException(e);
        // Set operation.Telemetry Success and ResponseCode here.
        operation.Telemetry.Success = false;
        throw;
    }
    finally
    {
        telemetryClient.StopOperation(operation);
    }
}

Proces

public async Task Process(BrokeredMessage message)
{
    // After the message is taken from the queue, create RequestTelemetry to track its processing.
    // It might also make sense to get the name from the message.
    RequestTelemetry requestTelemetry = new RequestTelemetry { Name = "process " + queueName };

    var rootId = message.Properties["RootId"].ToString();
    var parentId = message.Properties["ParentId"].ToString();
    // Get the operation ID from the Request-Id (if you follow the HTTP Protocol for Correlation).
    requestTelemetry.Context.Operation.Id = rootId;
    requestTelemetry.Context.Operation.ParentId = parentId;

    var operation = telemetryClient.StartOperation(requestTelemetry);

    try
    {
        await ProcessMessage();
    }
    catch (Exception e)
    {
        telemetryClient.TrackException(e);
        throw;
    }
    finally
    {
        // Update status code and success as appropriate.
        telemetryClient.StopOperation(operation);
    }
}

Kolejka Storage Azure

W poniższym przykładzie pokazano, jak śledzić operacje kolejki usługi Azure Storage i korelować dane telemetryczne między producentem, konsumentem i usługą Azure Storage.

Kolejka Storage ma interfejs API protokołu HTTP. Wszystkie wywołania kolejki są śledzone przez moduł zbierający zależności Szczegółowe informacje Application dla żądań HTTP. Jest on konfigurowany domyślnie w ASP.NET i ASP.NET Core, z innymi rodzajami aplikacji, można zapoznać się z dokumentacją aplikacji konsolowych

Możesz również skorelować identyfikator operacji application Szczegółowe informacje z identyfikatorem Storage żądania. Aby uzyskać informacje na temat sposobu ustawienia i uzyskania klienta żądania Storage identyfikatora żądania serwera, zobacz Monitorowanie,diagnozowanie i rozwiązywanie problemów z usługą Azure Storage .

Kolejka

Ponieważ Storage obsługują interfejs API protokołu HTTP, wszystkie operacje z kolejką są automatycznie śledzone przez usługi Application Szczegółowe informacje. W wielu przypadkach ta instrumentacja powinna wystarczyć. Jednak aby skorelować ślady po stronie konsumenta ze śladami producenta, należy przekazać kontekst korelacji podobny do tego w protokole HTTP dla korelacji.

W tym przykładzie pokazano, jak śledzić Enqueue operację. Oto co możesz zrobić:

  • Skoreluj ponowne próby (jeśli są): wszystkie one mają jeden wspólny element nadrzędny, który jest operacją. W przeciwnym razie są one śledzone jako dzieci żądania przychodzącego. Jeśli kolejka zawiera wiele żądań logicznych, znalezienie wywołania, które zakończyło się ponownymi próbami, może być trudne.
  • Korelowanie Storage (w razie potrzeby): są one skorelowane z telemetrią Szczegółowe informacje aplikacji.

Operacja Enqueue jest elementem podrzędnym operacji nadrzędnej (na przykład przychodzącego żądania HTTP). Wywołanie zależności HTTP jest podrzędne operacji Enqueue i grandchild żądania przychodzącego:

public async Task Enqueue(CloudQueue queue, string message)
{
    var operation = telemetryClient.StartOperation<DependencyTelemetry>("enqueue " + queue.Name);
    operation.Telemetry.Type = "Azure queue";
    operation.Telemetry.Data = "Enqueue " + queue.Name;

    // MessagePayload represents your custom message and also serializes correlation identifiers into payload.
    // For example, if you choose to pass payload serialized to JSON, it might look like
    // {'RootId' : 'some-id', 'ParentId' : '|some-id.1.2.3.', 'message' : 'your message to process'}
    var jsonPayload = JsonConvert.SerializeObject(new MessagePayload
    {
        RootId = operation.Telemetry.Context.Operation.Id,
        ParentId = operation.Telemetry.Id,
        Payload = message
    });
    
    CloudQueueMessage queueMessage = new CloudQueueMessage(jsonPayload);

    // Add operation.Telemetry.Id to the OperationContext to correlate Storage logs and Application Insights telemetry.
    OperationContext context = new OperationContext { ClientRequestID = operation.Telemetry.Id};

    try
    {
        await queue.AddMessageAsync(queueMessage, null, null, new QueueRequestOptions(), context);
    }
    catch (StorageException e)
    {
        operation.Telemetry.Properties.Add("AzureServiceRequestID", e.RequestInformation.ServiceRequestID);
        operation.Telemetry.Success = false;
        operation.Telemetry.ResultCode = e.RequestInformation.HttpStatusCode.ToString();
        telemetryClient.TrackException(e);
    }
    finally
    {
        // Update status code and success as appropriate.
        telemetryClient.StopOperation(operation);
    }
}  

Aby zmniejszyć ilość telemetrii raportów aplikacji lub jeśli nie chcesz śledzić operacji z innych powodów, użyj EnqueueActivity interfejsu API bezpośrednio:

  • Utwórz (i uruchom) nowy, Activity zamiast uruchamiać operację application Szczegółowe informacje. Nie trzeba przypisywać do niego żadnych właściwości z wyjątkiem nazwy operacji.
  • Serializuj yourActivity.Id do ładunku komunikatu zamiast operation.Telemetry.Id . Możesz również użyć funkcji Activity.Current.Id .

Dequeue (Dequeue)

Podobnie jak w przypadku żądania HTTP do kolejki Storage jest automatycznie śledzone przez Enqueue program Application Szczegółowe informacje. Jednak operacja prawdopodobnie Enqueue odbywa się w kontekście nadrzędnym, takim jak kontekst żądania przychodzącego. Zestawy SDK Szczegółowe informacje automatycznie skorelują taką operację (i jej część HTTP) z żądaniem nadrzędnym i innymi telemetriami zgłoszonymi w tym samym zakresie.

Operacja Dequeue jest trudna. Zestaw SDK usługi Application Szczegółowe informacje automatycznie śledzi żądania HTTP. Jednak nie zna kontekstu korelacji, dopóki komunikat nie zostanie analizowany. Nie można skorelować żądania HTTP w celu uzyskania komunikatu z resztą telemetrii, szczególnie w przypadku odebrania więcej niż jednego komunikatu.

public async Task<MessagePayload> Dequeue(CloudQueue queue)
{
    var operation = telemetryClient.StartOperation<DependencyTelemetry>("dequeue " + queue.Name);
    operation.Telemetry.Type = "Azure queue";
    operation.Telemetry.Data = "Dequeue " + queue.Name;
    
    try
    {
        var message = await queue.GetMessageAsync();
    }
    catch (StorageException e)
    {
        operation.telemetry.Properties.Add("AzureServiceRequestID", e.RequestInformation.ServiceRequestID);
        operation.telemetry.Success = false;
        operation.telemetry.ResultCode = e.RequestInformation.HttpStatusCode.ToString();
        telemetryClient.TrackException(e);
    }
    finally
    {
        // Update status code and success as appropriate.
        telemetryClient.StopOperation(operation);
    }

    return null;
}

Proces

W poniższym przykładzie przychodzący komunikat jest śledzony w sposób podobny do przychodzącego żądania HTTP:

public async Task Process(MessagePayload message)
{
    // After the message is dequeued from the queue, create RequestTelemetry to track its processing.
    RequestTelemetry requestTelemetry = new RequestTelemetry { Name = "process " + queueName };
    
    // It might also make sense to get the name from the message.
    requestTelemetry.Context.Operation.Id = message.RootId;
    requestTelemetry.Context.Operation.ParentId = message.ParentId;

    var operation = telemetryClient.StartOperation(requestTelemetry);

    try
    {
        await ProcessMessage();
    }
    catch (Exception e)
    {
        telemetryClient.TrackException(e);
        throw;
    }
    finally
    {
        // Update status code and success as appropriate.
        telemetryClient.StopOperation(operation);
    }
}

Podobnie inne operacje kolejki mogą być instrumentowane. Operację podglądu należy instrumentować w podobny sposób jak operację dequeue. Instrumentowanie operacji zarządzania kolejkami nie jest konieczne. Aplikacja Szczegółowe informacje śledzi operacje, takie jak HTTP, i w większości przypadków wystarczy.

Podczas instrumentowania usuwania komunikatów upewnij się, że ustawiono identyfikatory operacji (korelacji). Alternatywnie możesz użyć interfejsu Activity API. Następnie nie musisz ustawiać identyfikatorów operacji dla elementów telemetrii, ponieważ zestaw SDK usługi Application Szczegółowe informacje robi to za Ciebie:

  • Utwórz nowy Activity element po utworzeniu elementu z kolejki.
  • Użyj Activity.SetParentId(message.ParentId) , aby skorelować dzienniki konsumentów i producentów.
  • Uruchom Activity .
  • Śledzenie operacji usuwania z kolejkowania, przetwarzania i usuwania przy użyciu Start/StopOperation pomocników. Zrób to z tego samego asynchronicznego przepływu sterowania (kontekstu wykonywania). W ten sposób są one prawidłowo skorelowane.
  • Zatrzymaj Activity .
  • Użyj Start/StopOperation funkcji lub wywołaj Track telemetrię ręcznie.

Typy zależności

Interfejs Szczegółowe informacje używa typu zależności do dostosowywania interfejsu użytkownika. W przypadku kolejek rozpoznaje następujące typy, które DependencyTelemetry ulepszają DependencyTelemetry

  • Azure queuedla usługi Azure Storage Queues
  • Azure Event Hubs dla Azure Event Hubs
  • Azure Service Busdla usługi Azure Service Bus

Przetwarzanie wsadowe

W przypadku niektórych kolejek można za pomocą jednego żądania zdjąć z kolejki wiele komunikatów. Przetwarzanie takich komunikatów jest prawdopodobnie niezależne i należy do różnych operacji logicznych. Nie można skorelować operacji Dequeue z przetwarzanym konkretnym komunikatem.

Każdy komunikat powinien być przetwarzany we własnym asynchronicznym przepływie sterowania. Aby uzyskać więcej informacji, zobacz sekcję Śledzenie zależności wychodzących.

Długotrwałe zadania w tle

Niektóre aplikacje uruchamiają długotrwałe operacje, które mogą być spowodowane żądaniami użytkowników. Z perspektywy śledzenia/instrumentacji nie różni się ona od instrumentacji żądań lub zależności:

async Task BackgroundTask()
{
    var operation = telemetryClient.StartOperation<DependencyTelemetry>(taskName);
    operation.Telemetry.Type = "Background";
    try
    {
        int progress = 0;
        while (progress < 100)
        {
            // Process the task.
            telemetryClient.TrackTrace($"done {progress++}%");
        }
        // Update status code and success as appropriate.
    }
    catch (Exception e)
    {
        telemetryClient.TrackException(e);
        // Update status code and success as appropriate.
        throw;
    }
    finally
    {
        telemetryClient.StopOperation(operation);
    }
}

W tym przykładzie telemetryClient.StartOperation program tworzy i wypełnia kontekst DependencyTelemetry korelacji. Załóżmy, że masz operację nadrzędną, która została utworzona przez żądania przychodzące, które zaplanowały operację. Tak długo, jak rozpoczyna się w tym samym asynchronicznym przepływie sterowania co żądanie przychodzące, jest ono BackgroundTask skorelowane z operacją nadrzędną. BackgroundTask i wszystkie zagnieżdżone elementy telemetrii są automatycznie skorelowane z żądaniem, które je spowodowało, nawet po zakończeniu żądania.

Gdy zadanie rozpoczyna się od wątku w tle, z którym nie jest skojarzona jakakolwiek operacja ( ), nie ActivityBackgroundTask ma żadnego elementu nadrzędnego. Może jednak mieć zagnieżdżone operacje. Wszystkie elementy telemetrii zgłoszone z zadania są skorelowane z elementem DependencyTelemetry utworzonym w . BackgroundTask

Śledzenie zależności wychodzących

Możesz śledzić własny rodzaj zależności lub operację, która nie jest obsługiwana przez usługę Application Szczegółowe informacje.

Metoda w kolejce Service Bus lub kolejki Storage może służyć jako Enqueue przykłady takiego śledzenia niestandardowego.

Ogólne podejście do śledzenia zależności niestandardowych jest takie, jak:

  • Wywołaj metodę (rozszerzenie), która wypełnia właściwości wymagane do korelacji i niektóre inne właściwości (sygnatura czasowa TelemetryClient.StartOperationDependencyTelemetry rozpoczęcia, czas trwania).
  • Ustaw inne właściwości niestandardowe w DependencyTelemetry pliku , takie jak nazwa i dowolny inny potrzebny kontekst.
  • Wywołaj zależność i zaczekaj na nie.
  • Po zakończeniu operacji StopOperation zatrzymaj ją za pomocą .
  • Obsługa wyjątków.
public async Task RunMyTaskAsync()
{
    using (var operation = telemetryClient.StartOperation<DependencyTelemetry>("task 1"))
    {
        try 
        {
            var myTask = await StartMyTaskAsync();
            // Update status code and success as appropriate.
        }
        catch(...) 
        {
            // Update status code and success as appropriate.
        }
    }
}

Rozdysponowanie operacji powoduje, że operacja jest zatrzymywana, więc można to zrobić zamiast wywoływania . StopOperation

Ostrzeżenie:w niektórych przypadkach nieobsługiwany wyjątek może uniemożliwiać wywoływanie, więc operacje mogą nie być śledzone.

Równoległe przetwarzanie i śledzenie operacji

StopOperation zatrzymuje tylko uruchomiono operację. Jeśli bieżąca uruchomiona operacja nie pasuje do tej, którą chcesz zatrzymać, StopOperation nic nie robi. Taka sytuacja może wystąpić, jeśli równolegle uruchamiasz wiele operacji w tym samym kontekście wykonywania:

var firstOperation = telemetryClient.StartOperation<DependencyTelemetry>("task 1");
var firstTask = RunMyTaskAsync();

var secondOperation = telemetryClient.StartOperation<DependencyTelemetry>("task 2");
var secondTask = RunMyTaskAsync();

await firstTask;

// FAILURE!!! This will do nothing and will not report telemetry for the first operation
// as currently secondOperation is active.
telemetryClient.StopOperation(firstOperation); 

await secondTask;

Pamiętaj, aby zawsze wywołać StartOperation i przetworzyć operację w tej samej metodzie StartOperation aby odizolować operacje uruchomione równolegle. Jeśli operacja jest synchroniczna (lub nie asynchroniczna), opakuj proces i śledź za pomocą Task.Run polecenia :

public void RunMyTask(string name)
{
    using (var operation = telemetryClient.StartOperation<DependencyTelemetry>(name))
    {
        Process();
        // Update status code and success as appropriate.
    }
}

public async Task RunAllTasks()
{
    var task1 = Task.Run(() => RunMyTask("task 1"));
    var task2 = Task.Run(() => RunMyTask("task 2"));
    
    await Task.WhenAll(task1, task2);
}

Operacje usługi ApplicationInsights a System.Diagnostics.Activity

System.Diagnostics.Activity reprezentuje kontekst śledzenia rozproszonego i jest używany przez struktury i biblioteki do tworzenia i propagowania kontekstu wewnątrz procesu i poza nim oraz korelowania elementów telemetrii. Działanie współpracuje z programem — mechanizm powiadomień między platformą/biblioteką w celu powiadamiania o interesujących zdarzeniach (żądaniach przychodzących lub System.Diagnostics.DiagnosticSource wychodzących, wyjątkach itp.).

Działania są pierwszoklasową obywatelami w programie Application Szczegółowe informacje zależność automatyczna i zbieranie żądań w dużym stopniu zależy od nich wraz ze DiagnosticSource zdarzeniami. Utworzenie działania w aplikacji nie spowoduje utworzenia danych telemetrycznych Szczegółowe informacje Aplikacji. Usługa Application Szczegółowe informacje musi odbierać zdarzenia DiagnosticSource oraz znać nazwy i ładunki zdarzeń, aby przetłumaczyć działanie na telemetrię.

Każda aplikacja Szczegółowe informacje (żądanie lub zależność) obejmuje — po wywołaniu tworzy ActivityStartOperation działanie poniżej. StartOperation jest zalecanym sposobem ręcznego śledzenia telemetrii żądań lub zależności i upewnienia się, że wszystko jest skorelowane.

Następne kroki