Configurable aggregation temporality for OTLP registry #3145
Labels
enhancement
A general enhancement
registry: otlp
OpenTelemetry Protocol (OTLP) registry-related
spring-boot change
Change is needed in Spring Boot for this issue
Milestone
Comments
shakuzen
added
enhancement
3 tasks
shakuzen
pushed a commit
that referenced
this issue
Apr 10, 2023
…Registry (#3625) OTLP format supports delta and cumulative temporality. This adds the capability to export meters with delta temporality. Below are some behaviours this PR includes * capability to configure aggregation Temporality via property `otlp.aggregationTemporality` * Delta Temporality is supported by using StepMeters wherever applicable * Capability to export max as part of the HistogramDataPoint for Delta Temporality There are some remaining issues with using delta temporality. Fixes for these will be made as follow-ups. * max value in histogram is not right * histogram counts are not right * partial steps may not publish correct values Closes gh-3145 Co-authored-by: Jonatan Ivanov <[email protected]>
shakuzen
added
the
spring-boot change
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Please describe the feature request.
OTLP format supports delta and cumulative temporality. Currently the OTLP registry does not make this configurable and cumulative is always sent. While this should work for compliant OTLP receivers, as far as I understand, some users may have a preference for one and we could support making this configurable.
Rationale
OTLP explicitly does not have a preference of aggregation temporality. Since OTLP is not tied to a specific metrics backend, there is less reason for us to use one temporality over the other.
Additional context
See initial discussion: #3129 (comment). There is prior art in that the
SimpleMeterRegistryallows configuring whether it is cumulative or step based./cc @twicksell
The text was updated successfully, but these errors were encountered: