> For the complete documentation index, see [llms.txt](https://docs.bindplane.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bindplane.com/integrations/processors/filter-by-condition.md).

# Filter by Condition

Filters logs, metrics, or traces by an OTTL condition. When the condition matches a record, the processor either drops it or keeps it (dropping everything else), depending on the chosen action. Records that do not match are passed through unchanged.

### Supported Telemetry

| Metrics | Logs | Traces |
| ------- | ---- | ------ |
| ✓       | ✓    | ✓      |

### Configuration

<figure><img src="/files/oKl0VQTE50uXkoprSGmB" alt="Bindplane docs - Filter by Condition - image 1"><figcaption></figcaption></figure>

**Filter**

| Parameter             | Type                   | Required | Default   | Description                                                                                                                                  |
| --------------------- | ---------------------- | -------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| Choose Telemetry Type | Telemetry Selector     | No       | *(empty)* | The signal types this instance filters: Logs, Metrics, Traces. Select one or more.                                                           |
| Action                | Enum: include, exclude | No       | exclude   | What to do when the condition matches. **Exclude** drops matching telemetry. **Include** keeps matching telemetry and drops everything else. |
| Condition             | OTTL Condition         | Yes      | *(empty)* | The OTTL boolean condition evaluated against each record.                                                                                    |

The condition is evaluated per record in the selected signal's context: per log record for Logs, per data point for Metrics, and per span for Traces.

### Examples

#### Drop debug logs

Exclude (drop) log records whose severity is below `INFO`, keeping everything else.

```yaml
apiVersion: bindplane.observiq.com/v1
kind: Processor
metadata:
  name: drop-debug-logs
spec:
  type: filter-by-condition
  parameters:
    - name: telemetry_types
      value:
        - Logs
    - name: action
      value: exclude
    - name: condition
      value:
        ottl: severity_number < SEVERITY_NUMBER_INFO
```

#### Keep only production spans

Include (keep) only spans whose `deployment.environment` resource attribute equals `production`. All other spans are dropped.

```yaml
apiVersion: bindplane.observiq.com/v1
kind: Processor
metadata:
  name: keep-prod-spans
spec:
  type: filter-by-condition
  parameters:
    - name: telemetry_types
      value:
        - Traces
    - name: action
      value: include
    - name: condition
      value:
        ottl: resource.attributes["deployment.environment"] == "production"
```

#### Advanced OTTL conditions

The Condition accepts any OTTL boolean expression valid for the selected signal's context. Combine clauses with `and` / `or`, negate with `not`, and use OTTL converter functions.

Drop high-cardinality metric data points by name pattern and attribute:

```yaml
    - name: telemetry_types
      value:
        - Metrics
    - name: action
      value: exclude
    - name: condition
      value:
        ottl: IsMatch(metric.name, "^node_.*_bytes$") and attributes["device"] == "loopback"
```

Drop spans for noisy health-check endpoints across multiple paths:

```yaml
    - name: telemetry_types
      value:
        - Traces
    - name: action
      value: exclude
    - name: condition
      value:
        ottl: attributes["http.route"] == "/healthz" or attributes["http.route"] == "/readyz"
```

Keep only error or slow logs (a guarded clause avoids errors when a field is absent):

```yaml
    - name: telemetry_types
      value:
        - Logs
    - name: action
      value: include
    - name: condition
      value:
        ottl: severity_number >= SEVERITY_NUMBER_ERROR or (attributes["duration_ms"] != nil and attributes["duration_ms"] > 1000)
```

### Configuration Tips

* **Include vs. exclude.** Exclude drops only the records that match. Include is the inverse: it keeps matches and drops everything else. Use exclude to remove specific noise, include to whitelist a narrow subset.
* **One condition per instance.** A single condition is applied to every selected signal. To filter different signals with different logic, add a separate Filter by Condition instance per signal.
* **Guard optional fields.** Reference attributes that may be absent with a `field != nil` guard (for example `attributes["x"] != nil and attributes["x"] == "y"`) so the condition does not error on records that lack the field.

### Troubleshooting

#### Nothing is being filtered

Symptoms: telemetry passes through unchanged after the processor is added.

Solutions:

1. Confirm the **Choose Telemetry Type** includes the signal you are sending. The condition only runs against the selected signals.
2. Verify the OTTL paths match the record's actual context (for example `body[...]` for log bodies, `resource.attributes[...]` for resource attributes, `attributes[...]` for record attributes).
3. Check whether the Action is the one you intend. With **Include**, non-matching records are the ones that get dropped.

#### Too much telemetry is dropped

Symptoms: records you wanted to keep disappear.

Solutions:

1. With **Include**, remember everything that does *not* match the condition is dropped. Broaden the condition or switch to **Exclude**.
2. Test the condition logic with `and` / `or` precedence in mind; wrap grouped clauses in parentheses.

#### Records with missing fields are filtered unexpectedly

Symptoms: records that lack a referenced attribute behave inconsistently.

Solutions:

1. The underlying filter processor runs with `error_mode: ignore`, so a record that errors during evaluation is not filtered. Add a `!= nil` guard to make absent-field behavior explicit.

### Standalone Processor

```yaml
apiVersion: bindplane.observiq.com/v1
kind: Processor
metadata:
  name: filter-by-condition
spec:
  type: filter-by-condition
  parameters:
    - name: telemetry_types
      value:
        - Logs
    - name: action
      value: exclude
    - name: condition
      value:
        ottl: resource.attributes["host.name"] == "dev-server" and attributes["environment"] == "dev" and body["remote-ip"] == "127.0.0.1"
```

### Related Resources

* [Filter Processor — OpenTelemetry Collector Contrib](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/filterprocessor)
* [OpenTelemetry Transformation Language (OTTL)](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/ottl/README.md)
* [Filter by Field](/integrations/processors/filter-by-field.md)
* [Filter by Regex](/integrations/processors/filter-by-regex.md)
* [Filter by Severity](/integrations/processors/filter-severity.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.bindplane.com/integrations/processors/filter-by-condition.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.