Gedistribueerde tracering en correlatie via Service Bus berichten

Autotracering van .NET-Client Service Bus

De ServiceBusProcessor klasse van de Azure Messa ging-service bus client voor .net biedt tracerings instrumentatie punten die kunnen worden aangesloten door traceer systemen of client code. Met de instrumentatie kunt u alle aanroepen van de Service Bus Messa ging-service van aan de client zijde bijhouden. Als de bericht verwerking wordt uitgevoerd met behulp ProcessMessageAsync van ServiceBusProcessor (het bericht afhandelingsprocedure-patroon), wordt de bericht verwerking ook instrumentatie gebruikt.

Bijhouden met Azure-toepassing Insights

Micro soft Application Insights biedt uitgebreide mogelijkheden voor het controleren van prestaties, waaronder Automagic-aanvraag en het bijhouden van afhankelijkheden.

Installeer Application Insights SDK, afhankelijk van het project type:

• ASP.net -versie 2,5-Beta2 of hoger installeren
• ASP.net core -install versie 2.2.0-beta2 of hoger. Deze koppelingen bieden Details over het installeren van SDK, het maken van resources en het configureren van SDK (indien nodig). Raadpleeg het artikel Azure-toepassing Insights voor console toepassingen voor non-ASP.NET-toepassingen.

Als u gebruikmaakt ProcessMessageAsync van ServiceBusProcessor (bericht-handler-patroon) om berichten te verwerken, wordt de bericht verwerking ook instrumentatie gebruikt. Alle Service Bus-aanroepen die door uw service worden uitgevoerd, worden automatisch getraceerd en gecorreleerd met andere telemetrie-items. Raadpleeg anders het volgende voor beeld voor het bijhouden van hand matige bericht verwerking.

Verwerking van tracerings berichten

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");
        }
    }
}

In dit voor beeld wordt de aanvraag telemetrie voor elk verwerkte bericht gerapporteerd, met een tijds tempel, duur en resultaat (geslaagd). De telemetrie heeft ook een set correlatie-eigenschappen. Geneste traceringen en uitzonde ringen die worden gerapporteerd tijdens de bericht verwerking, worden ook gestempeld met correlatie-eigenschappen die ze vertegenwoordigen als ' kinderen ' van de RequestTelemetry .

Als u tijdens de verwerking van berichten aanroepen naar ondersteunde externe onderdelen maakt, worden deze ook automatisch gevolgd en gecorreleerd. Raadpleeg aangepaste bewerkingen bijhouden met Application Insights .NET SDK voor hand matig bijhouden en correlatie.

Als u naast de Application Insights SDK een externe code uitvoert, moet u de langere duur bekijken bij het weer geven van Application Insights-Logboeken.

Dit betekent niet dat er een vertraging is opgetreden bij het ontvangen van het bericht. In dit scenario is het bericht al ontvangen omdat het bericht is door gegeven als een para meter voor de SDK-code. En de label name in de app Insights-Logboeken (proces) geeft aan dat het bericht nu wordt verwerkt door de code voor externe gebeurtenis verwerking. Dit probleem is niet gerelateerd aan Azure. In plaats daarvan verwijzen deze metrische gegevens naar de efficiëntie van uw externe code, omdat het bericht al is ontvangen van Service Bus.

Bijhouden zonder tracering systeem

Als uw tracerings systeem geen automatische Service Bus traceringen ondersteunt, is het mogelijk om dergelijke ondersteuning toe te voegen aan een tracerings systeem of in uw toepassing. In deze sectie worden de diagnostische gebeurtenissen beschreven die worden verzonden door Service Bus .NET-client.

Service Bus .NET-client is instrumentatie met behulp van .NET-tracering primitieven System. Diagnostics. activity en System. Diagnostics. DiagnosticSource.

Activity fungeert als tracerings context, maar DiagnosticSource is een meldings mechanisme.

Als er geen listener is voor de DiagnosticSource-gebeurtenissen, is instrumentatie uitgeschakeld, waardoor de kosten voor de instrumentatie gelijk blijven. DiagnosticSource biedt alle controle over de listener:

• Listener bepaalt naar welke bronnen en gebeurtenissen moet worden geluisterd
• de controle van de gebeurtenis frequentie en de steek proef van de listener
• gebeurtenissen worden verzonden met een nettolading die volledige context biedt zodat u tijdens de gebeurtenis toegang krijgt tot het bericht object en deze kunt wijzigen

Raadpleeg de Gebruikers handleiding voor DiagnosticSource voordat u doorgaat met de implementatie.

We gaan een listener maken voor Service Bus gebeurtenissen in ASP.NET Core app die logboeken schrijft met micro soft. extension. logger. Er wordt gebruikgemaakt van System. Reactive. core -bibliotheek om u te abonneren op DiagnosticSource (u kunt zich ook eenvoudig abonneren op DiagnosticSource zonder 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();
    });
}

In dit voor beeld worden de duur, het resultaat, de unieke id en de start tijd van de listener voor elke Service Bus bewerking geregistreerd.

Gebeurtenissen

Alle gebeurtenissen hebben de volgende eigenschappen die voldoen aan de specificatie van de open telemetrie: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md .

• message_bus.destination -wachtrij/onderwerp/pad naar abonnement
• peer.address – volledig gekwalificeerde naam ruimte
• kind – producent, consument of client. De producent wordt gebruikt bij het verzenden van berichten, de consument wanneer deze wordt ontvangen en de client bij het vereffenen.
• component – servicebus

Alle gebeurtenissen hebben ook de eigenschappen entity en endpoint, die in de onderstaande tabel worden wegge laten

• string Entity --De naam van de entiteit (wachtrij, onderwerp, enzovoort.)
• Uri Endpoint -Service Bus eind punt-URL

Instrumentele bewerkingen

Dit is de volledige lijst met bewerkingen met een instrument:

Filters en steek proeven

In sommige gevallen is het wenselijk om slechts een deel van de gebeurtenissen te registreren om de prestaties van de overhead of het opslag verbruik te verminderen. U kunt stop gebeurtenissen alleen registreren (zoals in het voor gaande voor beeld) of het voorbeeld percentage van de gebeurtenissen. DiagnosticSource bieden een manier om deze te krijgen met een IsEnabled predikaat. Zie context-based filtering in DiagnosticSourcevoor meer informatie.

IsEnabled kan meerdere keren worden aangeroepen voor één bewerking om de prestaties te verminderen.

IsEnabled wordt in de volgende volg orde aangeroepen:

1. IsEnabled(<OperationName>, string entity, null) bijvoorbeeld IsEnabled("ServiceBusSender.Send", "MyQueue1") . Houd er rekening mee dat er aan het einde geen ' Start ' of ' Stop ' is. Gebruik het om bepaalde bewerkingen of wacht rijen te filteren. Als de call back-methode retourneert false , worden de gebeurtenissen voor de bewerking niet verzonden.

   • Voor de bewerkingen ' process ' en ' ProcessSession ' ontvangt u ook IsEnabled(<OperationName>, string entity, Activity activity) terugbellen. Gebruik deze functie om gebeurtenissen te filteren op basis van activity.Id of label eigenschappen.

2. IsEnabled(<OperationName>.Start) bijvoorbeeld IsEnabled("ServiceBusSender.Send.Start") . Hiermee wordt gecontroleerd of de gebeurtenis start moet worden gestart. Het resultaat is alleen van invloed op de gebeurtenis start, maar verdere instrumentatie is niet afhankelijk van het item.

Er is geen IsEnabled gebeurtenis voor ' Stop '.

Als een bepaalde bewerkings resultaat uitzonde ring is, IsEnabled("ServiceBusSender.Send.Exception") wordt aangeroepen. U kunt zich alleen abonneren op uitzonderings gebeurtenissen en de rest van de instrumentatie verhinderen. In dit geval moet u dergelijke uitzonde ringen nog steeds afhandelen. Omdat andere instrumentatie is uitgeschakeld, mag u niet verwachten dat de tracerings context met de berichten van de gebruiker naar de producent loopt.

U kunt IsEnabled ook sampling strategieën implementeren. Steek proeven op basis van de Activity.Id of zorgen voor een Activity.RootId consistente steek proef op alle banden (zolang deze door tracering systeem of door uw eigen code worden door gegeven).

Als er meerdere DiagnosticSource listeners voor dezelfde bron aanwezig zijn, is het voldoende voor slechts één listener om de gebeurtenis te accepteren. Daarom is er geen garantie die IsEnabled wordt aangeroepen.

Autotracering van .NET-Client Service Bus

Met ingang van versie 3.0.0 Microsoft Azure ServiceBus-client voor .net kunt u tracerings instrumentatie punten aanwijzen die kunnen worden aangesloten door traceer systemen of client code. Met de instrumentatie kunt u alle aanroepen van de Service Bus Messa ging-service van aan de client zijde bijhouden. Als bericht verwerking wordt uitgevoerd met het patroon van de bericht afhandelingsprocedure, wordt de bericht verwerking ook instrumentatie

Bijhouden met Azure-toepassing Insights

Micro soft Application Insights biedt uitgebreide mogelijkheden voor het controleren van prestaties, waaronder Automagic-aanvraag en het bijhouden van afhankelijkheden.

Installeer Application Insights SDK, afhankelijk van het project type:

• ASP.net -versie 2,5-Beta2 of hoger installeren
• ASP.net core -install versie 2.2.0-beta2 of hoger. Deze koppelingen bieden Details over het installeren van SDK, het maken van resources en het configureren van SDK (indien nodig). Raadpleeg het artikel Azure-toepassing Insights voor console toepassingen voor non-ASP.NET-toepassingen.

Als u het patroon voor bericht afhandeling gebruikt om berichten te verwerken, bent u klaar: alle Service Bus-aanroepen die door uw service worden uitgevoerd, worden automatisch bijgehouden en gecorreleerd met andere telemetrie-items. Raadpleeg anders het volgende voor beeld voor het bijhouden van hand matige bericht verwerking.

Verwerking van tracerings berichten

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");
   }
}

In dit voor beeld RequestTelemetry wordt voor elk verwerkte bericht gerapporteerd, met een tijds tempel, duur en resultaat (geslaagd). De telemetrie heeft ook een set correlatie-eigenschappen. Geneste traceringen en uitzonde ringen die worden gerapporteerd tijdens de bericht verwerking, worden ook gestempeld met correlatie-eigenschappen die ze vertegenwoordigen als ' kinderen ' van de RequestTelemetry .

Als u tijdens de verwerking van berichten aanroepen naar ondersteunde externe onderdelen maakt, worden deze ook automatisch gevolgd en gecorreleerd. Raadpleeg aangepaste bewerkingen bijhouden met Application Insights .NET SDK voor hand matig bijhouden en correlatie.

Als u naast de Application Insights SDK een externe code uitvoert, moet u de langere duur bekijken bij het weer geven van Application Insights-Logboeken.

Dit betekent niet dat er een vertraging is opgetreden bij het ontvangen van het bericht. In dit scenario is het bericht al ontvangen omdat het bericht is door gegeven als een para meter voor de SDK-code. En de label name in de app Insights-Logboeken (proces) geeft aan dat het bericht nu wordt verwerkt door de code voor externe gebeurtenis verwerking. Dit probleem is niet gerelateerd aan Azure. In plaats daarvan verwijzen deze metrische gegevens naar de efficiëntie van uw externe code, omdat het bericht al is ontvangen van Service Bus. Zie dit bestand op github om te zien waar de proces label wordt gegenereerd en toegewezen zodra het bericht is ontvangen van service bus.

Bijhouden zonder tracering systeem

Als uw tracerings systeem geen automatische Service Bus traceringen ondersteunt, is het mogelijk om dergelijke ondersteuning toe te voegen aan een tracerings systeem of in uw toepassing. In deze sectie worden de diagnostische gebeurtenissen beschreven die worden verzonden door Service Bus .NET-client.

Service Bus .NET-client is instrumentatie met behulp van .NET-tracering primitieven System. Diagnostics. activity en System. Diagnostics. DiagnosticSource.

Activity fungeert als tracerings context, maar DiagnosticSource is een meldings mechanisme.

Als er geen listener is voor de DiagnosticSource-gebeurtenissen, is instrumentatie uitgeschakeld, waardoor de kosten voor de instrumentatie gelijk blijven. DiagnosticSource biedt alle controle over de listener:

• Listener bepaalt naar welke bronnen en gebeurtenissen moet worden geluisterd
• de controle van de gebeurtenis frequentie en de steek proef van de listener
• gebeurtenissen worden verzonden met een nettolading die volledige context biedt zodat u tijdens de gebeurtenis toegang krijgt tot het bericht object en deze kunt wijzigen

Raadpleeg de Gebruikers handleiding voor DiagnosticSource voordat u doorgaat met de implementatie.

We gaan een listener maken voor Service Bus gebeurtenissen in ASP.NET Core app die logboeken schrijft met micro soft. extension. logger. Er wordt gebruikgemaakt van System. Reactive. core -bibliotheek om u te abonneren op DiagnosticSource (u kunt zich ook eenvoudig abonneren op DiagnosticSource zonder 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();
    });
}

In dit voor beeld worden de duur, het resultaat, de unieke id en de start tijd van de listener voor elke Service Bus bewerking geregistreerd.

Gebeurtenissen

Voor elke bewerking worden twee gebeurtenissen verzonden: Start en stop. Waarschijnlijk bent u alleen geïnteresseerd in ' Stop '-gebeurtenissen. Ze bieden het resultaat van de bewerking en de start tijd en duur als eigenschappen van de activiteit.

De nettolading van de gebeurtenis biedt een listener met de context van de bewerking, repliceert de API-binnenkomende para meters en retour waarden. De nettolading van de gebeurtenis stop heeft alle eigenschappen van de nettolading van de gebeurtenis, dus u kunt de gebeurtenis start volledig negeren.

Alle gebeurtenissen hebben ook de eigenschappen entity en endpoint, die in de onderstaande tabel worden wegge laten

• string Entity --De naam van de entiteit (wachtrij, onderwerp, enzovoort)
• Uri Endpoint -Service Bus eind punt-URL

Voor elke gebeurtenis ' Stop ' is een Status eigenschap met TaskStatus asynchrone bewerking voltooid, die ook in de volgende tabel wordt wegge laten voor eenvoud.

Dit is de volledige lijst met bewerkingen met een instrument:

In elke gebeurtenis kunt u toegang krijgen tot Activity.Current de huidige bewerkings context.

Logboek registratie meer eigenschappen

Activity.Current geeft gedetailleerde context van de huidige bewerking en de bovenliggende bewerkingen. Zie activiteiten documentatievoor meer informatie. Service Bus instrumentatie biedt meer informatie in het Activity.Current.Tags -blok MessageId en SessionId wanneer deze beschikbaar zijn.

Activiteiten die de gebeurtenis ' Receive ', ' Peek ' en ' ReceiveDeferred ' volgen, kunnen ook RelatedTo tag hebben. Het bevat een afzonderlijke lijst met Diagnostic-Id berichten die als resultaat zijn ontvangen. Deze bewerking kan ertoe leiden dat er verschillende niet-gerelateerde berichten worden ontvangen. Het is ook Diagnostic-Id niet bekend wanneer de bewerking wordt gestart. Daarom kunnen receive-bewerkingen alleen worden gecorreleerd aan proces bewerkingen met deze tag. Het is handig bij het analyseren van prestatie problemen om te controleren hoe lang het heeft geduurd om het bericht te ontvangen.

Een efficiënte manier om tags te registreren, is om ze te herhalen. het toevoegen van labels aan het voor gaande voor beeld ziet eruit als

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}");

Filters en steek proeven

In sommige gevallen is het wenselijk om slechts een deel van de gebeurtenissen te registreren om de prestaties van de overhead of het opslag verbruik te verminderen. U kunt stop gebeurtenissen alleen registreren (zoals in het voor gaande voor beeld) of het voorbeeld percentage van de gebeurtenissen. DiagnosticSource bieden een manier om deze te krijgen met een IsEnabled predikaat. Zie context-based filtering in DiagnosticSourcevoor meer informatie.

IsEnabled kan meerdere keren worden aangeroepen voor één bewerking om de prestaties te verminderen.

IsEnabled wordt in de volgende volg orde aangeroepen:

1. IsEnabled(<OperationName>, string entity, null) bijvoorbeeld IsEnabled("Microsoft.Azure.ServiceBus.Send", "MyQueue1") . Houd er rekening mee dat er aan het einde geen ' Start ' of ' Stop ' is. Gebruik het om bepaalde bewerkingen of wacht rijen te filteren. Als de call back-methode retourneert false , worden gebeurtenissen voor de bewerking niet verzonden

   • Voor de bewerkingen ' process ' en ' ProcessSession ' ontvangt u ook IsEnabled(<OperationName>, string entity, Activity activity) terugbellen. Gebruik deze functie om gebeurtenissen te filteren op basis van activity.Id of label eigenschappen.

2. IsEnabled(<OperationName>.Start) bijvoorbeeld IsEnabled("Microsoft.Azure.ServiceBus.Send.Start") . Hiermee wordt gecontroleerd of de gebeurtenis start moet worden gestart. Het resultaat is alleen van invloed op de gebeurtenis start, maar verdere instrumentatie is niet afhankelijk van het item.

Er is geen IsEnabled gebeurtenis voor ' Stop '.

Als een bepaalde bewerkings resultaat uitzonde ring is, IsEnabled("Microsoft.Azure.ServiceBus.Exception") wordt aangeroepen. U kunt zich alleen abonneren op uitzonderings gebeurtenissen en de rest van de instrumentatie verhinderen. In dit geval moet u dergelijke uitzonde ringen nog steeds afhandelen. Omdat andere instrumentatie is uitgeschakeld, mag u niet verwachten dat de tracerings context met de berichten van de gebruiker naar de producent loopt.

U kunt IsEnabled ook sampling strategieën implementeren. Steek proeven op basis van de Activity.Id of zorgen voor een Activity.RootId consistente steek proef op alle banden (zolang deze door tracering systeem of door uw eigen code worden door gegeven).

Als er meerdere DiagnosticSource listeners voor dezelfde bron aanwezig zijn, is het voldoende voor slechts één listener om de gebeurtenis te accepteren. Daarom is er geen garantie die IsEnabled wordt aangeroepen.