Distribuerad spårning och korrelation genom Service Bus meddelanden

Service Bus .NET-klient spårning

ServiceBusProcessorKlassen för Azure Messaging Service Bus-klienten för .net innehåller spårnings instrument som kan kopplas till spårnings system eller del av klient kod. Med instrumentering kan du spåra alla anrop till tjänsten för Service Bus meddelande tjänsten från klient sidan. Om meddelande bearbetningen görs med hjälp ProcessMessageAsync av ServiceBusProcessor (meddelande hanterarens mönster) instrumenteras även meddelande bearbetningen.

Spåra med Azure Application insikter

Microsoft Application Insights ger omfattande prestanda övervaknings funktioner, inklusive automagic-begäran och beroende spårning.

Installera Application Insights SDK, beroende på din projekt typ:

• ASP.net -installation version 2,5-beta2 eller högre
• ASP.net Core -installera version 2.2.0-beta2 eller högre. Dessa länkar innehåller information om hur du installerar SDK, skapar resurser och konfigurerar SDK (om det behövs). Information om non-ASP.NET-program finns i artikeln Azure Application Insights för konsol program .

Om du använder ProcessMessageAsync ServiceBusProcessor (mönster för meddelande hanterare) för att bearbeta meddelanden, instrumenteras även meddelande bearbetningen. Alla Service Bus-anrop som utförs av tjänsten spåras automatiskt och korreleras med andra telemetri objekt. I annat fall refererar vi till följande exempel för manuell meddelande bearbetnings spårning.

Behandling av spåra meddelanden

async Task ProcessAsync(ProcessMessageEventArgs args)
{
    ServiceBusReceivedMessage message = args.Message;
    if (message.ApplicationProperties.TryGetValue("Diagnostic-Id", out var objectId) && objectId is string diagnosticId)
    {
        var activity = new Activity("ServiceBusProcessor.ProcessMessage");
        activity.SetParentId(diagnosticId);
        // If you're using Microsoft.ApplicationInsights package version 2.6-beta or higher, you should call StartOperation<RequestTelemetry>(activity) instead
        using (var operation = telemetryClient.StartOperation<RequestTelemetry>("Process", activity.RootId, activity.ParentId))
        {
            telemetryClient.TrackTrace("Received message");
            try 
            {
            // process message
            }
            catch (Exception ex)
            {
                telemetryClient.TrackException(ex);
                operation.Telemetry.Success = false;
                throw;
            }

            telemetryClient.TrackTrace("Done");
        }
    }
}

I det här exemplet rapporteras begäran om telemetri för varje bearbetat meddelande, med en tidsstämpel, varaktighet och resultat (lyckades). Telemetri har också en uppsättning korrelations egenskaper. Kapslade spår och undantag som rapporteras vid meddelande bearbetning stämplas också med korrelations egenskaper som representerar dem som underordnade till RequestTelemetry .

Om du gör anrop till stödda externa komponenter under meddelande bearbetningen spåras de också automatiskt och korreleras. Se spåra anpassade åtgärder med Application Insights .NET SDK för manuell spårning och korrelation.

Om du kör någon extern kod utöver Application Insights SDK, förväntar du dig att se längre tid när du visar Application Insights loggar.

Det innebär inte att det tog lång tid att ta emot meddelandet. I det här scenariot har meddelandet redan mottagits sedan meddelandet skickades som en parameter till SDK-koden. Och namn -taggen i App Insights-loggarna (processen) anger att meddelandet nu bearbetas av den externa händelse bearbetnings koden. Det här problemet är inte Azure-relaterat. De här måtten avser i stället effektiviteten hos din externa kod, under förutsättning att meddelandet redan har tagits emot från Service Bus.

Spåra utan spårnings system

Om spårnings systemet inte stöder automatisk Service Bus samtals spårning kan du behöva lägga till sådant stöd i ett spårnings system eller i ditt program. I det här avsnittet beskrivs diagnostiska händelser som skickas av Service Bus .NET-klienten.

Service Bus .NET-klienten instrumenteras med hjälp av .NET tracing primitiver system. Diagnostics. Activity och system. Diagnostics. DiagnosticSource.

Activity fungerar som en spårnings kontext medan DiagnosticSource är en meddelande funktion.

Om det inte finns någon lyssnare för DiagnosticSource-händelserna, är instrumentering inaktiverat, och behåller inga instrument kostnader. DiagnosticSource ger all kontroll till lyssnaren:

• lyssnare styr vilka källor och händelser som ska bevakas
• lyssnare kontrollerar händelse frekvens och sampling
• händelser skickas med en nytto last som ger fullständig kontext så att du kan komma åt och ändra meddelande objekt under händelsen

Bekanta dig med användar handboken för DiagnosticSource innan du fortsätter med implementeringen.

Nu ska vi skapa en lyssnare för Service Bus händelser i ASP.NET Core app som skriver loggar med Microsoft. extension. Logga. Den använder system. Reactive. Core -biblioteket för att prenumerera på DiagnosticSource (det är också enkelt att prenumerera på DiagnosticSource utan IT)

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory factory, IApplicationLifetime applicationLifetime)
{
    // configuration...

    var serviceBusLogger = factory.CreateLogger("Azure.Messaging.ServiceBus");

    IDisposable innerSubscription = null;
    IDisposable outerSubscription = DiagnosticListener.AllListeners.Subscribe(delegate (DiagnosticListener listener)
    {
        // subscribe to the Service Bus DiagnosticSource
        if (listener.Name == "Azure.Messaging.ServiceBus")
        {
            // receive event from Service Bus DiagnosticSource
            innerSubscription = listener.Subscribe(delegate (KeyValuePair<string, object> evnt)
            {
                // Log operation details once it's done
                if (evnt.Key.EndsWith("Stop"))
                {
                    Activity currentActivity = Activity.Current;
                    serviceBusLogger.LogInformation($"Operation {currentActivity.OperationName} is finished, Duration={currentActivity.Duration}, Id={currentActivity.Id}, StartTime={currentActivity.StartTimeUtc}");
                }
            });
        }
    });

    applicationLifetime.ApplicationStopping.Register(() =>
    {
        outerSubscription?.Dispose();
        innerSubscription?.Dispose();
    });
}

I det här exemplet loggar Listener varaktighet, resultat, unik identifierare och start tid för varje Service Bus åtgärd.

Händelser

Alla händelser har följande egenskaper som stämmer med den öppna telemetri-specifikationen: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md .

• message_bus.destination – kö/ämne/prenumerations Sök väg
• peer.address – fullständigt kvalificerat namn område
• kind – antingen producent, konsument eller klient. Producer används vid sändning av meddelanden, konsument vid mottagning och klient vid kvittning.
• component – servicebus

Alla händelser har även egenskaperna "entity" och "slut punkt", de utelämnas i tabellen nedan

• string Entity --Namn på entiteten (kö, ämne osv.)
• Uri Endpoint -Service Bus slut punkts-URL

Instrumenterade åtgärder

Här är en fullständig lista över instrumenterade åtgärder:

Filtrering och sampling

I vissa fall är det önskvärt att endast logga en del av händelserna för att minska prestanda och lagrings förbrukning. Du kan endast logga "stoppa"-händelser (som i föregående exempel) eller en procentuell sampling av händelserna. DiagnosticSource Ange ett sätt att åstadkomma det med IsEnabled predikatet. Mer information finns i Sammanhangs beroende filtrering i DiagnosticSource.

IsEnabled kan anropas flera gånger för en enskild åtgärd för att minimera prestanda påverkan.

IsEnabled anropas i följande ordning:

1. IsEnabled(<OperationName>, string entity, null) till exempel IsEnabled("ServiceBusSender.Send", "MyQueue1") . Observera att det inte finns någon start eller stopp i slutet. Använd den för att filtrera bort specifika åtgärder eller köer. Om callback-metoden returnerar false skickas inte händelser för åtgärden.

   • För åtgärderna "process" och "ProcessSession" får du också IsEnabled(<OperationName>, string entity, Activity activity) motringning. Använd den för att filtrera händelser baserat på activity.Id eller Taggar egenskaper.

2. IsEnabled(<OperationName>.Start) till exempel IsEnabled("ServiceBusSender.Send.Start") . Kontrollerar om start händelsen ska utlösas. Resultatet påverkar endast händelsen "starta", men ytterligare Instrumentation är inte beroende av det.

Det finns ingen IsEnabled "stopp"-händelse.

Om åtgärds resultatet är ett undantag IsEnabled("ServiceBusSender.Send.Exception") kallas det. Du kan bara prenumerera på "undantags händelser" och förhindra resten av Instrumentation. I så fall måste du fortfarande hantera sådana undantag. Eftersom annan Instrumentation är inaktive rad bör du inte förvänta spårnings kontexten för att flöda med meddelanden från konsument till producent.

Du kan IsEnabled även implementera provtagnings strategier. Sampling som baseras på Activity.Id eller Activity.RootId säkerställer konsekvent provtagning över alla däck (så länge som det sprids av spårnings systemet eller av din egen kod).

I närvaro av flera DiagnosticSource lyssnare för samma källa räcker det bara för en lyssnare att acceptera händelsen, så det finns ingen garanti som IsEnabled kallas.

Service Bus .NET-klient spårning

Från och med version 3.0.0 Microsoft Azure Service Bus-klienten för .net får du spårnings instrument som kan kopplas till spårnings system, eller del av klient kod. Med instrumentering kan du spåra alla anrop till tjänsten för Service Bus meddelande tjänsten från klient sidan. Om meddelande bearbetning görs med meddelande hanterarens mönster, instrumenteras även meddelande bearbetning

Spåra med Azure Application insikter

Microsoft Application Insights ger omfattande prestanda övervaknings funktioner, inklusive automagic-begäran och beroende spårning.

Installera Application Insights SDK, beroende på din projekt typ:

• ASP.net -installation version 2,5-beta2 eller högre
• ASP.net Core -installera version 2.2.0-beta2 eller högre. Dessa länkar innehåller information om hur du installerar SDK, skapar resurser och konfigurerar SDK (om det behövs). Information om non-ASP.NET-program finns i artikeln Azure Application Insights för konsol program .

Om du använder meddelande hanteraren för att bearbeta meddelanden är du klar: alla Service Bus samtal som utförs av tjänsten spåras automatiskt och korreleras med andra telemetridata. I annat fall refererar vi till följande exempel för manuell meddelande bearbetnings spårning.

Behandling av spåra meddelanden

private readonly TelemetryClient telemetryClient;

async Task ProcessAsync(Message message)
{
    var activity = message.ExtractActivity();
    
    // If you're using Microsoft.ApplicationInsights package version 2.6-beta or higher, you should call StartOperation<RequestTelemetry>(activity) instead
    using (var operation = telemetryClient.StartOperation<RequestTelemetry>("Process", activity.RootId, activity.ParentId))
    {
        telemetryClient.TrackTrace("Received message");
        try 
        {
           // process message
        }
        catch (Exception ex)
        {
             telemetryClient.TrackException(ex);
             operation.Telemetry.Success = false;
             throw;
        }

        telemetryClient.TrackTrace("Done");
   }
}

I det här exemplet RequestTelemetry rapporteras för varje bearbetat meddelande, med en tidsstämpel, varaktighet och resultat (lyckades). Telemetri har också en uppsättning korrelations egenskaper. Kapslade spår och undantag som rapporteras vid meddelande bearbetning stämplas också med korrelations egenskaper som representerar dem som underordnade till RequestTelemetry .

Om du gör anrop till stödda externa komponenter under meddelande bearbetningen spåras de också automatiskt och korreleras. Se spåra anpassade åtgärder med Application Insights .NET SDK för manuell spårning och korrelation.

Om du kör någon extern kod utöver Application Insights SDK, förväntar du dig att se längre tid när du visar Application Insights loggar.

Det innebär inte att det tog lång tid att ta emot meddelandet. I det här scenariot har meddelandet redan mottagits sedan meddelandet skickades som en parameter till SDK-koden. Och namn -taggen i App Insights-loggarna (processen) anger att meddelandet nu bearbetas av den externa händelse bearbetnings koden. Det här problemet är inte Azure-relaterat. De här måtten avser i stället effektiviteten hos din externa kod, under förutsättning att meddelandet redan har tagits emot från Service Bus. Se den här filen på GitHub för att se var process tag gen genereras och tilldelas när meddelandet har tagits emot från Service Bus.

Spåra utan spårnings system

Om spårnings systemet inte stöder automatisk Service Bus samtals spårning kan du behöva lägga till sådant stöd i ett spårnings system eller i ditt program. I det här avsnittet beskrivs diagnostiska händelser som skickas av Service Bus .NET-klienten.

Service Bus .NET-klienten instrumenteras med hjälp av .NET tracing primitiver system. Diagnostics. Activity och system. Diagnostics. DiagnosticSource.

Activity fungerar som en spårnings kontext medan DiagnosticSource är en meddelande funktion.

Om det inte finns någon lyssnare för DiagnosticSource-händelserna, är instrumentering inaktiverat, och behåller inga instrument kostnader. DiagnosticSource ger all kontroll till lyssnaren:

• lyssnare styr vilka källor och händelser som ska bevakas
• lyssnare kontrollerar händelse frekvens och sampling
• händelser skickas med en nytto last som ger fullständig kontext så att du kan komma åt och ändra meddelande objekt under händelsen

Bekanta dig med användar handboken för DiagnosticSource innan du fortsätter med implementeringen.

Nu ska vi skapa en lyssnare för Service Bus händelser i ASP.NET Core app som skriver loggar med Microsoft. extension. Logga. Den använder system. Reactive. Core -biblioteket för att prenumerera på DiagnosticSource (det är också enkelt att prenumerera på DiagnosticSource utan IT)

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory factory, IApplicationLifetime applicationLifetime)
{
    // configuration...

    var serviceBusLogger = factory.CreateLogger("Microsoft.Azure.ServiceBus");

    IDisposable innerSubscription = null;
    IDisposable outerSubscription = DiagnosticListener.AllListeners.Subscribe(delegate (DiagnosticListener listener)
    {
        // subscribe to the Service Bus DiagnosticSource
        if (listener.Name == "Microsoft.Azure.ServiceBus")
        {
            // receive event from Service Bus DiagnosticSource
            innerSubscription = listener.Subscribe(delegate (KeyValuePair<string, object> evnt)
            {
                // Log operation details once it's done
                if (evnt.Key.EndsWith("Stop"))
                {
                    Activity currentActivity = Activity.Current;
                    TaskStatus status = (TaskStatus)evnt.Value.GetProperty("Status");
                    serviceBusLogger.LogInformation($"Operation {currentActivity.OperationName} is finished, Duration={currentActivity.Duration}, Status={status}, Id={currentActivity.Id}, StartTime={currentActivity.StartTimeUtc}");
                }
            });
        }
    });

    applicationLifetime.ApplicationStopping.Register(() =>
    {
        outerSubscription?.Dispose();
        innerSubscription?.Dispose();
    });
}

I det här exemplet loggar Listener varaktighet, resultat, unik identifierare och start tid för varje Service Bus åtgärd.

Händelser

För varje åtgärd skickas två händelser: "starta" och "stoppa". Förmodligen är du bara intresse rad av "stopp"-händelser. De ger resultatet av åtgärden och start tid och varaktighet som aktivitets egenskaper.

Händelse nytto Last tillhandahåller en lyssnare med åtgärdens kontext, den replikerar API-inkommande parametrar och retur värde. Händelse nytto lasten "stoppa" har alla egenskaper för "starta" händelse nytto Last, så att du kan ignorera "Start"-händelsen fullständigt.

Alla händelser har även egenskaperna "entity" och "slut punkt", de utelämnas i tabellen nedan

• string Entity --Namn på entiteten (kö, ämne osv.)
• Uri Endpoint -Service Bus slut punkts-URL

Varje "stopp"-händelse har en Status egenskap med en TaskStatus asynkron åtgärd slutfördes med, vilket också utelämnas i följande tabell för enkelhetens skull.

Här är en fullständig lista över instrumenterade åtgärder:

I varje händelse kan du komma åt Activity.Current som innehåller aktuell åtgärds kontext.

Logga fler egenskaper

Activity.Current innehåller en detaljerad kontext för den aktuella åtgärden och dess överordnade. Mer information finns i aktivitets dokumentation. Service Bus Instrumentation innehåller mer information i Activity.Current.Tags – de är kvar MessageId och SessionId när de är tillgängliga.

Aktiviteter som spårar "Receive", "Peek" och "ReceiveDeferred"-händelsen kan också ha RelatedTo tagg. Den innehåller en distinkt lista över Diagnostic-Id meddelanden som tagits emot som ett resultat. Sådan åtgärd kan leda till att flera orelaterade meddelanden tas emot. Det Diagnostic-Id är inte heller känt när åtgärden startar, så att Receive-åtgärder kan korreleras till process åtgärder med endast den här taggen. Det är användbart när du analyserar prestanda problem för att kontrol lera hur lång tid det tog att ta emot meddelandet.

Effektivt sätt att logga taggar är att iterera över dem, så att lägga till taggar i föregående exempel ser ut så här

Activity currentActivity = Activity.Current;
TaskStatus status = (TaskStatus)evnt.Value.GetProperty("Status");

var tagsList = new StringBuilder();
foreach (var tags in currentActivity.Tags)
{
    tagsList.Append($", {tags.Key}={tags.Value}");
}

serviceBusLogger.LogInformation($"{currentActivity.OperationName} is finished, Duration={currentActivity.Duration}, Status={status}, Id={currentActivity.Id}, StartTime={currentActivity.StartTimeUtc}{tagsList}");

Filtrering och sampling

I vissa fall är det önskvärt att endast logga en del av händelserna för att minska prestanda och lagrings förbrukning. Du kan endast logga "stoppa"-händelser (som i föregående exempel) eller en procentuell sampling av händelserna. DiagnosticSource Ange ett sätt att åstadkomma det med IsEnabled predikatet. Mer information finns i Sammanhangs beroende filtrering i DiagnosticSource.

IsEnabled kan anropas flera gånger för en enskild åtgärd för att minimera prestanda påverkan.

IsEnabled anropas i följande ordning:

1. IsEnabled(<OperationName>, string entity, null) till exempel IsEnabled("Microsoft.Azure.ServiceBus.Send", "MyQueue1") . Observera att det inte finns någon start eller stopp i slutet. Använd den för att filtrera bort specifika åtgärder eller köer. Om callback-metoden returnerar false skickas inte händelser för åtgärden

   • För åtgärderna "process" och "ProcessSession" får du också IsEnabled(<OperationName>, string entity, Activity activity) motringning. Använd den för att filtrera händelser baserat på activity.Id eller Taggar egenskaper.

2. IsEnabled(<OperationName>.Start) till exempel IsEnabled("Microsoft.Azure.ServiceBus.Send.Start") . Kontrollerar om start händelsen ska utlösas. Resultatet påverkar endast händelsen "starta", men ytterligare Instrumentation är inte beroende av det.

Det finns ingen IsEnabled "stopp"-händelse.

Om åtgärds resultatet är ett undantag IsEnabled("Microsoft.Azure.ServiceBus.Exception") kallas det. Du kan bara prenumerera på "undantags händelser" och förhindra resten av Instrumentation. I så fall måste du fortfarande hantera sådana undantag. Eftersom annan Instrumentation är inaktive rad bör du inte förvänta spårnings kontexten för att flöda med meddelanden från konsument till producent.

Du kan IsEnabled även implementera provtagnings strategier. Sampling som baseras på Activity.Id eller Activity.RootId säkerställer konsekvent provtagning över alla däck (så länge som det sprids av spårnings systemet eller av din egen kod).

I närvaro av flera DiagnosticSource lyssnare för samma källa räcker det bara för en lyssnare att acceptera händelsen, så det finns ingen garanti som IsEnabled kallas.