Mark exemplars as stable.#3870
Conversation
|
Are we in need of the usual 3 languages implemented before calling this stable? The spec matrix shows only Java, though .NET has most of the implementation (in preview). I can send an update to spec matrix to reflect .NET's status. |
|
Those link does not tell much...For example, in JavaScript some exemplar related classes are there, but its not connected to SDK - its as good as saying JS does not support Exemplars... Which is why I was hoping every languages who implemented it will update the matrix, so we know if we have 3 languages implementing the spec. (or we can ask around as well :) ) OTel C++ also has some exemplars.. |
|
Go has an experimental implementation. It does not expose any API for configuration outside of environment variables. |
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
|
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
|
The TC discussed this during the Mar. 13th, 2024 meeting:
|
…#3943) Related to #3756. See this [conversation](#3870 (comment)) for context. --------- Co-authored-by: Reiley Yang <reyang@microsoft.com>
|
This is now ready for review/merge |
jack-berg
left a comment
There was a problem hiding this comment.
Was giving the exemplar spec a final read and noticed an issue.
|
#3994 would hopefully be the last piece before we mark Exemplar spec stable. Please refer to the #3944 PR description for the Technical Committee discussion details. @cijothomas would you check if it unblocks this PR? Thanks! |
Sure. Will check and post back here. |
cijothomas
left a comment
There was a problem hiding this comment.
Based on #3994 (comment), languages are free to chose a different default, and changing the default is considered non-breaking.
All the blocking issues are hence, addressable post stable as well.
|
@open-telemetry/specs-approvers @open-telemetry/specs-metrics-approvers @open-telemetry/technical-committee PTAL, I think this is ready to be merged by end of Fri. this week (Apr. 19th, 2024, PT). |
|
open-telemetry/opentelemetry-dotnet#5545 (comment) OTel .NET's performance hit when enabling exemplars is shown here. And OTel .NET is planning to make Exemplars opt-in for now. @jack-berg Do you have some perf numbers from Java handy that can be shared? |
|
I measured the Lightstep metrics SDK implementation of exemplars here and the performance hit is consistent with what has been reported for .NET. For example, a fast-path that was 45ns becomes 60ns, for a 33% hit. I believe this is acceptable, and if there are applications for which a few 10s or 100s of nanoseconds of additional cost per metrics event are limiting, there may be other paths to optimization other than simply disabling exemplars. |
|
Here are the benchmarks from the java repo. Sharing these without having recently dug into what elements of the exemplar implementation drive perf. The benchmark tests a variety of dimension:
There's a lot of noise here, so I've narrowed it down to show the time difference with a single thread and exemplars enabled and disabled: There's no doubt a performance impact to enabling examplars, but to add some context:
|
|
Benchmark after optimizing accessing the current nano time from the VM below. Much more in line with what we're seeing from .NET and Go. |
…open-telemetry#3943) Related to open-telemetry#3756. See this [conversation](open-telemetry#3870 (comment)) for context. --------- Co-authored-by: Reiley Yang <reyang@microsoft.com>
May 2024 release. Important changes: * Mark exemplars as stable (open-telemetry#3870) * Mark synchronous gauge as stable (open-telemetry#4019) * Record Links with empty/invalid SpanContext (open-telemetry#3928)
Fixes #3756
Changes
For non-trivial changes, follow the change proposal process.
CHANGELOG.mdfile updated for non-trivial changesspec-compliance-matrix.mdupdated if necessary