search

open-telemetry / semantic-conventions

Defines standards for generating consistent, accessible telemetry across a variety of domains
Apache License 2.0
277 stars 175 forks source link

`http.response.header.content-length` and `http.request.header.content-length` attributes are missing #1439

Closed pellared closed 1 month ago

pellared commented 1 month ago

Area(s)

area:http

What happened?

The http.response.header.content-length and http.request.header.content-length attributes are missing or the deprecated attributes have improper description.

See: https://github.com/search?q=repo%3Aopen-telemetry%2Fsemantic-conventions%20http.response.header.content-length&type=code

CC @IdlePhysicist

Semantic convention version

v1.27.0

Additional context

Discussed in https://github.com/open-telemetry/opentelemetry-go/discussions/5853

trask commented 1 month ago

http.response.header.content-length is a specialization of http.response.header.<key>

maybe we can make this clearer in the deprecation note

trask commented 1 month ago

@pellared let me know if #1444 addresses the confusion, thanks!

IdlePhysicist commented 1 month ago

Hi @trask, I am the one who opened the discussion that lead to this issue being filed.

Firstly thanks for putting up your PR, but your clarification doesn't have much contextual impact for me. I understand that there are potentially many keys under http.response.header & http.request.header.

What I think I am missing is that why there is no HTTPRequestHeaderContentLengthKey or anything prefixed with HTTPRequestHeader? For every other deprecation that I encountered, when updating from semconv v1.24.0 to semconv v1.26.0, there was a corresponding replacement constant in the Go package (the example that I gave in my original post was semconv.HTTPURLKey -> semconv.URLFullKey). I suspect that the issue is where does one stop? Having a constant for each and every key is likely a path to madness.

I am wondering if we should be using attribute.Key("<key>") in general going forward and defining our own constants in code if or as needed?

trask commented 1 month ago

hi @IdlePhysicist!

Having a constant for each and every key is likely a path to madness.

http.request.header.<key> is a special kind of semantic attribute because there are infinite number of different HTTP headers:

https://github.com/open-telemetry/semantic-conventions/blob/87ec4e6e3b56effd895775f4f8f63e412bde7f75/docs/attributes-registry/http.md?plain=1#L20

I'm not sure if/how Go encodes these special semantic attributes, probably @pellared can guide you better there. Here's how they work in Java:

https://github.com/open-telemetry/semantic-conventions-java/blob/dd1d40c6be372bc73e203307d4a02c24c5ce89f2/semconv/src/main/java/io/opentelemetry/semconv/HttpAttributes.java#L33-L34

jsuereth commented 1 month ago

Go (and the collector) do not support template attribute types in their semconv gen. There's actually a decent class of things not supported in Go that have evolved in Semconv.

We had a discussion withing the WG recently (about this). @MrAlias and @dashpole may be able to give a better estimate on when those may be supported in Go. I haven't been able to keep up to date on the status there myself.

References https://github.com/open-telemetry/opentelemetry-go/issues/5668 so this context is available for whomever updates semconv for Go.