Merge pull request #109097 from spelluru/sbusappinsight0325

Application Insights SDK

Author: GitHubber17

articles/service-bus-messaging/media/service-bus-end-to-end-tracing/longer-duration.png

@@ -32,7 +32,7 @@ The protocol is based on the [HTTP Correlation protocol](https://github.com/dotn
 |  Diagnostic-Id       | Unique identifier of an external call from producer to the queue. Refer to [Request-Id in HTTP protocol](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/HttpCorrelationProtocol.md#request-id) for the rationale, considerations, and format |
 |  Correlation-Context | Operation context, which is propagated across all services involved in operation processing. For more information, see [Correlation-Context in HTTP protocol](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/HttpCorrelationProtocol.md#correlation-context) |
 
-## Service Bus .NET Client auto-tracing
+## Service Bus .NET Client autotracing
 
 Starting with version 3.0.0 [Microsoft Azure ServiceBus Client for .NET](/dotnet/api/microsoft.azure.servicebus.queueclient) provides tracing instrumentation points that can be hooked by tracing systems, or piece of client code.
 The instrumentation allows tracking all calls to the Service Bus messaging service from client side. If message processing is done with the [message handler pattern](/dotnet/api/microsoft.azure.servicebus.queueclient.registermessagehandler), message processing is also instrumented
@@ -82,6 +82,12 @@ Nested traces and exceptions reported during message processing are also stamped
 
 In case you make calls to supported external components during message processing, they are also automatically tracked and correlated. Refer to [Track custom operations with Application Insights .NET SDK](../azure-monitor/app/custom-operations-tracking.md) for manual tracking and correlation.
 
+If you are running any external code in addition to the Application Insights SDK, expect to see longer **duration** when viewing Application Insights logs. 
+
+![Longer duration in Application Insights log](./media/service-bus-end-to-end-tracing/longer-duration.png)
+
+It doesn't mean that there was a delay in receiving the message. In this scenario, the message has already been received since the message is passed in as a parameter to the SDK code. And, the **name** tag in the App Insights logs (**Process**) indicates that the message is now being processed by your external event processing code. This issue is not Azure-related. Instead, these metrics refer to the efficiency of your external code given that the message has already been received from Service Bus. See [this file on GitHub](https://github.com/Azure/azure-sdk-for-net/blob/4bab05144ce647cc9e704d46d3763de5f9681ee0/sdk/servicebus/Microsoft.Azure.ServiceBus/src/ServiceBusDiagnosticsSource.cs) to see where the **Process** tag is generated and assigned once the message has been received from Service Bus. 
+
 ### Tracking without tracing system
 In case your tracing system does not support automatic Service Bus calls tracking you may be looking into adding such support into a tracing system or into your application. This section describes diagnostics events sent by Service Bus .NET client.  
 
@@ -139,7 +145,7 @@ In this example, listener logs duration, result, unique identifier, and start ti
 #### Events
 
 For every operation, two events are sent: 'Start' and 'Stop'. 
-Most probably, you are only interested in 'Stop' events. They provide the result of operation, as well as start time and duration as an Activity properties.
+Most probably, you are only interested in 'Stop' events. They provide the result of operation, as well as start time and duration as Activity properties.
 
 Event payload provides a listener with the context of the operation, it replicates API incoming parameters and return value. 'Stop' event payload has all the properties of 'Start' event payload, so you can ignore 'Start' event completely.