Add filterprocessor to processors in your Collector config; set error_mode: ignore so a malformed condition does not halt the pipeline
Under the signal section (traces, metrics, or logs), add a span/datapoint/log_record block with a conditions list; any record matching at least one condition is dropped
Write conditions using OTTL syntax, for example: attributes["http.route"] == "/healthz" to drop health-check spans, or severity_number < SEVERITY_NUMBER_WARN to drop below-warning logs
Combine predicates with and / or inside a single condition string; use parentheses for grouping when mixing operators
For metrics, use metric.name or resource.attributes to drop entire metric families or per-resource streams; the datapoint block can filter individual data points within a metric
Validate dropped volumes by watching the otelcol_processor_dropped_* internal metrics (exposed on port 8888 by default) after deploying the filter processor
Known gotchas
Conditions are OR-ed: a record is dropped if any single condition matches; to require multiple criteria simultaneously, combine them with and inside one condition string
The filter processor drops matching records entirely and permanently—place it after enrichment processors so you can filter on enriched attributes, but before the batch processor to avoid batching data you will immediately discard
Dropping spans without dropping associated metrics can create orphaned RED metrics (requests with no matching trace); consider filtering at the same cardinality boundary across signals
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp