Cribl LogStream – Docs

Cribl LogStream Documentation

Questions? We'd love to help you! Meet us in #Cribl Community Slack (sign up)
Download entire manual as PDF - v2.3.0

Routes

What Are Routes

Before incoming events are transformed by a processing Pipeline, Cribl LogStream uses a set of filters to first select a subset to deliver to the correct Pipeline. This process is done via Routes.

How Do Routes Work

Routes apply filter expressions on incoming events to send matching results to the appropriate Pipeline. Filters are JavaScript-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 each Route can be associated with only one Pipeline.

Routes are evaluated in their display order, top‑>down. The stats shown in the Events column are for the most-recent 15 minutes.

Routes and events

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.

Managing the Routes Page

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 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 as long as no field has focus.)

Output Destination

Routes can be configured with an output Destination that denotes where to send events after they're processed by the Pipeline.

The Final Toggle

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.

If the 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.

Final Flag and Cloning Considerations

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 Final toggles 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.

Route Groups

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.

Routing with Output Router

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 about 23 hours ago

Routes


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.