[psx95]

Summary

Adds support for configuring PeriodicMetricReaderBuilder#setMaxExportBatchSize in opentelemetry-sdk-extension-autoconfigure via the otel.experimental.metric.export.max.batch.size system property (OTEL_EXPERIMENTAL_METRIC_EXPORT_MAX_BATCH_SIZE environment variable).

Motivation / Justification

PeriodicMetricReaderBuilder#setMaxExportBatchSize was added in #8296 and stabilized in #8829, and is supported in declarative configuration via max_export_batch_size/development. However, users relying on environment variable / system property autoconfiguration (such as zero-code OpenTelemetry Javaagent users or Spring Boot starter users) currently have no way to configure metric export batching:

1. Operational need alongside cardinality limits: Users who export a large number of metric data points (especially when increasing otel.java.metrics.cardinality.limit) can hit OTLP payload / gRPC message size limits or collector/backend ingestion limits per export request without batching.
2. Declarative config parity: Declarative configuration already supports max_export_batch_size/development on PeriodicMetricReaderModel, so declarative config remains a strict superset of env var / system property configuration.
3. Experimental prefix: Because the property is not yet standardized in the OpenTelemetry environment variable specification (and remains /development in opentelemetry-configuration), it is namespaced under otel.experimental.* to avoid locking in a stable property name prematurely.

Fix: #8936

[opentelemetry-pr-dashboard]

Pull request dashboard status

Merged · refreshed 2026-10-28 21:16 UTC

Status above doesn't look right?

• Anything look wrong? Report it with what you expected; it helps us improve the dashboard.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.42%. Comparing base (7647e49) to head (582ff05).

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #8935      +/-   ##
============================================
- Coverage     90.43%   90.42%   -0.01%     
- Complexity    10908    10909       +1     
============================================
  Files          1015     1015              
  Lines         29854    29858       +4     
  Branches       3901     3902       +1     
============================================
+ Hits          26998    26999       +1     
- Misses         1907     1908       +1     
- Partials        949      951       +2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jack-berg]

Couple of thoughts:

1. Have you tried introducing this env var at the spec level? Right now its a judgement call when we add java-specific env vars. If this var were defined in the spec, adding it would be a no-brainer.

2. java-specific env vars include a otel.java.* prefix to denote that they're java specific and to avoid collisions with possible future spec level vars.

3. Given that declarative config is stable, and we (otel project level) want to avoid having multiple ways to accomplish the same thing, the thought has been to eventually deprecate env vars completely in favor of declarative config. We're not there yet, but I still think we need to develop heuristics for when / why its appropriate to extend env vars vs. recommending to migrate to declarative config.

[psx95]

Couple of thoughts:

1. Have you tried introducing this env var at the spec level? Right now its a judgement call when we add java-specific env vars. If this var were defined in the spec, adding it would be a no-brainer.
2. java-specific env vars include a otel.java.* prefix to denote that they're java specific and to avoid collisions with possible future spec level vars.
3. Given that declarative config is stable, and we (otel project level) want to avoid having multiple ways to accomplish the same thing, the thought has been to eventually deprecate env vars completely in favor of declarative config. We're not there yet, but I still think we need to develop heuristics for when / why its appropriate to extend env vars vs. recommending to migrate to declarative config.

1. No, not yet - but I can send in a proposal upstream - The periodic exporting MetricReader already has env vars for export interval and timeout and I feel this would fit in nicely.

2. Does this need to be Java specific? The batching is now part of spec and is implemented across languages. The declarative config also has stabilized this property now. I'm thinking it could just be called OTEL_METRIC_EXPORT_MAX_BATCH_SIZE.

3. In any case, we would still at least be able to use the system props to configure via Autoconfigure module, right? IIUC, if you specify a system property recognizable by the autoconfigure module, you automatically get a compatible environment variable - we can obviously choose not to document it.

Let me know your thoughts on this.

cc: @jack-berg , @dashpole

[psx95]

Hi @psx95 — just a friendly reminder that this pull request is waiting on you. The dashboard status comment has the open items and is kept current.

• Replying is enough to hand it off — answer, explain why no change is needed, or ask a follow-up. The dashboard routes it onward once nothing on the list is waiting on you.
• To hand it back for any other reason, including the dashboard getting this wrong, comment /dashboard route:reviewers.

Just waiting on the spec PR to officially support the proposed env var here. Once this PR is merged, we should be ok to merge this.

[psx95]

Hey @jack-berg, the spec PR to officially support the proposed env var got merged. I believe this PR is ready for review / merge now.

[jack-berg]

Thanks for following up and working through the spec 👍