Merge pull request #286763 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: Albertyang0

articles/sentinel/tutorial-enrich-ip-information.md

@@ -43,6 +43,8 @@ To complete this tutorial, make sure you have:
     - [**Microsoft Sentinel Contributor**](../role-based-access-control/built-in-roles.md#microsoft-sentinel-contributor) on the Log Analytics workspace where Microsoft Sentinel is deployed. 
     - [**Logic App Contributor**](../role-based-access-control/built-in-roles.md#logic-app-contributor), and **Owner** or equivalent, on whichever resource group will contain the playbook created in this tutorial.
 
+- Installed [VirusTotal Solution from the Content Hub](https://azuremarketplace.microsoft.com/en-gb/marketplace/apps/azuresentinel.azure-sentinel-solution-virustotal?tab=Overview)
+
 - A (free) [VirusTotal account](https://www.virustotal.com/gui/my-apikey) will suffice for this tutorial. A production implementation requires a VirusTotal Premium account.
 
 ## Create a playbook from a template

articles/service-bus-messaging/message-counters.md

@@ -20,6 +20,8 @@ This article shows you different ways of getting message counts for a queue or s
 
 If an application wants to scale resources based on the length of the queue, it should do so with a measured pace. The acquisition of the message counters is an expensive operation inside the message broker, and executing it frequently directly and adversely impacts the entity performance.
 
+Another useful metric to consider for scaling is the time between when the latest message was sent and when it was processed, also known as "critical time". This is helpful for scenarios where a queue may have thousands of messages in it, but the processing is fast enough to keep up, giving a "critical time" of only a couple of seconds, which may be more than enough for something like an email sending endpoint. Third-party libraries like [NServiceBus](https://docs.particular.net/nservicebus/operations/opentelemetry#meters-emitted-meters) emit this and other useful metrics via OpenTelemetry.
+
 > [!NOTE]
 > The messages that are sent to a Service Bus topic are forwarded to subscriptions for that topic. So, the active message count on the topic itself is 0, as those messages have been successfully forwarded to the subscription. Get the message count at the subscription and verify that it's greater than 0. Even though you see messages at the subscription, they are actually stored in a storage owned by the topic. If you look at the subscriptions, then they would have non-zero message count (which add up to 323 MB of space for this entire entity).
 

articles/service-bus-messaging/service-bus-end-to-end-tracing.md

@@ -12,7 +12,7 @@ ms.custom: devx-track-csharp, devx-track-dotnet
 One of the common problems in micro services development is the ability to trace operation from a client through all the services that are involved in processing. It's useful for debugging, performance analysis, A/B testing, and other typical diagnostics scenarios.
 One part of this problem is tracking logical pieces of work. It includes message processing result and latency and external dependency calls. Another part is correlation of these diagnostics events beyond process boundaries.
 
-When a producer sends a message through a queue, it typically happens in the scope of some other logical operation, initiated by some other client or service. The same operation is continued by consumer once it receives a message. Both producer and consumer (and other services that process the operation), presumably emit telemetry events to trace the operation flow and result. In order to correlate such events and trace operation end-to-end, each service that reports telemetry has to stamp every event with a trace context.
+When a producer sends a message through a queue, it typically happens in the scope of some other logical operation, initiated by some other client or service. The same operation is continued by consumer once it receives a message. Both producer and consumer (and other services that process the operation), presumably emit telemetry events to trace the operation flow and result. In order to correlate such events and trace operation end-to-end, each service that reports telemetry has to stamp every event with a trace context. One library that can help developers have all of this telemetry emitted by default is [NServiceBus](https://docs.particular.net/nservicebus/operations/opentelemetry).
 
 Microsoft Azure Service Bus messaging has defined payload properties that producers and consumers should use to pass such trace context.
 The protocol is based on the [W3C Trace-Context](https://www.w3.org/TR/trace-context/).