Stabilize LogRecordProcessor.Enabled#4717
Stabilize LogRecordProcessor.Enabled#4717carlosalberto merged 10 commits intoopen-telemetry:mainfrom
Conversation
|
@open-telemetry/php-maintainers @open-telemetry/rust-maintainers @open-telemetry/go-maintainers, PTAL as OTel PHP, Rust, and Go are implementing this part of the specification. |
|
@pellared can you please seek feedback from languages that already implemented it? Just to confirm they are happy with the feature. |
This is what I have done here #4717 (comment) 😉 Awaiting approval from a PHP maintainer. I also think we can wait until next spec SIG meeting before merging. |
This demonstrates my reading comprehension. |
pellared
added
area:sdk
brettmc
left a comment
brettmc
left a comment
There was a problem hiding this comment.
Ok with PHP SIG to stabilize this (we have not implemented it yet)
However, given you already have According to, spec compliance matrix, I supposed to be also awaiting approval from OTel Ruby 😉 However, I am not sure if it is really implemented (see https://github.com/open-telemetry/opentelemetry-ruby/blob/main/logs_sdk/lib/opentelemetry/sdk/logs/log_record_processor.rb and https://github.com/open-telemetry/opentelemetry-ruby/blob/main/logs_api/lib/opentelemetry/logs/logger.rb). I think this is a mistake in the spec compliance matrix. @open-telemetry/ruby-maintainers, PTAL |
|
Hi @pellared, chiming in from the Ruby maintainers team. This was a typo. I'll open a PR to get it removed. |
This was a typo. The language does not currently support this feature. cc @pellared * [X] Related issues #4717 * [ ] Related [OTEP(s)](https://github.com/open-telemetry/oteps) # * [ ] Links to the prototypes (when adding or changing features) * [ ] [`CHANGELOG.md`](https://github.com/open-telemetry/opentelemetry-specification/blob/main/CHANGELOG.md) file updated for non-trivial changes * [X] [Spec compliance matrix](https://github.com/open-telemetry/opentelemetry-specification/blob/main/spec-compliance-matrix/template.yaml) updated if necessary
|
@open-telemetry/technical-committee, I think this can be merged given the amount of time this PR is opened, the approvals it received, and the fact that we just had a spec release. |
### Context - Make the W3C randomness flag required. ([#4761](#4761)) ### Traces - Deprecate Zipkin exporter document and make exporter implementation optional. ([#4715](#4715)) - Add spec for `AlwaysRecord` sampler ([#4699](#4699)) ### Metrics - Stabilize `Enabled` API for synchronous instruments. ([#4746](#4746)) - Allow instrument `Enabled` implementation to have additional optimizations and features. ([#4747](#4747)) ### Logs - Stabilize `LogRecordProcessor.Enabled`. ([#4717](#4717)) ### SDK Configuration - Clarifies that guidance related to boolean environment variables is not applicable to other configuration interfaces. ([#4723](#4723)) --------- Co-authored-by: Armin Ruech <7052238+arminru@users.noreply.github.com>
14 participants
Fixes #4458
According to spec compliance matrix this feature is already implemented in 2 languages (Go and Rust; PHP approved, but not implemented yet), even though it is marked as optional.
In OTel Go, the design and implementation of this feature have remained unchanged since 2025-03-05. Since that release, we haven’t received any feedback or proposals suggesting changes.
Given this, I would like to propose stabilizing this feature in the specification. Doing so is also a prerequisite for stabilizing the OTel Go Logs SDK.
From #4458 (comment)
Advanced processing guidelines, they already show how to implement
Enabledand how processors can be composed (e.g. chained).Examples from OTel Go documentation:
More info on use cases, chaining/composing processors, and declarative configuration: #4717 (comment)
Approvals from languages that implement (or plan to implement)
LogRecordProcessor.Enabled: