Clean logs before they
become stored noise.

What it is

Data Shaper is an ingest-time processing stage that runs inside Telemtra. As log records arrive at the ingest endpoint, enabled rules transform them before they are written to storage. It is logs-only today, and you manage it entirely from the app at /data-shaper - no YAML and no collector restart.

Because rules run at ingest, they reduce stored volume and remove sensitive data the moment it lands, so you control cost and exposure without touching every service or collector that sends data.

How a rule works

Each rule is evaluated in three steps, in order:

1. Scope - first-class service, environment, and host matching decides whether a log is even a candidate.
2. Conditions - structured field conditions on the matched logs decide whether the rule fires.
3. Actions - the transformations applied to logs that match.

Rules are versioned and can be enabled or disabled independently. A disabled rule still exists and can be previewed, so you can stage a change safely before it affects live ingest.

First-class scope

Service, environment, and host are matched as first-class scope before any field conditions run. This keeps operational scope (which workload, which environment, which machine) separate from structured log matching, so a rule for one noisy service never accidentally reshapes another.

Actions

A matching rule can apply any of these actions:

• Drop log - discard the record entirely so it is never stored or counted against retention.
• Rewrite severity - normalize the severity of known structured events.
• Set service, set environment, set host - correct or normalize first-class identity fields.
• Add attribute, rename attribute, remove attribute - reshape structured fields.
• Mask field - redact a sensitive structured field value.
• Mask body by regex - redact tokens, passwords, and secrets inside the log body.

Preview and rollout

Data Shaper is built for safe, observable changes:

• Preview a rule against recent logs to see exactly what it would drop or change before enabling it.
• Enable / disable a rule at any time without deleting it.
• Version history tracks every change to a rule.
• Daily counters show how many records each rule matched, so you can confirm it is working after enabling it.
• Audit events record who changed what, for owner/admin review.

The recommended flow is: create the rule disabled, preview it against recent logs, enable it, then watch the daily counters change as matching logs are ingested.

Plans and limits

Data Shaper is visible on every plan so you can build and preview rules. Active processing is gated by quota: the number of rules that can be enabled at once scales with your billing plan. See pricing for the active rule limit per plan.

Common uses

• Drop noisy health checks and readiness probes.
• Mask tokens, passwords, and secrets in log bodies before storage.
• Redact PII in structured fields like email or account identifiers.
• Rewrite severity for known structured events so alerts stay meaningful.
• Normalize inconsistent service, environment, or host names from older deployments.

Data Shaper vs the Collector

You can drop and mask data at the OpenTelemetry Collector too, using processors. The difference is where the control lives:

• Collector processing happens in your infrastructure, before data leaves your network. Best for data you never want to transmit, but it requires editing config and redeploying collectors.
• Data Shaper happens at Telemtra ingest, controlled from the app. Best for fast iteration, previewing impact, and applying rules across many senders without redeploying anything.

Many teams use both: strip the most sensitive data at the Collector, then iterate on noise and normalization with Data Shaper.