Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extract HTTP request/response headers as span attributes #4237

Merged
merged 7 commits into from
Oct 5, 2021

Conversation

mateuszrzeszutek
Copy link
Member

This PR implements the HTTP request/response headers as span attributes semantic convention.

It includes:

  • new methods added in the HTTP extractors, and a new "configuration" class that needs to be passed to HTTP extractors
  • 4 new javaagent config properties (see HttpHeadersConfig)
  • implementations of the new methods in all HTTP instrumentations that we have

Things that will be done in the followings PRs:

  • remove userAgent() and host() implementations from all instrumentations, they're not needed anymore
  • implement captured headers configuration for library instrumentations
  • add tests that verify that headers were captured to HttpClientTest and HttpServerTest
  • move client IP extraction from ServerInstrumenter to HttpServerAttributesExtractor
  • maybe introduce a universal HttpHeadersGetter for all HTTP instrumentations? since we already have a method that returns values of any header in the extractor (it could implement update Get function in propagators to combine duplicate keys opentelemetry-specification#1884 properly too, for all HTTP instrumentations at the same time)
  • some documentation for the new config properties (other than Javadocs 😅 )

CLIENT =
CapturedHttpHeaders.create(
config.getList(
"otel.instrumentation.common.experimental.capture-http-headers.client.request"),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this part of ExperimentalConfig?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, you're right. Do you mind if I do that in a separate PR, after this one an #4255 are both merged? I'll just add another item to the TODO list in the PR description (and create a tracking issue for all of them once this PR is merged)

Comment on lines +14 to +18
private static final Cache<String, AttributeKey<List<String>>> requestKeysCache =
Cache.newBuilder().setMaximumSize(32).build();
private static final Cache<String, AttributeKey<List<String>>> responseKeysCache =
Cache.newBuilder().setMaximumSize(32).build();

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would it work to store the attribute name along with the header name in the configuration object, and avoid the need for this cache?

Copy link
Member Author

@mateuszrzeszutek mateuszrzeszutek Oct 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'd create different AttributeKey values for same headers, if there were more than 1 instrumentations (that use them) loaded.
And I wanted to avoid exposing the attribute keys in any public APIs (although now that I think of it, it could be implemented without doing so)

@mateuszrzeszutek mateuszrzeszutek merged commit 7473eff into open-telemetry:main Oct 5, 2021
@mateuszrzeszutek mateuszrzeszutek deleted the http-headers branch October 5, 2021 08:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants