Preview a processor chain

Every pipeline is a linear chain of processors, and a chain can misbehave in ways that aren’t obvious from the config: a regex that matches too much, two steps that fight over the same field, a filter that drops everything. The preview workspace — the dry-run panel in the chain editor — runs the whole chain against a sample you control and shows you what comes out, step by step, before the pipeline ever touches live telemetry.

This page is a tour of the workspace itself: its two layouts, the sample-data controls, and how to read the result. For an end-to-end build that uses it in passing, see Build your first pipeline.

Note

The preview runs entirely in the server against the sample you provide. It never reads from a live source and never sends anything to a destination — it’s a pure what-if. Nothing you do here changes a running collector until you save the pipeline and a route references it.

Open the workspace

Open a pipeline in Process → Pipelines (or start a new one). The dry-run panel lives in the chain editor alongside the Processor Chain. It starts collapsed as a drawer under the chain — the Sample Data — dry-run this chain bar at the bottom of the editor.

The chain editor with the preview drawer collapsed. Build the Processor Chain in the main column; the 'Sample Data — dry-run this chain' bar at the bottom expands the workspace when you're ready to test.

Two layouts: docked-below or split-right

The workspace toggles between two positions so it fits how you’re working:

• Split-right — the sample panel sits to the right of the chain, so you see the processor list and the preview side by side. Best while you’re iterating on steps: change a processor, re-run, read the result without scrolling.
• Dock below — the panel collapses to a full-width drawer under the chain. Best when the chain is long, or when you want the full editor width for a step’s config.

The Dock below button in the panel header flips between the two.

The split-right layout. Pick a signal and format, seed a sample from a template or paste your own, and Run. Keeping the panel beside the chain means each edit-and-run round-trip stays in view.

Choose a signal and format

Two selectors at the top of the panel decide how your sample is parsed:

• Signal — logs, metrics, or traces. This must match the signal the chain processes; a logs chain run against a metrics sample won’t do anything useful.
• Format — how the sample is written. OTLP JSON is the canonical OpenTelemetry envelope. Log chains can also take raw syslog, which the workspace parses into log records the way a real syslog receiver would — so you can paste a line straight off a device and see how the chain treats it.

Seed a sample, or paste your own

You rarely want to hand-write an OTLP envelope. The template buttons — Insert logs template, metrics, traces, raw syslog — drop a valid, minimal sample into the editor so you only have to edit the part you care about (usually a log body or an attribute value). Or paste a real sample: an OTLP-JSON payload you captured, or a raw syslog line.

Tip

Pair this with live capture. Capture a handful of real records off the source the pipeline will run against, paste one into the preview, and you’re testing the chain against production-shaped data instead of a synthetic guess.

Run and read the result

Click Run. The workspace executes the chain top-to-bottom — each step receives the previous step’s output — and reports:

• A summary line: how many steps ran and the total time (e.g. 1 step · 3ms total). A chain that takes milliseconds on a representative sample won’t be your bottleneck in production.
• A per-step row for each processor: its index, name, an OK / error badge, and the time that step took. A step that errors stops the chain there and tells you which one and why — you’re not left guessing which of five processors rejected the record.
• The Final output: the OTLP envelope as it leaves the last step. This is exactly what a downstream destination would receive.

A completed run. The summary shows the step count and total time, each step carries an OK/error badge and its own timing, and Final output holds the envelope as it leaves the chain — the redacted body here confirms the transform did its job.

Expand a step row (the caret on the left) to see that step’s before and after in isolation — the record as it arrived and as it left. In a multi-step chain this is how you localise a bug: instead of diffing the whole chain’s input against its output, you walk the record step by step and find the exact processor that did the wrong thing.

Iterate

The workflow that makes the preview worth keeping open:

1. Paste (or template) a sample once.

2. Change a processor — tweak a regex, reorder two steps, adjust a filter condition.

3. Run again. Read the Final output and, if it’s wrong, expand the step rows until you find the one that diverged.

4. Repeat until the output is exactly what you want — then save the pipeline.

Because the sample stays put between runs, each round-trip is just a click of Run and a glance at the output. You verify every change against the same known input, so a regression the moment you introduce it — not after it’s live on a collector.

What’s next

• Build your first pipeline — the end-to-end walkthrough this workspace supports, from empty chain to a live route.
• Concepts: Pipeline — the model behind the chain: input/output schemas, per-step evaluation, and parameter overrides.
• Capture live samples — pull real records off a source to feed the preview instead of synthetic data.
• Mask PII and Drop noisy logs — transform and filter recipes worth previewing before you ship them.