Skip to main content
A data processor is a pure function (data) => data that runs on every attribute object the package emits. They’re the right place to redact, hash, allow-list, or enrich attributes site-wide.

Signature

You configure them on TelemetryConfig.dataProcessors:
Processors run in order. Each receives the output of the previous one.

What gets processed

Every call to:
  • startActiveSpan(name, attributes, fn)
  • getHistogram(...)(value, attributes)
  • getIncrementCounter(...)(value, attributes)
…runs its attributes through every processor before recording. The session id (mcp.session.id) is merged in before processors run, so processors see it and can override or remove it.

Common recipes

Add deployment metadata

Redact specific keys

Hash user identifiers

Drop attributes by pattern

Calling processors directly

You can run the configured chain manually for one-off uses:
This is useful when you’re building your own log lines and want them to share the same redaction logic as your spans.

Order matters

A common bug: redact-then-add ordering. If you add deployment env after you redact, the env keys are not redacted (which is usually fine but worth being deliberate about).

Performance

Processors run on the hot path of every span and metric record. Keep them:
  • Pure — no I/O, no awaits.
  • Fast — use precompiled regexes, avoid full string clones when nothing needs replacing.
  • Allocation-light — return the same object when nothing changed.

Next

PII sanitization

A more focused recipe for the common case.

Custom spans & metrics

Where processors fit in your custom code.