mark the batchprocessor as deprecated#15046
Conversation
This continues the work to deprecate the batch processor in favour of the exporter helper's batching capabilities. Signed-off-by: alex boten <223565+codeboten@users.noreply.github.com>
atoulme
left a comment
There was a problem hiding this comment.
LGTM - no joke, it has been coming for a while
The date it was opened on is unfortunate |
songy23
left a comment
There was a problem hiding this comment.
cc @open-telemetry/collector-approvers
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #15046 +/- ##
==========================================
- Coverage 91.22% 91.22% -0.01%
==========================================
Files 697 697
Lines 44627 44629 +2
==========================================
+ Hits 40710 40711 +1
- Misses 2773 2775 +2
+ Partials 1144 1143 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
note i'm not putting in the changelog to avoid merging this until we have enough approvals |
There was a problem hiding this comment.
I don't think we should deprecate it. The processor (or its v2 version if implemented) is still useful in some specific scenarios.
I propose we instead implement the fixes and also change the docs to explain that the exporter helper should be used in most scenarios, describing the use cases for this component (or rather of the new better version of it).
If we actually implement the improvements on the processor as some kind of a v2 version, then v1 could be deprecated.
|
I volunteered myself to write an RFC to describe the difficult transition problem we're facing here. I have not seen the proposal to support major-versioning of components referred to in #13583 (comment), but it sounds like a potential solution. |
|
See #15047 |
|
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
## Tulip LTS May 2026 This PR prepares the Tulip LTS (Long-Term Support) release by upgrading all components to v0.151.0 and making targeted component changes to ensure production stability. ### What is an LTS? The upstream OpenTelemetry Collector ships new releases every ~2 weeks. The Tulip LTS provides a curated, validated baseline with extended support — giving production environments a stable target without upgrade fatigue. ### Changes #### Version bump All components upgraded from **v0.145.0 → v0.151.0**, verified against the [official otelcol-contrib manifest](https://github.com/open-telemetry/opentelemetry-collector-releases/blob/main/distributions/otelcol-contrib/manifest.yaml). - Core components: `v0.151.0` - Core providers: `v1.57.0` #### Component changes **Removed: `batchprocessor`** - Formally deprecated upstream ([PR #15046](open-telemetry/opentelemetry-collector#15046)) - Known data loss bug ([#12443](open-telemetry/opentelemetry-collector#12443)) — silently drops data when downstream exporters reject without queue/retry - Replaced with exporter-level `sending_queue` + `batch` configuration, which provides durable queuing, crash recovery, and retry with backoff **Removed: `memorylimiterprocessor`** - Being replaced upstream by [`memorylimiterextension`](https://github.com/open-telemetry/opentelemetry-collector/tree/main/extension/memorylimiterextension) - Not suitable for an LTS release since the processor variant is on a deprecation path **Removed: `healthcheckextension`** - The healthcheck extension v1 and v2 share code via a feature flag ([#42256](open-telemetry/opentelemetry-collector-contrib#42256)) - Including v1 would indirectly support v2, which is not the objective for an LTS release where component behavior must be fully predictable **Added: `redactionprocessor`** - Redacts sensitive data from telemetry attributes before export - Essential for enterprise environments with data privacy requirements (PII, HIPAA, GDPR) **Added: `filestorage` extension** - Persistent file-based storage for durable state across collector restarts (e.g., exporter sending queues, receiver checkpoints) **Added: `hostmetricsreceiver`** - Collects host-level metrics (CPU, memory, disk, network, filesystem, processes) - Essential for infrastructure monitoring use cases **Added: `filelogreceiver`** - Reads and parses log data from files on the host - Enables log collection pipelines for application, system, and container logs #### Configuration updates The default `config.yaml` now includes: - Exporter-level `sending_queue` for durable queuing - Exporter-level `batch` for efficient batching at the export stage - `retry_on_failure` with exponential backoff on all network exporters - Removed `memory_limiter` processor and `health_check` extension references #### Bug fix - Fixed bash 3.2 compatibility in `test/generate-trace.sh` (`&>>` → `>> file 2>&1`) ### Final component manifest (28 components) | Category | Count | Components | |----------|-------|------------| | Extensions | 7 | zpages, pprof, basicauth, bearertokenauth, oauth2clientauth, oidcauth, filestorage | | Receivers | 4 | otlp, nop, hostmetrics, filelog | | Exporters | 5 | debug, nop, otlp, otlphttp, file | | Processors | 7 | attributes, resource, span, probabilisticsampler, filter, transform, redaction | | Connectors | 1 | forward | | Providers | 3 | env, file, yaml | ### Documentation Full upgrade plan with migration guide available at `docs/tulip-lts-may2026-upgrade-plan.md`. ### Validation - `make generate-sources` — PASS - `make build` — PASS (Tulip v0.151.0 compiles with all 28 components) - `make test` — PASS (collector starts, traces generated and verified) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Exporters gain buffered sending, exporter-level batching, and retry/backoff controls * Added filestorage extension, host metrics and file log receivers, and a redaction processor * **Documentation** * Added Tulip LTS May 2026 upgrade plan with migration guidance and final component manifest * **Chores** * Upgraded Tulip distribution and component pins to v0.151.0; removed pipeline-level batch processor * Replaced health-check extension with pprof as the enabled extension * **Tests** * Adjusted trace generation script log redirection form * **Bug Fixes** * Startup readiness now detects service readiness from startup logs rather than health endpoint <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Signed-off-by: perebaj <perebaj@gmail.com>
|
Here's a link to the RFC with the deprecation proposal: #15273 |
|
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
This continues the work to deprecate the batch processor in favour of the exporter helper's batching capabilities.
Part of #12022