OTLP pipelines.
Sample, redact, and derive metrics from your OTLP stream before it ever lands in storage.
What a pipeline is
A pipeline is an ordered list of transforms applied to OTLP records as they arrive at the ingest edge. Pipelines run before storage, which means anything you drop or rewrite at this layer never touches your bill, your retention floor, or your downstream queries.
Transform reference
Pipeline file layout
A typical workspace keeps one pipeline per service-environment pair, with
shared rules pulled into a _lib/ folder.
▸▸meridian-config/
▸▸pipelines/
- ·api-prod.toml
- ·api-staging.toml
- ·checkout-prod.toml
▸▸_lib/
- ·redact-pii.toml
- ·sample-defaults.toml
- ·workspace.toml
When pipelines aren’t enough
You need to enrich with external data
Pipelines run at the edge with no network egress. If you need to look up a customer tier or join against a feature flag, do it at the application layer and emit the result as a span attribute — then a pipeline rule can route on it.
You need conditional sampling per user
The sample transform takes a seed parameter. Set it to a user-stable
attribute and the same user’s traces will be kept or dropped consistently
across the whole window.
You need to drop spans, not whole traces
Use the prune transform with a span-level where clause. Beware: pruning
spans inside a kept trace breaks the parent-child chain and will show as
gaps in the waterfall view.
Cost tip. Most teams over-collect debug logs by 50–100×. A single
match = "level = 'debug'" → sample { rate = 0.01 }rule typically pays for the workspace inside the first week.