[Spike] sdk/log: Change FilterProcessor to Filterer #5825
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #5825 +/- ##
=====================================
Coverage 84.5% 84.5%
=====================================
Files 272 273 +1
Lines 22734 22739 +5
=====================================
+ Hits 19224 19231 +7
+ Misses 3167 3165 -2
Partials 343 343 |
|
@open-telemetry/go-approvers, PTAL. |
| @@ -30,6 +29,7 @@ const ( | |||
| type providerConfig struct { | |||
| resource *resource.Resource | |||
| processors []Processor | |||
| filterers []Filterer | |||
There was a problem hiding this comment.
Just like the sampler in TracerProvider, could we only have a single instance here? If no one is complaining about the current implementation of the sampler, maybe it is ok to have just one instance.
There was a problem hiding this comment.
I think this approach is simpler and more consistent with how processing works.
For reference, the samplers can be decorators e.g. ParentBased Sampler. There is nothing technically preventing creating a filterer decorator. However, I feel that accepting multiple filterers increases the ease of use.
Initially I wanted to name it |
| param.SetSeverity(r.Severity()) | ||
| if !l.Enabled(ctx, param) { |
There was a problem hiding this comment.
Maybe it should be possible to make it possible to filter out based on more parameters than passed via Logger.Enabled? E.g. log record body, attributes, etc.
This could be enhanced later without making any breaking change.
Towards open-telemetry/opentelemetry-specification#4207
Based on Proposal B
This is another idea of implementing filtering to the Logs SDK.
I think this design is more in the spirit of the specification and current SDK design. The initial implementation of
Enabledwas designed when wrapping processors was also needed for implementing log record mutations during processing as log records were passed by value (and not by pointer).This approach should make adding custom filtering easier for the users in most cases (see the updated
ExampleFilterer).There is a little (mostly CPU) performance overhead caused by looping over filterers in
logger.Emit, but I do not find it significant.