Before incoming events are transformed by a processing pipeline, Cribl uses a set of filters to first select a subset to deliver to the correct pipeline. This process is done via routes.
Routes apply filter expressions on incoming events to send matching results to the appropriate pipeline . Filters are JS-syntax compatible expressions, e.g.,
source=='foo.log' && fieldA=='bar',
true, etc. that are configured with each route. There can be multiple routes in the system but a route can only be associated with one pipeline.
Routes are evaluated in order, top down.
In this example, incoming events will be evaluated against the route named Route first, then Sensitive Data, then Logs to Metrics and so on. At the end, the Main route serves as a catch-all for any event that does not match any of the other routes. If a route needs to be applied before another, simply drag it on top of it. In addition, you can turn routes On/Off inline as necessary.
Routes can be configured with an output destination which denotes where to send events after they're processed by the pipeline. This destination overrides the one set at the pipeline level.
An event that enters the system and matches a route-pipeline pair in most cases it will either be dropped by a function or optionally transformed and exit the system. This is ensured by the
final toggle in route settings. It defaults to
Yes and means that matched events will be consumed by that route and not evaluated against any other routes that sit below it.
If the toggle is set to
No, clone(s) of the matching events are processed by the configured pipeline and the original events are allowed to continue their trip downstream to be evaluated and/or processed by other route-pipeline pairs.
This is very useful in cases where the same set of events needs to be processed differently and delivered to different destinations. Each clone can be decorated with KV pairs as necessary.
Depending on your cloning needs you may want to follow a most specific first or most general first processing strategy. The general goal is to minimize the number of filters/routes an event gets evaluated against. For example:
- If cloning is not needed at all (i.e. all
finaltoggles at default), then it makes sense to start with the broadest expression at the top so as to consume as many events as early as possible.
- If cloning is needed on a narrow set of events, then it may make sense to do that upfront and follow it with a route that consumes those clones immediately after.