Add support for batching in PeriodicMetricReader - #8296
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #8296 +/- ##
============================================
- Coverage 90.82% 90.82% -0.01%
- Complexity 7927 7944 +17
============================================
Files 895 896 +1
Lines 23872 24010 +138
Branches 2378 2390 +12
============================================
+ Hits 21681 21806 +125
- Misses 1446 1456 +10
- Partials 745 748 +3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Signed-off-by: Gregor Zeitlinger <gregor.zeitlinger@grafana.com>
# Conflicts: # sdk/metrics/src/main/java/io/opentelemetry/sdk/metrics/export/MetricExportBatcher.java
…ropagation' into lane-a-pr-8296 # Conflicts: # sdk/metrics/src/test/java/io/opentelemetry/sdk/metrics/export/PeriodicMetricReaderTest.java Signed-off-by: Gregor Zeitlinger <gregor.zeitlinger@grafana.com>
Signed-off-by: Gregor Zeitlinger <gregor.zeitlinger@grafana.com>
…propagation Fix batched forceFlush failure and make batching linear
jack-berg
left a comment
There was a problem hiding this comment.
Couple of comments, but looks pretty good!
|
Addressed all the feedback on this PR and added a Changelog entry as well. The CI Build failure on Windows for Java 11 looks like a transient error and might be fixed upon retrying. |
| public static SdkMeterProviderBuilder setMaxExportBatchSize( | ||
| SdkMeterProviderBuilder sdkMeterProviderBuilder, int maxExportBatchSize) { | ||
| try { | ||
| Method method = | ||
| SdkMeterProviderBuilder.class.getDeclaredMethod("setMaxExportBatchSize", int.class); | ||
| method.setAccessible(true); | ||
| method.invoke(sdkMeterProviderBuilder, maxExportBatchSize); | ||
| } catch (NoSuchMethodException | IllegalAccessException | InvocationTargetException e) { | ||
| throw new IllegalStateException( | ||
| "Error calling setMaxExportBatchSize on SdkMeterProviderBuilder", e); | ||
| } | ||
| return sdkMeterProviderBuilder; | ||
| } |
There was a problem hiding this comment.
I don't think this works? there's no setMaxExportBatchSize method on SdkMeterProviderBuilder and that class is final
There's a real possibility i'm just being dumb though
…er (open-telemetry#5265) Part of open-telemetry#5184 ## Changes Clarifies the behavior of `maxExportBatchSize` on `Periodic exporting MetricReader` based on feedback and findings from prototype implementations: - Clarified that `exportTimeoutMillis` applies to each individual `Export(batch)` invocation when `maxExportBatchSize` splits collected metric data into multiple batches. - Clarified that batches produced from a single `Collect()` call must be provided to `Export` serially and in-order before metric points from subsequent collections are provided. - Clarified that batches produced by splitting should not contain empty metric structures (metrics containing zero metric data points). - Clarified that if an export is still in progress when the next scheduled interval occurs, the reader must delay subsequent collection/export or skip that interval to prevent concurrent `Export` calls. - Clarified that `ForceFlush` exports batches serially and returns an error status if any `Export(batch)` call or the exporter's `ForceFlush()` fails/times out. * [x] Related issues: open-telemetry#5184 * [ ] Related [OTEP(s)](https://github.com/open-telemetry/oteps) # * [x] Links to the prototypes (when adding or changing features): * Go: open-telemetry/opentelemetry-go#8071 * Java: open-telemetry/opentelemetry-java#8296 * JS: open-telemetry/opentelemetry-js#6655 * [x] [`CHANGELOG.md`](https://github.com/open-telemetry/opentelemetry-specification/blob/main/CHANGELOG.md) file updated for non-trivial changes * [ ] [Spec compliance matrix](https://github.com/open-telemetry/opentelemetry-specification/blob/main/spec-compliance-matrix/template.yaml) updated if necessary * [ ] [Declarative config data model](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/data-model.md#overview) is updated if SDK config surface is changed --------- Co-authored-by: Reiley Yang <reyang@microsoft.com>
This PR adds support for configuring
setMaxExportBatchSizeon thePeriodicMetricReaderthat sets the maximum number of metric data points to be sent in a single export call.If the number of metric data points (across
Collection<MetricData>) scheduled to be export exceeds themaxExportBatchSize, the data points organized in batches and sent over multiple export calls.These changes do not modify the current timeout behavior, which is still per export call.
Fix #8245