Azure / Azure/data-api-builder

[Bug]: No server-side HTTP request trace spans

Aperta
#3,559 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub
2.x telemetry
Lingua principale
C#
Stelle
1.5k
Fork
370
Merge medio
3g 17h
PR unite (30g)
8

Descrizione

When you call a DAB endpoint (REST, GraphQL, or MCP), no trace span is created for that request. The only spans DAB produces are outbound HTTP calls it makes itself — downloading its JSON schema from GitHub and pinging its own health endpoint. Inbound API traffic is invisible in traces.

This means you **cannot** use distributed tracing to follow a request through DAB. If a downstream service passes a `traceparent` header, DAB will not create a child span, breaking the trace chain.

## Expected

Every inbound HTTP request should produce a server-side span. In a standard ASP.NET Core app, this happens automatically when the OTEL SDK is configured with `AddAspNetCoreInstrumentation()`. A call to `GET /api/Todo` should appear in your trace viewer like this:

```
Span: GET /api/Todo
Kind: Server
Duration: 220ms
Attributes:
http.request.method = GET
url.path = /api/Todo
http.response.status_code = 200
http.route = /api/{entityName}/{primaryKeyRoute?}
```

Ideally, child spans would also appear for the SQL query DAB executes under the hood, giving a full picture:

```
[Server] GET /api/Todo ── 220ms
└─ [Client] SELECT ... FROM dbo.Todo ── 18ms
```

## Actual

The only 4 spans captured across 28+ API requests were all outbound (`Kind: Client`):

| # | What it is | Why it exists |
|---|-----------|---------------|
| Span 1 | `GET github.com` | DAB downloads its JSON schema file at startup |
| Span 2 | `GET release-assets.githubusercontent.com` | Redirect target of span 1 |
| Span 3 | `GET localhost:5000/api/...` | DAB's health check calls itself |
| Span 4 | `GET localhost:5000/api/...` | Another health self-check |

None of these represent a user's API call.

## Fix

DAB's OTEL `TracerProvider` setup needs to register the ASP.NET Core instrumentation source. In the `Startup.cs` (or wherever the OTEL SDK is configured), add:

```csharp
builder.Services.AddOpenTelemetry()
.WithTracing(tracing => tracing
.AddAspNetCoreInstrumentation() // <-- missing today
.AddSqlClientInstrumentation() // <-- also recommended
.AddHttpClientInstrumentation() // already present (System.Net.Http spans work)
.AddOtlpExporter(/* ... */)
);
```

`AddAspNetCoreInstrumentation()` hooks into the `Microsoft.AspNetCore.Hosting.HttpRequestIn` ActivitySource that ASP.NET Core already emits. Without it, those Activities are created but never sampled or exported.

Guida per i contributori

Apri la guida per i contributori

Direzione di ricerca

Inizia in Startup.cs o nel punto in cui viene configurato OTEL TracerProvider e analizza la configurazione esistente del tracing dei client HTTP. Riproduci il problema con una richiesta REST, GraphQL o MCP in ingresso e confronta gli span esportati con il server span previsto e la propagazione di traceparent. L'attività è completata quando le richieste in ingresso vengono visualizzate come server span; l'issue raccomanda inoltre gli span figli SQL.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
csharp
Ambito
api, backend, observability
Tipo di issue
Bug
Difficoltà
3/5
Tempo stimato
1-2 giorni
Stato di attività
Tranquilla
Chiarezza
Abbastanza chiara
Idoneità per principianti
55/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.