Open trask opened 11 months ago
Current status: waiting for additional implementations to collect feedback.
Known implementations:
@open-telemetry/go-approvers @open-telemetry/dotnet-approvers @open-telemetry/python-approvers @open-telemetry/javascript-approvers Can you please comment on whether or not this is implemented in your respective language?
OTel .NET has not implemented this. I just created an issue to track this : https://github.com/open-telemetry/opentelemetry-dotnet/issues/5165
(Given .NET's special arrangement of maintaining the Metrics API in the .NET Runtime itself, the earliest we can do this is with next .NET release, which will be Nov 2024, with preview releases comings much earlier)
We currently do not have a prototype for this in the JavaScript SIG. Edit: I also just created an issue to track this: https://github.com/open-telemetry/opentelemetry-js/issues/4365
Linking related: #3790
pre-requisite for Go: #3803
Greetings from Rubyland!
I'm working on implementing advisory parameters for Ruby
I'm just planning to work on explicit bucket boundaries for now, but I'm curious about the attributes advisory parameter. How close are we to stability?
For context, we just released an early, experimental metrics API and SDK (OTLP exporter coming soon). The feature set is not complete, but we're working our way through the spec compliance checklist. Advisory parameters came up because I'd like to add metrics to our instrumentation.
If it seems like this feature will stabilize soon, it might be nice to have all instrumentation start with this parameter available.
How close are we to stability?
I think we still only have the 1 prototype (Java). I've added this to Monday's maintainer meeting. If we can get another language to implement it, and if Ruby can also implement it, that would give us enough prototypes (3) to propose stabilization.
What are you trying to achieve?
Stability of Instrument advisory parameter: Attributes
Additional context.
Java Instrumentation is relying heavily on this feature, e.g. emitting HTTP span attributes on HTTP metrics and using this instrument advice to report only the expected attributes, and we would benefit from the feature being stable.
Has anyone else implemented/prototyped this advisory parameter yet?
cc @open-telemetry/go-approvers @open-telemetry/dotnet-approvers @open-telemetry/python-approvers @open-telemetry/javascript-approvers