-
Notifications
You must be signed in to change notification settings - Fork 394
Open
Labels
coreInvolves Datadog core librariesInvolves Datadog core librariesdev/refactorInvolves refactoring existing componentsInvolves refactoring existing componentsfeature-requestA request for a new feature or change to an existing oneA request for a new feature or change to an existing one
Description
Currently, the Datadog::Pipeline
is a global-level class that has mutable state. It is configured via Datadog::Pipeline.before_flush { }
and used via Datadog::Pipeline.process!
.
Some downsides:
- It is not possible to "reset" the state of the pipeline (once its modified, its permanent until application restart.)
- Its state is effectively a global variable, which has negative consequences (particularly Ractors)
It would be better if:
- Pipeline was instantiated, rather than accessed through class methods. Perhaps middleware style?
Datadog::Pipeline.new do |p| # Custom processor: passed "traces", returns traces p.process HealthCheckTraceFilter # Shorthand for processing traces in aggregate # Return traces to be kept p.process { |traces| } # Shorthand for filtering each individual trace # Return truthy to keep, falsey to remove p.trace_filter { |trace| } # Shorthand for filtering each individual span # Return truthy to keep, falsey to remove p.span_filter { |span| } end
- Pipeline was managed by configuration e.g.
Datadog.configure do |c| c.pipeline do |p| p.process HealthCheckTraceFilter # More pipeline middleware here... end end
This would make it easier to rebuild and modify the pipeline in a controlled, non-ambiguous way.
kssmilik
Metadata
Metadata
Assignees
Labels
coreInvolves Datadog core librariesInvolves Datadog core librariesdev/refactorInvolves refactoring existing componentsInvolves refactoring existing componentsfeature-requestA request for a new feature or change to an existing oneA request for a new feature or change to an existing one