Description
openedon Nov 25, 2019
Extend light modules implemented in #12270 to support processors in their manifests. These processors could be used to modify the events before sending them to the outputs. This can be useful in many use cases where some extra enrichment or mapping would need to be done.
Processors would be defined like that in the manifest.yml
:
default: true
input:
module: prometheus
metricset: collector
defaults:
metrics_path: /_status/vars
processors:
- rename:
fields:
- from: prometheus.labels.instance
to: cockroachdb.instance
ignore_missing:true
And they would need to be executed before processors defined in the configuration.
Some insights on possible ways to implementing this:
When a new module is going to be created from a configuration (in metricbeat/mb/module/factory.go
), a runner is created from a new connector and a new wrapper. Light modules are instantiated in the wrapper, but processors are initialized in the new connector, so there is no way at the moment to add processors where the light modules are loaded.
There are some ways to approach the solution of this:
- Expose a way to add processors to the connector from the module factory, this way the connection would be created first, and it would expose something to add processors, this something would be passed to the module creator that could prepend its processors. This solution can add an artificial dependency between modules initialization and pipelines.
- Where we do all the overrides in
metricbeat/mb/lightmetricset.go
we could create a metricset wrapper that applies the processors to any event generated before reporting it. This may require to create a wrapper for each one of the reporter interfaces we have. This may also force to do normalization of events twice, as processors need to work on normalized events. - A variant of the previous point, that could be useful in other metricsets would be to add a
Transformer
interface, with aTransform(event)
method that can be implemented by metricsets, in the case of light metricsets with processors it could be implemented by a wrapper and would execute the processors for the given event. Metricsets implementing this interface would receive a different reporter inmetricSetWrapper.run()
, one that applies the transformations before actually sending the event to the output.