Azure / Azure/data-api-builder

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

Ouverte
#3,559 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub
2.x telemetry
Langage dominant
C#
Étoiles
1.5k
Forks
370
Merge moyen
3 j 22 h
PR mergées (30 j)
9

Description

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.

Guide de contribution

Ouvrir le guide de contribution

Piste de recherche

Commencez dans Startup.cs ou à l’endroit où OTEL TracerProvider est configuré, puis examinez la configuration existante du tracing des clients HTTP. Reproduisez le problème avec une requête REST, GraphQL ou MCP entrante et comparez les spans exportés avec le server span attendu et la propagation de traceparent. La tâche est terminée lorsque les requêtes entrantes apparaissent comme des server spans ; l’issue recommande également des spans enfants SQL.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
csharp
Domaine
api, backend, observability
Type d'issue
Bug
Difficulté
3/5
Temps estimé
1-2 jours
Activité
Calme
Clarté
Plutôt claire
Accessibilité débutants
55/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.