Azure / Azure/data-api-builder

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

Abierto
#3,559 0 comentarios 0 reacciones 0 asignados Ver en GitHub
2.x telemetry
Lenguaje dominante
C#
Estrellas
1.5k
Forks
370
Merge medio
3 d 22 h
PR fusionados (30 d)
9

Descripción

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.

Guía de contribución

Abrir la guía de contribución

Línea de trabajo

Comienza en Startup.cs o donde se configure OTEL TracerProvider, e inspecciona la configuración existente del tracing del cliente HTTP. Reproduce el problema con una solicitud REST, GraphQL o MCP entrante y compara los spans exportados con el server span esperado y la propagación de traceparent. La tarea se considera terminada cuando las solicitudes entrantes aparecen como server spans; el issue también recomienda spans hijos de SQL.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
csharp
Área
api, backend, observability
Tipo de issue
Error
Dificultad
3/5
Tiempo estimado
1-2 días
Estado de actividad
Tranquilo
Claridad
Bastante claro
Aptitud para principiantes
55/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.