v7: OpenTelemetry tracing and metrics, Microsoft.Extensions.Logging #90

Activity

1. christopherread

   added this to the v7 milestone on Oct 25, 2026
2. christopherread

   added

   enhancement

   on Oct 25, 2026
3. christopherread

   added 2 commits that reference this issue on Oct 25, 2026

   OpenTelemetry tracing and metrics, and Debug logging of outgoing mess…

   ...

   4da4be6

   v7: Carry trace context in message headers across processes (#116)

   ...

   664607b
4. christopherread commented on Oct 26, 2026

   

   christopherread

   on Oct 26, 2026

   Last edited by christopherread

   OwnerAuthor

   More actions

   Status on the v7 branch.

   Merged

   • v7: OpenTelemetry tracing and metrics, Debug logging #115:

     • an ActivitySource and a Meter named Obvs (ObvsTelemetry);
     • send, publish, request, reply and process spans, following the OpenTelemetry messaging conventions;
     • the messaging.client.sent.messages and messaging.process.duration metrics;
     • ILogger logging of outgoing messages at Debug level.

   • v7: Carry trace context in message headers across processes #116: trace context carried in message headers (traceparent and tracestate), so the receiver's span continues the sender's trace. It started with RabbitMQ and the in-memory transport.

   • Header support on the other transports:

     • NATS (v7: UseNats with options from configuration, and headers over NATS #118);
     • Kafka (v7: UseKafka with options from configuration, and headers over Kafka #119);
     • ActiveMQ (v7: UseActiveMq with options from configuration, and headers over ActiveMQ #121);
     • Azure Service Bus (v7: Obvs.AzureSB, an Azure Service Bus transport #123).

     Each has a broker test showing the trace continues from one host to another.

   Left

   • The "done when": a sample app showing end-to-end traces across two services in an OpenTelemetry exporter (v7: a migration guide, a v6 and v7 interop test, and the examples on v7 (#95) #154). The examples' client and service trace with OpenTelemetry's console exporter, and a command's trace crosses both apps under one trace ID.
   • Retiring Obvs.Monitoring.AppMetrics, .ElasticSearch, .PerformanceCounters and Obvs.Logging.NLog. They're removed from the v7 branch (v7: System.Text.Json by default, and retire the v6-only packages (#93) #144) and stay on v6. Deprecating them on NuGet is tracked in v7: Fewer packages: System.Text.Json default, retire unmaintained extensions #93.
   • Metrics for messages received and failed: messaging.client.consumed.messages and obvs.process.failed.messages (Obvs.Hosting: metrics for received and failed messages #137).
   • Count responses as received, and messages a transport can't deserialize, which needs a hook every transport calls. Add error.type to messaging.client.sent.messages for failed sends (v7: count failed sends, responses, and messages transports can't deserialize (#90) #147). The hook is ObvsTransportTelemetry.RecordUndeserializable. Azure Service Bus, SQS and JetStream call it. The other transports report such a message as an error on the bus's stream, which is now logged.
5. christopherread

   added a commit that references this issue on Oct 27, 2026

   Merge pull request #147 from christopherread/v7-telemetry-gaps

   ...

   92821dd
6. christopherread commented on Oct 27, 2026

   

   christopherread

   on Oct 27, 2026

   OwnerAuthor

   More actions

   Done in #115 (OpenTelemetry tracing and metrics), #116, #118, #119, #121 and #123 (trace context in message headers on each transport), #137 (received and failed message metrics), #146 (Microsoft.Extensions.Logging for bus and transport errors), #147 (failed sends, responses and undeserializable messages), and #154 (the examples, where a command's trace crosses both apps). Merged into v7.
7. christopherread

   closed this as completedon Oct 27, 2026