1. Building a pipeline #
The heart of Bindplane.
The three building blocks #
| Block | Examples | Advice |
|---|---|---|
| Sources | File, Journald, Syslog, Windows Events, OTLP, Kubernetes, Prometheus, databases, AWS, Azure, GCP | One source per data type, labels and attributes right at the input |
| Processors | Parse JSON/Regex/CSV, Severity Filter, Filter by condition, Deduplicate, Sampling, Mask Sensitive Data, Add Fields, Batch | Filter early, enrich just before the destination that needs it |
| Destinations | OTLP, Splunk HEC, Elasticsearch, Google SecOps, Datadog, Grafana Cloud, Amazon S3, Google Cloud Storage | A reusable destination (shared resource) across configurations |
Sources, processors and destinations can be created as reusable resources: changing a shared destination (a URL, a token) updates every configuration that uses it, at its next rollout.
Platform and role #
A configuration targets a platform (Linux, Windows, macOS, Kubernetes Node/Cluster/Gateway, OpenShift) and a role (Edge or Gateway). The sources offered depend on the platform: Journald does not exist for Windows, nor Windows Events for Linux.
2. Seeing what flows through: snapshots #
Debugging without guessing.
Snapshots #
A snapshot shows a sample of the real records going through a collector, at the input or output of a processor. It is the visual equivalent of the debug exporter, without redeploying.
- Check that parsing produces the expected fields (
http.status_code,user.id). - Make sure masking is applied before the destination.
- Measure the effect of a filter: throughput before and after each processor is shown on the pipeline.
Good practice: Before adding a processor, take a snapshot of the source: you write a parsing or filtering rule much faster with the real records in front of you.
3. Versions and rollback #
Changing without risk.
Lifecycle #
- Every change creates a draft version: collectors keep running the live version.
- Before the rollout, compare the draft with the live version, or discard it.
- Rollback is done with Roll forward to this version in the history: Bindplane creates a new version that copies the old one (v5 rolled to v3 becomes v6 with v3's content). History is never rewritten.
- Before this rollback, Bindplane checks that the sources, processors and destinations of the old version still exist.
Common mistake: Deleting a shared destination blocks rollback to the versions that used it: disable it or remove it from configurations rather than deleting it.
