Processors overview
A processor sits between a source and a destination and shapes telemetry in flight — filtering noise, redacting sensitive fields, enriching records with infrastructure context, batching for efficiency, or restructuring payloads to match what your destination expects.
Use the Integrations catalog to discover processors by name, signal, or platform. The pages in this section are the field-level reference.
Groups in this section
| Group | What it does | Examples |
|---|---|---|
| Top-level files | Stateless utilities and parsers used across signals. | Batch, K8s attributes, Lookup, Masking, Parse JSON, Parse with regex, Resource detection, Log deduplication, Parse time logs, Set severity (logs), Set trace context (logs) |
| Filter processors | Drop or keep records based on conditions or severity. | By condition (logs / metrics / traces), By severity |
| Transform processors | Rewrite, add, copy, rename, or remove fields, including OTTL and CSV transforms and SecOps standardization. | OTTL Transform, Add fields, Copy fields, Rename fields, Replace fields, Delete fields, CSV transform, Google SecOps standardization |
Picking the right processor
- Filter early, transform late — Drop unwanted records as close to the source as possible to save downstream cost; reshape and enrich just before the destination so each fork can have its own shape.
- Use OTTL for non-trivial logic — When several add/copy/rename steps would chain together, the OTTL Transform processor is usually clearer.
- Mind ordering — Processors run in pipeline order. Batch is almost always last before a destination, and Resource detection is almost always first so later processors can reference the resource attributes it adds.
Related
- Integrations catalog — searchable view of every processor.
- Sources overview and Destinations overview — endpoints that processors sit between.