DiagnosticSource, EventCounters, Activity/OpenTelemetry Integration, and Correlation

Learning outcomes

1. Logs answer “what happened”; diagnostics add machine-readable event streams

ServiceHub can now emit safe structured logs, but a production observability pipeline also needs continuous counters and trace correlation. EF Core exposes several layers. DiagnosticSource/DiagnosticListener publishes rich in-process diagnostic events for EF operations. System.Diagnostics.Metrics publishes continuous numeric instruments through a named Meter. EventCounters are the older event-source counter mechanism and remain useful for tools such as dotnet-counters. Activity is .NET's representation of trace/span context. OpenTelemetry collects .NET logs, metrics, and activities and exports them to an observability backend.

2. DiagnosticListener is process-wide, not a DbContext-local hook

EF's diagnostic listener can expose events from every context in the process. That makes it useful for libraries, profilers, telemetry adapters, and process-wide diagnostics. It is not intended as a general-purpose logging API, and it is broader than a context-specific interceptor.

public sealed class EfDiagnosticObserver :    IObserver<DiagnosticListener>,    IObserver<KeyValuePair<string, object?>>{    private IDisposable? _efSubscription;    public void OnNext(DiagnosticListener listener)    {        if (listener.Name == DbLoggerCategory.Name)        {            _efSubscription = listener.Subscribe(this);        }    }    public void OnNext(KeyValuePair<string, object?> evt)    {        if (evt.Key.EndsWith("CommandExecuted", StringComparison.Ordinal))        {            Console.WriteLine($"EF diagnostic event: {evt.Key}; trace={Activity.Current?.TraceId}");        }    }    public void OnCompleted() => _efSubscription?.Dispose();    public void OnError(Exception error) => Console.Error.WriteLine(error);}

A real observer should filter aggressively and understand each payload type rather than reflect every object. The point of this example is topology: subscribing to DiagnosticListener.AllListeners can observe process-wide EF events, while an interceptor is registered on configured context instances. Register once with DiagnosticListener.AllListeners.Subscribe(new EfDiagnosticObserver()), retain the returned subscription for the intended application lifetime, and dispose it during shutdown.

3. EF Core 10 exposes first-class System.Diagnostics.Metrics

Since EF Core 9, the preferred continuous numeric metrics use the standard .NET Metrics API. The meter name is Microsoft.EntityFrameworkCore. The currently documented instruments include:

These are application/EF signals. They do not tell you database CPU, lock waits, buffer-cache efficiency, or server connection saturation; those need provider/database telemetry.

4. Export the EF meter with stable OpenTelemetry packages

The mandatory lesson does not require a telemetry backend. A free console exporter is sufficient to prove that EF metrics can be collected. The stable OpenTelemetry hosting line is 1.18.0 as of this chapter review.

dotnet add package OpenTelemetry.Extensions.Hosting --version 1.18.0dotnet add package OpenTelemetry.Exporter.Console --version 1.18.0

builder.Services.AddOpenTelemetry()    .WithMetrics(metrics => metrics        .AddMeter("Microsoft.EntityFrameworkCore")        .AddConsoleExporter());

Run ServiceHub queries and SaveChanges calls, then inspect the emitted measurements. Do not add high-cardinality dimensions such as work-order numbers or SQL text to your own metrics; metrics are for aggregation, not payload storage.

5. EventCounters are the legacy observation path

EF Core still exposes legacy counters, and dotnet-counters can monitor them without application code. This is useful on an existing process or when your tooling has not moved to System.Diagnostics.Metrics. Do not assume the names/aggregation semantics are identical to the new meter.

dotnet tool install --global dotnet-countersdotnet-counters monitor   --counters Microsoft.EntityFrameworkCore   --process-id <PID>

Typical output includes active contexts, queries/sec and total queries, query-cache hit rate, SaveChanges counts, execution-strategy failures, and optimistic concurrency failures. Use it as a live diagnostic view, not a durable time-series store.

6. Correlation begins at the application Activity

An HTTP request, message handler, or scheduled job should establish a trace context before data access. In .NET, Activity represents the span context that flows through asynchronous work. Logs can include Activity.Current.TraceId; diagnostic events and instrumentation libraries can attach database spans to the same trace.

public static class ServiceHubTelemetry{    public static readonly ActivitySource Source =        new("ServiceHub.Workflows", "1.0.0");}using var activity = ServiceHubTelemetry.Source.StartActivity("dispatch.rebuild");activity?.SetTag("servicehub.operation", "dispatch.rebuild");await RebuildDispatchQueueAsync(db, cancellationToken);logger.LogInformation(    "Dispatch rebuild completed; TraceId={TraceId}",    Activity.Current?.TraceId);

Do not tag the activity with customer name, work-order summary, or arbitrary SQL. Stable operation names and low-cardinality tags are enough to find the trace and then inspect authorized evidence.

7. Optional EF spans: the current OpenTelemetry EF package is still beta

OpenTelemetry.Instrumentation.EntityFrameworkCore consumes EF relational diagnostics and creates trace activities for outgoing database operations. At review time the latest package is 1.18.0-beta.1; NuGet labels the component beta because database semantic conventions remain experimental. It is compatible with .NET 10 but must be treated as prerelease.

dotnet add package OpenTelemetry.Instrumentation.EntityFrameworkCore   --version 1.18.0-beta.1   --prerelease

builder.Services.AddOpenTelemetry()    .WithTracing(tracing => tracing        .AddSource("ServiceHub.Workflows")        .AddEntityFrameworkCoreInstrumentation()        .AddConsoleExporter());

The package documentation explicitly warns that query-parameter telemetry is experimental and disabled by default because parameters can contain sensitive data. Keep it disabled for this course.

8. Failure case: use TraceId, SQL text, and user IDs as metric labels

A developer exports a metric ef_query_duration_ms with labels trace_id, work_order_number, and full SQL. Every request creates a new time-series. The metrics backend consumes excessive memory/storage and now contains sensitive query payloads.

Repair: keep metrics low-cardinality: operation (dispatch.queue), provider (sqlite), outcome (success/error), perhaps a bounded query-template identifier. Put trace IDs on logs/spans where exemplars or links are appropriate, not as a metric dimension.

9. Mandatory lab: correlate one request/job, metrics, and EF work

1. Start a ServiceHub operation inside an application-owned ActivitySource activity.
2. Enable the stable OpenTelemetry console exporter for the Microsoft.EntityFrameworkCore meter or observe legacy counters with dotnet-counters.
3. Execute a query and one SaveChanges; verify query/save metrics move.
4. Log the current trace ID in the application operation.
5. Optionally install the beta EF instrumentation in a disposable branch/lab and observe relational spans under the same trace context.
6. Verify no customer values, work-order summaries, SQL parameters, or connection-string secrets appear in exported attributes.
7. Record which signals are EF-provided versus application-, provider-, or database-provided.

10. Production judgment

Use the EF meter for process health and query-cache/concurrency/retry signals, DiagnosticSource when a process-wide rich-event consumer is justified, and Activity/OpenTelemetry for cross-component correlation. Keep legacy EventCounters for compatibility/tooling, not as the conceptual center of a new dashboard. Treat the beta EF OpenTelemetry instrumentation as optional and version-pinned. The next lesson goes one level deeper: interceptors can not only observe but modify or suppress EF operations, which makes them powerful—and dangerous.

Authoritative references

Observability and diagnostics are version-, provider-, and topology-sensitive. Re-check these primary sources before standardizing a production telemetry contract.

• Metrics in EF Core — System.Diagnostics.Metrics instruments and legacy EventCounters
• Using diagnostic listeners in EF Core — process-wide EF DiagnosticListener events
• Overview of logging and interception - EF Core — when to use diagnostic listeners, logging, events and interceptors
• .NET observability with OpenTelemetry — ILogger, Meter and ActivitySource relationship to OpenTelemetry
• OpenTelemetry .NET — current traces, metrics and logs guidance
• OpenTelemetry.Instrumentation.EntityFrameworkCore — beta relational EF instrumentation and parameter/privacy warnings