Document the new 9.1 OpenTelemetry meters

monitoring/metrics/definitions.md

@@ -15,10 +15,14 @@ Gathering metrics is important to know how a system works and if it works proper
 
 NServiceBus and ServiceControl capture a number of different metrics about a running endpoint including the processing time, the number of messages in each queue (differentiating between those pulled from the queue, those processed successfully, and those which failed processing), as well as "critical time".
 
-
 ### Processing time
 
-Processing time is the time it takes for an endpoint to **successfully** invoke all handlers and sagas for a single incoming message. Processing failures are not included in the processing time metric.
+Processing time is the time it takes for an endpoint to **successfully** process an incoming message. It includes:
+
+- Invoking all handlers and sagas for a single incoming message
+- Invoking the incoming message processing pipeline, which includes steps like deserialization or user defined pipeline behaviors.
+
+Processing failures are not included in the processing time metric.
 
 > [!NOTE]
 > Processing time does not include the time to store the outbox operation, transmit outgoing messages to the transport, fetch the incoming message, and complete the incoming message (i.e. commit the transport transaction or acknowledge the message).

nservicebus/operations/opentelemetry_content_core_[8,).partial.md

@@ -24,14 +24,22 @@ snippet: opentelemetry-enablemeters
 - `nservicebus.messaging.successes` - Total number of messages processed successfully by the endpoint
 - `nservicebus.messaging.fetches` - Total number of messages fetched from the queue by the endpoint
 - `nservicebus.messaging.failures` - Total number of messages processed unsuccessfully by the endpoint
+- `nservicebus.messaging.handler_time` - The time the user handling code takes to handle a message
+- `nservicebus.messaging.processing_time` - The time the endpoint takes to process a message from when it's fetched from the input queue to when processing completes. It includes:
+  - Invoking all handlers and sagas for a single incoming message
+  - Invoking the incoming message processing pipeline, which includes steps like deserialization or user defined pipeline behaviors.
+- `nservicebus.messaging.critical_time` - The time between when a message is sent and when it is fully processed. It is a combination of:
+  - Network send time: The time a message spends on the network before arriving in the destination queue
+  - Queue wait time: The time a message spends in the destination queue before being picked up and processed
+  - Processing time: The time it takes for the destination endpoint to process the message
 
 See the [OpenTelemetry samples](/samples/open-telemetry/) for instructions on how to send metric information to different tools.
 
 ## Logging
 
 NServiceBus supports logging out of the box. To collect OpenTelemetry-compatible logging in NServiceBus endpoints, it's possible to configure the endpoint to connect traces and logging when using `Microsoft.Extensions.Logging` package. See the [_Connecting OpenTelemetry traces and logs_ sample](/samples/open-telemetry/logging) for more details.
 
-## Alignment of host identifier 
+## Alignment of host identifier
 
 It is recommended to align the instance identifier between NServiceBus and OpenTelemetry so all logs, metrics, traces and audit messages can be correlated by a host (instance) if needed.
 
@@ -40,7 +48,7 @@ It is recommended to align the instance identifier between NServiceBus and OpenT
 
 NServiceBus adds an [host identifier to all audit messages](/nservicebus/hosting/override-hostid.md) and this instance identifier is also used to show [performance metrics for each running instance in ServicePulse](/monitoring/metrics/in-servicepulse.md). The [instance identifier used for ServicePulse value can be overriden](/monitoring/metrics/install-plugin.md#configuration-instance-id).
 
-OpenTelemetry also allows to customize the instance id used for `service.instance.id` in various ways. 
+OpenTelemetry also allows to customize the instance id used for `service.instance.id` in various ways.
 
 Consider aligning the instance ID used by OpenTelemetry and ServiceControl metrics API.