Before incoming events are transformed by a processing Pipeline, Cribl LogStream uses a set of filters to first select a subset of events to deliver to the correct Pipeline. This selection is made via Routes.
source=='foo.log' && fieldA=='bar',
true, etc.) that are configured with each Route.
There can be multiple Routes in the system, but each Route can be associated with only one Pipeline.
Routes are evaluated in their display order, top‑>down. The stats shown in the Bytes/Events (toggle) column are for the most-recent 15 minutes.
In this example, incoming events will be evaluated first against the Route named speedtest, then against mtr, then against statsd, 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.
When you condense the Routes page to a narrower viewport, LogStream consolidates the In/Out/Dropped selectors onto an expanded Bytes/Events drop-down menu, as shown below.
To apply a Route before another, simply drag it vertically. Use the sliders to turn Routes On/Off inline, as necessary, to facilitate development and debugging.
In the screenshot above, note the selectors to toggle between displaying Events versus Bytes, and to display In versus Out.
You can press the
] (right-bracket) shortcut key to toggle between the Preview pane and the expanded Routes display shown above. (This works when no field has focus.)
Routes can be configured with an output Destination that denotes where to send events after they're processed by the Pipeline.
When an event that enters the system and matches a route-pipeline pair, usually it will either be:
- Dropped by a function, or
- Transformed (optionally) and exit the system.
This behavior is ensured by the
Final toggle in Route settings. It defaults to
Yes, meaning that matched events will be consumed by that Route, and will not be evaluated against any other Routes that sit below it.
Final toggle is set to
No, clone(s) of the matching events will be processed by the configured Pipeline, and the original events will be allowed to continue their trip 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 key-value pairs as necessary.
Depending on your cloning needs, you might 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 stay 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 might make sense to do that upfront, and follow it with a Route that consumes those clones immediately after.
A Route group is a collection of consecutive Routes that can be moved up and down the Route stack together. Groups help with managing long lists of Routes. They are a UI visualization only: While Routes are in a group, those Routes maintain their global position order.
Route groups work much like Function groups.
Output Routers are another way to route data. They are meta-destinations, in that they allow actual Destination selection based on rules. Rules are evaluated in order, top‑>down, with the first match being the winner.
Updated 9 days ago