Azure / Azure/data-api-builder
[Bug]: No server-side HTTP request trace spans
- 主要言語
- C#
- スター
- 1.5k
- フォーク
- 370
- 平均マージ
- 3日 22時間
- マージ済み PR(30日)
- 9
説明
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.
コントリビューションガイド
調査の方向性
Startup.cs、または OTEL TracerProvider が設定されている箇所から始めて、既存の HTTP クライアントのトレーシング設定を確認します。受信した REST、GraphQL、または MCP リクエストで問題を再現し、エクスポートされたスパンを、期待されるサーバースパンおよび traceparent の伝播と比較します。受信リクエストがサーバースパンとして現れれば完了です。SQL の子スパンも、この issue で推奨されています。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- csharp
- 領域
- api, backend, observability
- issue の種類
- バグ
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 活発さ
- 静か
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 55/100