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

Open
  • Is something wrong?
#70,349 0 comments 2 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
backend, observability

Research direction

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.

Written by the indexing model from the issue text.

Description

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.
Dominant language
C#
Stars
38.5k
Forks
11.6k
Avg merge
3d 1h
Merged PRs (30d)
289

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dotnet/aspnetcore

All issues in dotnet/aspnetcore

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.