Make server.address and server.port to opt-in on HTTP server metrics #109
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #108
Most HTTP server instrumentations report
server.address
andserver.port
based on the requestHost
header as it's the only source of information they have.Depending on the reverse proxies presence and other infra configuration,
Host
header might come unmodified from clients. Malicious or buggy clients could cause a cardinality explosion and degrade the server metrics experience.The expectation is that the majority of HTTP applications do not need
server.address
andserver.port
attributes on metrics as these attributes are static and are the same for a specificservice.name
or a combination of resource attributes.They are beneficial in multi-host applications, but still, resource attributes set on the corresponding meter
and tracerproviders can be used to distinguish tenants.This PR changes
server.*
requirement level to:opt_in
for metrics, to mitigate the attack vectorrecommended
for traces. These attributes are still interesting, but not essential for the tracing experience.url.query
requirement level changed fromrecommended
torequired
(to matchurl.path
) on spans - this seems like a bug that slipped into BREAKING: Introduce commonurl.*
attributes, and improve use of namespacing underhttp.*
opentelemetry-specification#3355