Crib LogStream - Docs

Getting started with Cribl LogStream

Questions? We'd love to help you! Meet us in #cribl (sign up)
Download manual as PDF - v2.1

    Docs Home


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

Output Destination

Routes can be configured with an output destination which denotes where to send events after they're processed by the pipeline.

The Final Toggle

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.

Final Flag and Cloning Considerations

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

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 list of routes and they are a UI artifact only - i.e. while in a group routes maintain their global position order.

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 first match being the winner.

Updated about a month ago


Suggested Edits are limited on API Reference Pages

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