OpenTelemetry defines semantic conventions, e.g. https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/http/
micrometer-tracing-bridge-otel appears to contain code to support at least some of these but it is not activated by the spring-boot auto config. I think at one point it may have (https://github.com/spring-projects/spring-boot/commit/afdb651b04bba52a36d8568c79ff591361ef94dc) but was removed (https://github.com/spring-projects/spring-boot/commit/13a2ea9194eec702564e5cfac80da866cf822995). Hence we don't get http.client_ip, http.user_agent etc.
Comment From: jimbogithub
Looks like io.micrometer.observation.ObservationConvention<T> is probably the right way to do this now? I now have some of what I need by extending org.springframework.http.server.observation.DefaultServerRequestObservationConvention and adding KeyValues. This mechanism is a nice improvement as it avoids Filter ordering issues that I had with a legacy approach.
So perhaps a micrometer-bridge-otel-semconv module is needed?
Comment From: jonatan-ivanov
Let me give you some background/more details:
1. OTel Semantic Conventions are not stable yet: "status: experimental" on the page you linked and also the latest version in Maven Central is still -alpha.
2. That's one of the reason the stable/GA version of Spring Framework (or Boot) does not bring you in these since they are not production ready yet.
3. The other reason is backward-compatibility: the outputs of the default instrumentation (that is now in Spring Framework) is compatible with the previous one (that was in Boot 2.x). Also, using OTLP, the OTel APIs or the OTel SDK does not mean you must use semantic conventions.
If you want to use the OTel semantic conventions, defining your own ObservationConvention is the way. In fact, this is one of the reasons we designed ObservationConvention: with the use of it you can define whatever convention you want to use. Right now it is in our (our as in Micrometer folks, we need buy-in from the Boot and Framework teams) future plans to provide OTel conventions as well next to the default (/backward compatible) one and you can choose which one you want. Right now doing such a thing would be very risky since semantic conventions are not stable yet.
Comment From: wilkinsona
Thanks, @jonatan-ivanov.
I'm going to close this issue for now. If and when the conventions become stable we can consider how to offer a path to migrate to them. It's too soon to do that now and we prefer not to keep an issue open if it's going to be blocked indefinitely.
Comment From: tony-clarke-amdocs
@wilkinsona @jonatan-ivanov Would you accepts PRs for this, that was opt in for enabling this OTEL semantic convention?
Comment From: scottfrederick
@tony-clarke-amdocs These statements are still true:
- OTel Semantic Conventions are not stable yet: "status: experimental" on the page you linked and also the latest version in Maven Central is still -alpha.
- That's one of the reason the stable/GA version of Spring Framework (or Boot) does not bring you in these since they are not production ready yet.
We would not accept a PR that depends on something that does not have a GA release, so Andy's comment still applies.
Comment From: fahrradflucht
Given that some semantic conventions are now stable (e.g. HTTP spans), does it make sense to reconsider this issue? Or is your stance that the maven central package needs to be GA? Because that will obviously take way longer given that there are new conventions added for additional areas over time, but they are packaged together.
Comment From: scottfrederick
is your stance that the maven central package needs to be GA?
Yes, that is the case. We will not include a pre-GA version of any dependency in a GA version of Spring Boot.
Comment From: antechrestos
@scottfrederick Would it be acceptable to provide a PR that provides a convention / documentation that can be injected through configuration to HttpWebHandlerAdapter without putting the alpha dependency as @tony-clarke-amdocs suggested ?
Comment From: bclozel
@antechrestos we would rather keep such conventions in a dedicated project that syncs up with the semantic metadata. See https://github.com/micrometer-metrics/micrometer-otel-conventions-experimental
Comment From: antechrestos
Well... This repo does not seem quite active, last commit one year ago. Since I have issue integrating with some APM (method instead of http.method or rather http.request.method...) I will either implement on my side or a processor step in a otel collector sidecar.