Distribuované trasování a korelace prostřednictvím Service Bus zasílání zpráv

Service Bus autotracing klienta .NET

ServiceBusProcessorTřída služby Azure Messaging Service Bus Client for .NET poskytuje trasovací body instrumentace, které mohou být zapojeny do trasovacích systémů nebo z kódu klienta. Instrumentace umožňuje sledování všech volání služby Service Bus Messaging Service ze strany klienta. Pokud je zpracování zpráv provedeno ProcessMessageAsync ServiceBusProcessor pomocí (vzoru obslužné rutiny zpráv), je rovněž instrumentované zpracování zprávy.

Sledování s využitím Azure Application Insights

Microsoft Application Insights poskytuje bohatě výkonné možnosti monitorování, včetně automagic Request a sledování závislostí.

V závislosti na typu projektu nainstalujte Application Insights SDK:

• ASP.NET – instalace verze 2,5-beta2 nebo vyšší
• ASP.NET Core – instalace verze 2.2.0-beta2 nebo vyšší. Tyto odkazy poskytují podrobné informace o instalaci sady SDK, vytváření prostředků a konfiguraci sady SDK (v případě potřeby). Informace o aplikacích non-ASP.NET najdete v článku o konzolových aplikacích Azure Application Insights .

Použijete-li pro zpracování zpráv (vzorek ProcessMessageAsync ServiceBusProcessor obslužné rutiny zpráv), je zpracování zprávy rovněž instrumentované. Všechna Service Bus volání prováděná službou jsou automaticky sledována a koreluje s ostatními položkami telemetrie. Jinak v případě ručního sledování zpracování zpráv použijte následující příklad.

Trasování zpracování zpráv

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

V tomto příkladu je pro každou zpracovávanou zprávu hlášena telemetrie požadavků, která má časové razítko, dobu trvání a výsledek (úspěch). Telemetrie má také sadu vlastností korelace. Vnořená trasování a výjimky hlášené během zpracování zprávy jsou také označeny vlastnostmi korelace, které je představují jako podřízené položky RequestTelemetry .

V případě, že během zpracování zprávy provedete volání podporovaných externích komponent, jsou také automaticky sledovány a korelace. Informace o ručním sledování a korelaci najdete v tématu sledování vlastních operací pomocí Application Insights .NET SDK .

Pokud kromě Application Insights SDK používáte i nějaký externí kód, při zobrazení protokolů Application Insights se očekává, že se zobrazí delší Doba trvání .

Neznamená to, že při přijímání zprávy došlo k prodlevě. V tomto scénáři již byla zpráva přijata, protože zpráva je předána jako parametr kódu sady SDK. A značka Name v protokolech App Insights (Process) označuje, že zpráva se teď zpracovává vaším kódem pro zpracování externích událostí. Tento problém se netýká Azure. Místo toho tyto metriky odkazují na efektivitu vašeho externího kódu, protože zpráva již byla přijata z Service Bus.

Sledování bez trasování systému

V případě, že váš sledovací systém nepodporuje sledování volání automatických Service Bus, může se stát, že budete chtít přidat takovou podporu do trasovacího systému nebo do aplikace. Tato část popisuje diagnostické události odesílané Service Bus klienta .NET.

Service Bus klient .NET instrumentuje pomocí primitivních primitiv rozhraní .NET System. Diagnostics. Activity a System. Diagnostics. DiagnosticSource.

Activity slouží jako kontext trasování, zatímco DiagnosticSource je mechanismus oznámení.

Pokud není k dispozici naslouchací proces pro události DiagnosticSource, instrumentace se vypne a zachová nulové náklady instrumentace. DiagnosticSource poskytuje všem ovládacím prvkům naslouchací proces:

• naslouchací proces řídí, se kterými zdroji a událostmi naslouchá
• frekvence a vzorkování událostí ovládacích prvků naslouchacího procesu
• události se odesílají s datovou částí, která poskytuje úplný kontext, takže můžete přistupovat k objektu zprávy a upravovat ho během události.

Než budete pokračovat v implementaci, Seznamte se s DiagnosticSource User Guide .

Pojďme vytvořit naslouchací proces pro Service Bus události v aplikaci ASP.NET Core, která zapisuje protokoly do Microsoft. extension. protokolovacího nástroje. Pomocí knihovny System. Reactive. Core se přihlásí k odběru DiagnosticSource (můžete se taky snadno přihlásit k odběru DiagnosticSource bez něj).

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

V tomto příkladu jsou protokoly naslouchacího procesu trvání, výsledek, jedinečný identifikátor a čas spuštění pro každou operaci Service Bus.

Události

Všechny události budou mít následující vlastnosti, které jsou v souladu se specifikací Open telemetrie: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md .

• message_bus.destination – fronta/téma/cesta předplatného
• peer.address – plně kvalifikovaný obor názvů
• kind – buď producent, příjemce nebo klient. Výrobce se používá při posílání zpráv, příjemce při přijímání a klientovi při vyrovnávání.
• component – servicebus

Všechny události mají také vlastnosti entita a koncový bod, které jsou v níže uvedené tabulce vynechány.

• string Entity --Název entity (Queue, téma atd.)
• Uri Endpoint – Service Bus adresa URL koncového bodu

Instrumentované operace

Tady je úplný seznam instrumentované operace:

Filtrování a vzorkování

V některých případech je žádoucí protokolovat pouze část událostí, aby se snížila režie výkonu nebo spotřeba úložiště. Mohli byste protokolovat pouze události stop (jako v předchozím příkladu) nebo ukázkové procento událostí. DiagnosticSource Poskytněte způsob, jak ho dosáhnout pomocí IsEnabled predikátu. Další informace najdete v tématu filtrování založené na kontextu v DiagnosticSource.

IsEnabled může být voláno vícekrát, aby jedna operace minimalizovala dopad na výkon.

IsEnabled se volá v následujícím pořadí:

1. IsEnabled(<OperationName>, string entity, null) například IsEnabled("ServiceBusSender.Send", "MyQueue1") . Všimněte si, že na konci není žádné "Start" nebo "Stop". Slouží k filtrování konkrétních operací nebo front. Pokud metoda zpětného volání vrátí hodnotu false , události pro operaci se neodesílají.

   • Pro operace "proces" a "ProcessSession" obdržíte také IsEnabled(<OperationName>, string entity, Activity activity) zpětné volání. Slouží k filtrování událostí na základě activity.Id vlastností značek nebo.

2. IsEnabled(<OperationName>.Start) například IsEnabled("ServiceBusSender.Send.Start") . Kontroluje, zda by měla být aktivována událost Start. Výsledek má vliv pouze na událost Start, ale další instrumentace na ní není závislá.

IsEnabledPro událost zastavení není k dispozici.

Pokud je výsledkem nějaké operace výjimka, IsEnabled("ServiceBusSender.Send.Exception") je volána metoda. Přihlásili jste se k odběru událostí Exception a zabráníte zbytek instrumentace. V takovém případě je stále nutné tyto výjimky zpracovat. Vzhledem k tomu, že je jiná instrumentace zakázaná, neměli byste očekávat, že by kontext trasování byl tok se zprávami od spotřebitelů k producentovi.

Můžete použít IsEnabled také implementaci strategií vzorkování. Vzorkování založené na Activity.Id nebo Activity.RootId zaručuje konzistentní vzorkování napříč všemi pneumatikami (Pokud je šířené systémem trasování nebo vlastním kódem).

V DiagnosticSource případě, že je pro stejný zdroj k dispozici více posluchačů, je pro přijetí události dostačující pouze jeden naslouchací proces, takže není IsEnabled zavolána žádná záruka.

Service Bus autotracing klienta .NET

Počínaje verzí 3.0.0 Microsoft Azure klient ServiceBus pro .NET poskytuje trasovací body instrumentace, které mohou být zapojeny do trasovacích systémů nebo do části kódu klienta. Instrumentace umožňuje sledování všech volání služby Service Bus Messaging Service ze strany klienta. Pokud se zpracování zprávy provádí pomocí vzoru obslužné rutiny zpráv, je také instrumentované zpracování zprávy.

Sledování s využitím Azure Application Insights

Microsoft Application Insights poskytuje bohatě výkonné možnosti monitorování, včetně automagic Request a sledování závislostí.

V závislosti na typu projektu nainstalujte Application Insights SDK:

• ASP.NET – instalace verze 2,5-beta2 nebo vyšší
• ASP.NET Core – instalace verze 2.2.0-beta2 nebo vyšší. Tyto odkazy poskytují podrobné informace o instalaci sady SDK, vytváření prostředků a konfiguraci sady SDK (v případě potřeby). Informace o aplikacích non-ASP.NET najdete v článku o konzolových aplikacích Azure Application Insights .

Pokud ke zpracování zpráv používáte vzor obslužné rutiny zpráv , jste hotovi: všechna Service Bus volání prováděná službou jsou automaticky sledována a koreluje s ostatními položkami telemetrie. Jinak v případě ručního sledování zpracování zpráv použijte následující příklad.

Trasování zpracování zpráv

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

V tomto příkladu RequestTelemetry je hlášena pro každou zpracovávanou zprávu s časovým razítkem, dobou trvání a výsledkem (úspěch). Telemetrie má také sadu vlastností korelace. Vnořená trasování a výjimky hlášené během zpracování zprávy jsou také označeny vlastnostmi korelace, které je představují jako podřízené položky RequestTelemetry .

V případě, že během zpracování zprávy provedete volání podporovaných externích komponent, jsou také automaticky sledovány a korelace. Informace o ručním sledování a korelaci najdete v tématu sledování vlastních operací pomocí Application Insights .NET SDK .

Pokud kromě Application Insights SDK používáte i nějaký externí kód, při zobrazení protokolů Application Insights se očekává, že se zobrazí delší Doba trvání .

Neznamená to, že při přijímání zprávy došlo k prodlevě. V tomto scénáři již byla zpráva přijata, protože zpráva je předána jako parametr kódu sady SDK. A značka Name v protokolech App Insights (Process) označuje, že zpráva se teď zpracovává vaším kódem pro zpracování externích událostí. Tento problém se netýká Azure. Místo toho tyto metriky odkazují na efektivitu vašeho externího kódu, protože zpráva již byla přijata z Service Bus. Podívejte se na tento soubor na GitHubu a zjistěte, kde se po přijetí zprávy z Service Bus značka procesu vygenerovala a přiřadí.

Sledování bez trasování systému

V případě, že váš sledovací systém nepodporuje sledování volání automatických Service Bus, může se stát, že budete chtít přidat takovou podporu do trasovacího systému nebo do aplikace. Tato část popisuje diagnostické události odesílané Service Bus klienta .NET.

Service Bus klient .NET instrumentuje pomocí primitivních primitiv rozhraní .NET System. Diagnostics. Activity a System. Diagnostics. DiagnosticSource.

Activity slouží jako kontext trasování, zatímco DiagnosticSource je mechanismus oznámení.

Pokud není k dispozici naslouchací proces pro události DiagnosticSource, instrumentace se vypne a zachová nulové náklady instrumentace. DiagnosticSource poskytuje všem ovládacím prvkům naslouchací proces:

• naslouchací proces řídí, se kterými zdroji a událostmi naslouchá
• frekvence a vzorkování událostí ovládacích prvků naslouchacího procesu
• události se odesílají s datovou částí, která poskytuje úplný kontext, takže můžete přistupovat k objektu zprávy a upravovat ho během události.

Než budete pokračovat v implementaci, Seznamte se s DiagnosticSource User Guide .

Pojďme vytvořit naslouchací proces pro Service Bus události v aplikaci ASP.NET Core, která zapisuje protokoly do Microsoft. extension. protokolovacího nástroje. Pomocí knihovny System. Reactive. Core se přihlásí k odběru DiagnosticSource (můžete se taky snadno přihlásit k odběru DiagnosticSource bez něj).

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

V tomto příkladu jsou protokoly naslouchacího procesu trvání, výsledek, jedinečný identifikátor a čas spuštění pro každou operaci Service Bus.

Události

Pro každou operaci jsou odesílány dvě události: ' Start ' a ' stop '. Pravděpodobně jste zajímá jenom události stop. Poskytují výsledek operace a čas spuštění a dobu trvání jako vlastnosti aktivity.

Datová část události poskytuje naslouchací proces s kontextem operace, replikuje příchozí parametry rozhraní API a návratovou hodnotu. Datová část události ' stop ' má všechny vlastnosti datové části ' Start ', takže můžete událost ' spustit ' zcela ignorovat.

Všechny události mají také vlastnosti entita a koncový bod, které jsou v níže uvedené tabulce vynechány.

• string Entity --Název entity (Queue, téma atd.)
• Uri Endpoint – Service Bus adresa URL koncového bodu

Každé události ' stop ' má Status vlastnost s TaskStatus asynchronní operací byla dokončena s, která je také vynechána v následující tabulce pro zjednodušení.

Tady je úplný seznam instrumentované operace:

V každé události máte přístup Activity.Current , který obsahuje kontext aktuální operace.

Protokolování dalších vlastností

Activity.Current poskytuje podrobný kontext aktuální operace a jejích nadřazených prvků. Další informace najdete v dokumentaci k aktivitám. Service Bus Instrumentace poskytuje další informace, Activity.Current.Tags které jsou MessageId SessionId k dispozici, a pokaždé, když jsou dostupné.

Aktivity, které sledují událost Receive, prohlížet a ReceiveDeferred, mohou mít také RelatedTo značku. Obsahuje jedinečný seznam Diagnostic-Id (y) zpráv, které byly přijaty v důsledku. Tato operace může vést k přijetí několika nesouvisejících zpráv. Také se Diagnostic-Id při spuštění operace není známo, takže operace Receive by mohly být sladěné s operacemi zpracování pouze pomocí této značky. Je užitečné při analýze problémů s výkonem ke kontrole, jak dlouho trvalo přijímání zprávy.

Účinný způsob, jak přihlašovat značky, je iterovat přes ně, takže Přidání značek k předchozímu příkladu vypadá takto.

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

Filtrování a vzorkování

V některých případech je žádoucí protokolovat pouze část událostí, aby se snížila režie výkonu nebo spotřeba úložiště. Mohli byste protokolovat pouze události stop (jako v předchozím příkladu) nebo ukázkové procento událostí. DiagnosticSource Poskytněte způsob, jak ho dosáhnout pomocí IsEnabled predikátu. Další informace najdete v tématu filtrování založené na kontextu v DiagnosticSource.

IsEnabled může být voláno vícekrát, aby jedna operace minimalizovala dopad na výkon.

IsEnabled se volá v následujícím pořadí:

1. IsEnabled(<OperationName>, string entity, null) například IsEnabled("Microsoft.Azure.ServiceBus.Send", "MyQueue1") . Všimněte si, že na konci není žádné "Start" nebo "Stop". Slouží k filtrování konkrétních operací nebo front. Pokud metoda zpětného volání vrátí hodnotu false , události pro operaci se neodesílají.

   • Pro operace "proces" a "ProcessSession" obdržíte také IsEnabled(<OperationName>, string entity, Activity activity) zpětné volání. Slouží k filtrování událostí na základě activity.Id vlastností značek nebo.

2. IsEnabled(<OperationName>.Start) například IsEnabled("Microsoft.Azure.ServiceBus.Send.Start") . Kontroluje, zda by měla být aktivována událost Start. Výsledek má vliv pouze na událost Start, ale další instrumentace na ní není závislá.

IsEnabledPro událost zastavení není k dispozici.

Pokud je výsledkem nějaké operace výjimka, IsEnabled("Microsoft.Azure.ServiceBus.Exception") je volána metoda. Přihlásili jste se k odběru událostí Exception a zabráníte zbytek instrumentace. V takovém případě je stále nutné tyto výjimky zpracovat. Vzhledem k tomu, že je jiná instrumentace zakázaná, neměli byste očekávat, že by kontext trasování byl tok se zprávami od spotřebitelů k producentovi.

Můžete použít IsEnabled také implementaci strategií vzorkování. Vzorkování založené na Activity.Id nebo Activity.RootId zaručuje konzistentní vzorkování napříč všemi pneumatikami (Pokud je šířené systémem trasování nebo vlastním kódem).

V DiagnosticSource případě, že je pro stejný zdroj k dispozici více posluchačů, je pro přijetí události dostačující pouze jeden naslouchací proces, takže není IsEnabled zavolána žádná záruka.