Add ASP.NET Core instrumentation to OpenTelemetry tracing

[piqpiq (lepiqpiqclem)]

Why make this change?

• Closes [Bug]: No server-side HTTP request trace spans #3559
  • When OpenTelemetry is enabled, DAB exports no span for inbound REST, GraphQL or MCP requests. The TracerProvider only registers HttpClientInstrumentation, so the only exported spans are outbound calls DAB makes itself (schema download, health self-checks). An incoming traceparent is also not continued, which breaks distributed traces going through DAB.

What is this change?

• Registers .AddAspNetCoreInstrumentation() in the WithTracing block of Startup.cs.
  • The OpenTelemetry.Instrumentation.AspNetCore package (1.12.0) is already referenced by Azure.DataApiBuilder.Service.csproj and Directory.Packages.props, but it was never used. No new dependency and no version change.
  • ASP.NET Core already creates an activity for every request on the Microsoft.AspNetCore activity source; without this call the OpenTelemetry SDK does not subscribe to it, so those activities are never sampled or exported.
  • Existing DAB spans (DABActivitySource, e.g. GET {entity} / QUERY {entity} in RestController) and HotChocolate spans now become children of the server span, and the incoming W3C traceparent is honored.
• SQL client spans (also mentioned in the issue) are intentionally left out of this PR: OpenTelemetry.Instrumentation.SqlClient is not available on the data_api_builder_build_packages feed, so adding it would fail restore (NU1301) until a maintainer adds it to the feed. Version 1.15.2 would be the compatible one (depends on OpenTelemetry.Api.ProviderBuilderExtensions >= 1.15.3, matching the current OpenTelemetry.Exporter.OpenTelemetryProtocol 1.15.3). Happy to follow up in a separate PR.

How was this tested?

• Integration Tests
  • Added OpenTelemetryTests.TestOpenTelemetryRecordsInboundHttpRequestSpan. It registers an ActivityListener on the Microsoft.AspNetCore source that never samples by itself, sends a request to the TestServer, and asserts that the server activity for that request path is Recorded. The activity can only be recorded if the OpenTelemetry TracerProvider subscribes to ASP.NET Core, so the test fails without the fix.
• Unit Tests
• Manual: the same one-line change applied on top of v2.0.12, running against SQL Server with OTLP gRPC export to Grafana Alloy → Tempo. Before: the OTEL SDK self-diagnostics log shows Instrumentations added = "HttpClientInstrumentation" and no request spans. After: one Server span per REST request is visible in Tempo.

Sample Request(s)

With runtime.telemetry.open-telemetry.enabled: true:

GET http://localhost:5000/api/Book

now exports a Server span (http.request.method=GET, url.path=/api/Book, http.response.status_code=200), with the existing DAB spans for the request (GET Book, QUERY Book) nested under it.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[piqpiq (lepiqpiqclem)]

@microsoft-github-policy-service agree

[Copilot]

Copilot review overview

🟡 Changes recommended

The test does not verify trace-context propagation; also correct the OpenTelemetry spelling nit.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1

Open (1)

• Test W3C traceparent propagation and parent span linkage · New

What changed in this PR

Adds ASP.NET Core OpenTelemetry instrumentation so inbound DAB requests emit server spans and participate in distributed tracing.

Changes:

• Registers AddAspNetCoreInstrumentation().
• Adds an integration test for inbound server-span recording.

File	Summary
src/​Service/​Startup.cs	Enables ASP.NET Core request tracing.
src/​Service.Tests/​Configuration/​Telemetry/​OpenTelemetryTests.cs	Tests inbound server-span creation.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.