[OpenTelemetry] Support opt-in capture of request and response headers

Aperta
  • Qualcosa non va?
#70,349 0 commenti 2 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
csharp
Ambito
backend, observability

Direzione di ricerca

Start by reading the hosting code around CreateInitializeActivityTags, then trace where the Activity stops and how SuppressActivityOpenTelemetryData is applied. The issue describes separate opt-in request and response header lists, with request values available at sampling time. Done means the agreed configuration surface and header capture behavior are implemented; the issue leaves those design choices open.

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

Descrizione

area-hosting
Is there an existing issue for this?
  • I have searched the existing issues
Is your feature request related to a problem? Please describe the problem.

I want to capture selected request and response headers on the hosting Activity, as http.request.header.<key> and http.response.header.<key>, and have request headers available to samplers. ASP.NET Core has no way to do this today.

  • The semantic conventions define both attributes as stable, opt-in string arrays. They say "Instrumentations SHOULD require an explicit configuration of which headers are to be captured".
  • For HTTP server spans, http.request.header.<key> is one of the attributes that "SHOULD be provided at span creation time (if provided at all)" for sampling (http-spans).
  • Enrich callbacks in OpenTelemetry.Instrumentation.AspNetCore and custom listeners both run after the Activity is created and sampled, so headers can't drive sampling decisions.
Describe the solution you'd like

Opt-in header capture in hosting, targeting .NET 12. Would this be accepted? I'm happy to contribute the implementation.

  • Two configurable lists of header names, one for request headers and one for response headers. Both are empty by default, so nothing is captured and nothing changes.
  • Names are matched exactly, case-insensitively, with no wildcards
  • Request headers are added in CreateInitializeActivityTags as http.request.header.<lower-cased-name> with string-array values, so they are available to samplers.
  • Response headers are added when the Activity stops, as http.response.header.<lower-cased-name>.
  • Both respect SuppressActivityOpenTelemetryData.

Creation tags are added even when the request isn't sampled, so a configured list costs one header lookup per configured name per request. An empty list costs nothing.

Open questions:

  • What configuration surface would you prefer: a public API, an OTel-aligned environment variable as proposed in #69092, or both?
  • Should response headers be in scope, or request headers only?

Alternatives considered:

  • Enrich callbacks or a custom listener: these work for export, but headers are added after sampling, and every app writes the same code and requires the contrib instrumentation package.
  • Header capture in OpenTelemetry.Instrumentation.AspNetCore: this has the same post-sampling limitation and ideally the maintainers would like to deprecate this package once optional attributes are built into ASP.NET Core. This requires extra dependencies and registration for consumers vs. on a clean OOB experience.
Additional context
  • open-telemetry/opentelemetry-dotnet-contrib#5921: now that #65873 has made the contrib package largely optional, the preference there is to build this into ASP.NET Core for .NET 12 rather than add features to the package. Contrib may carry an interim bridge for net10.0/net11.0.
  • Within OTel there is a moratorium on new OTEL_ env vars so a discussion would need to occur on how ASP.NET Core users would opt in for this.
  • #69092 is a related request to make hosting's OpenTelemetry behaviour configurable.
Lingua principale
C#
Stelle
38.5k
Fork
11.6k
Merge medio
3g 1h
PR unite (30g)
289

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dotnet/aspnetcore

Tutte le issue di dotnet/aspnetcore

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.