-
Notifications
You must be signed in to change notification settings - Fork 862
[sdk-metrics] ExemplarReservoir dedicated diagnostic and custom ExemplarReservoir support #5558
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
a5105e8
9972819
2ef5120
02b3751
b7182b4
b317f2b
36b0a45
f73bad5
8eff6b2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,62 @@ | ||
| # OpenTelemetry .NET Diagnostic: OTEL1004 | ||
|
|
||
| ## Overview | ||
|
|
||
| This is an Experimental API diagnostic covering the following APIs: | ||
|
|
||
| * `ExemplarReservoir` | ||
| * `FixedSizeExemplarReservoir` | ||
| * `ExemplarMeasurement<T>` | ||
| * `MetricStreamConfiguration.ExemplarReservoirFactory.get` | ||
| * `MetricStreamConfiguration.ExemplarReservoirFactory.set` | ||
|
|
||
| Experimental APIs may be changed or removed in the future. | ||
|
|
||
| ## Details | ||
|
|
||
| The OpenTelemetry Specification defines an [ExemplarReservoir | ||
| API](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#exemplarreservoir) | ||
| and a mechanism for configuring `ExemplarReservoir` via the [View | ||
| API](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#stream-configuration) | ||
| in the Metrics SDK. | ||
|
|
||
| From the specification: | ||
|
|
||
| > The SDK MUST provide a mechanism for SDK users to provide their own | ||
| > ExemplarReservoir implementation. This extension MUST be configurable on a | ||
| > metric View, although individual reservoirs MUST still be instantiated per | ||
| > metric-timeseries... | ||
|
|
||
| We are exposing these APIs experimentally for the following reasons: | ||
|
|
||
| * `FixedSizeExemplarReservoir` is not part of the spec. It is meant to help | ||
| custom reservoir authors and takes care of correctly creating & updating | ||
| `struct Exemplar`s (managing tag filtering when views are used), handles | ||
| `Exemplar` collection, and ensures all operations are safe to be called | ||
| concurrency (spec requirement). We want to see if this is helpful and meets | ||
| the needs of users. | ||
|
|
||
| * There is currently no way to use | ||
| `MetricStreamConfiguration.ExemplarReservoirFactory` to switch a metric to a | ||
| different built-in reservoir (`AlignedHistogramBucketExemplarReservoir` or | ||
| `SimpleFixedSizeExemplarReservoir`). This is something supported by the spec | ||
| but we want to understand the use cases and needs before exposing these types. | ||
| Also it seems the default reservoirs may change. | ||
|
|
||
| * There is currently no way to get access to the bucket index inside a reservoir | ||
| when a measurement is recorded against a histogram with explicit bounds. The | ||
| spec says the reservoir should calculate this given the | ||
| definition/configuration of the bounds but the SDK has already done this | ||
| computation. It seems unncessarily complicated to expose the configuration and | ||
| wasteful to do the work twice. We want to understand the types of algorithms | ||
| which users will want to implement before exposing something. | ||
|
|
||
| **TL;DR** We want to gather feedback on the usability of the API and for the | ||
| need(s) in general for custom reservoirs before exposing a stable API. | ||
|
|
||
| <!-- | ||
| ## Provide feedback | ||
|
|
||
| Please provide feedback on [this issue](TODO) if you need stable support for | ||
| custom `ExemplarReservoir`s. | ||
| --> |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -12,10 +12,10 @@ namespace OpenTelemetry.Metrics; | |
| /// <summary> | ||
| /// Represents an Exemplar measurement. | ||
| /// </summary> | ||
| /// <remarks><inheritdoc cref="Exemplar" path="/remarks/para[@experimental-warning='true']"/></remarks> | ||
| /// <remarks><inheritdoc cref="ExemplarReservoir" path="/remarks/para[@experimental-warning='true']"/></remarks> | ||
| /// <typeparam name="T">Measurement type.</typeparam> | ||
| #if NET8_0_OR_GREATER | ||
| [Experimental(DiagnosticDefinitions.ExemplarExperimentalApi, UrlFormat = DiagnosticDefinitions.ExperimentalApiUrlFormat)] | ||
| [Experimental(DiagnosticDefinitions.ExemplarReservoirExperimentalApi, UrlFormat = DiagnosticDefinitions.ExperimentalApiUrlFormat)] | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we not need this exposed?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The spec design is you give the This Should it be exposed? It isn't part of the spec so I don't know if we can/should expose it. Chatting with @alanwest, it does seem like a useful thing to have available to custom reservoirs. The spec could have "MAY" language about exposing it. But it isn't a blocker for the current plan for the first stable release. In general, we (me, @alanwest, @cijothomas) have a lot of questions/concerns about the reservoir design which is why I think it is a good idea to keep it in preview initially.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sounds good to me 👍 . I asked because of this reason only - |
||
| #endif | ||
| public | ||
| #else | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.