As we describe features and concepts, it helps to have a mental model of Cribl LogStream as a system that receives events from various sources, processes them, and then sends them to one or more destinations.
Let's zoom in on the center of the above diagram, to take a closer look at the processing and transformation options that LogStream provides internally. The basic interface concepts to work with are Routes, which manage data flowing through Pipelines, which consist of Functions.
Routes evaluate incoming events against filter expressions to find the appropriate Pipeline to send them to. Routes are evaluated in order. A Route can be associated with only one Pipeline and one output. By default, a Route-Pipeline-Output tuple will consume matching events.
If the Route's
Final flag is disabled, one or more event clones are sent down the associated Pipeline, while the original event continues down the rest of the Routes. This is very useful in cases where the same set of events needs to be processed in multiple ways and delivered to different destinations. For more details, see Routes.
A series of Functions is called a Pipeline, and the order in which the Functions are executed matters. Events are delivered to the beginning of a pipeline by a Route, and as they're processed by a Function, the events are passed to the next Function down the line.
Pipelines attached to Routes are called processing Pipelines. You can optionally attach pre-processing Pipelines to individual LogStream Sources, and attach post-processing Pipelines to LogStream Destinations. All Pipelines are configured through the same UI; these three designations are determined only by their placement in LogStream's data flow.
Events only move forward – toward the end of a Pipeline, and eventually out of the system. For more details, see Pipelines.
At its core, a Function is a piece of code that executes on an event, and that encapsulates the smallest amount of processing that can happen to that event. For instance, a very simple Function can be one that replaces the term
bar on each event. Another one can hash or encrypt
bar. Yet another function can add a field – say,
dc=jfk-42 – to any event with
Functions process each event that passes through them. To help improve performance, Functions can optionally be configured with filters, to limit their processing scope to matching events only. For more details, see Functions.
You can scale LogStream up to meet enterprise needs in a distributed deployment. Here, multiple LogStream Workers (instances) share the processing load. But as you can see in the preview schematic below, even complex deployments follow the same basic model outlined above.
Updated about a month ago