> 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-regex.md).
# Filter by Regex
The Filter by Regex processor includes or excludes log records based on whether a regular expression matches the log body or an attribute field. Exclude drops matching logs; Include keeps only matching logs and drops the rest.
### Supported Telemetry
| Metrics | Logs | Traces |
| ------- | ---- | ------ |
| | ✓ | |
### Configuration
| Parameter | Type | Required | Default | Description |
| --------- | ---------------------- | -------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Action | Enum: include, exclude | No | exclude | The action to take when the regex matches. Include retains matching logs and drops the rest. Exclude removes matching logs. |
| Regex | Code Block | Yes | *(empty)* | The regular expression that logs are evaluated against. |
| Match | Enum: Body, Attributes | No | Body | The type containing the field the regex is evaluated against. |
| Field | OTTL Field | No | *(empty)* | When Match is `Body`, the body field to evaluate. Use bracket notation for nested fields (e.g. `parent["child"]`). Leave empty to evaluate the entire body. |
| Field | OTTL Field | No | *(empty)* | When Match is `Attributes`, the attribute field to evaluate. Use bracket notation for nested fields (e.g. `parent["child"]`). Leave empty to evaluate the entire attributes map. |
{% hint style="info" %}
**Use case**
Use Filter by Regex for quick body or single-field regex filtering. For multi-field logic, comparisons across signal types, or OTTL conditions beyond a single regex, the [Filter by Condition](/integrations/processors/filter-by-condition.md) processor provides more expressive filtering.
{% endhint %}
### Examples
#### Exclude logs whose `path` ends in `ql`
This configuration drops any log whose body field `path` matches the regex `.+(?:ql)`, for example requests to a GraphQL endpoint.
```yaml
- name: action
value: exclude
- name: regex
value: '.+(?:ql)'
- name: field_type
value: Body
- name: body_field
value: path
```
#### Include only logs with a matching attribute
This configuration keeps only logs whose `http.target` attribute matches `^/api/`, dropping everything else.
```yaml
- name: action
value: include
- name: regex
value: '^/api/'
- name: field_type
value: Attributes
- name: attribute_field
value: http.target
```
### Configuration Tips
* Leave Field empty to evaluate the entire body or attributes map; set it to target a single field.
* The regex follows RE2 syntax. Anchor patterns (`^`, `$`) when you need a full-string match, since `IsMatch` succeeds on any substring match.
* Include keeps only matching logs and drops everything else, which is easy to over-apply. Verify the pattern against sample data before deploying with Include.
### Troubleshooting
#### No logs are filtered
Symptoms: matching logs still pass through unchanged.
Solutions:
1. Confirm Match is set to the correct type (Body vs Attributes) for where the field lives.
2. Verify the Field name and bracket notation match the actual record structure, or leave Field empty to evaluate the whole body or attributes map.
3. Check that the regex matches the data; recall that a bare pattern matches any substring.
#### Too many logs are dropped
Symptoms: more logs are removed than expected.
Solutions:
1. With Action set to Include, every non-matching log is dropped. Switch to Exclude if you intended to remove only the matches.
2. Anchor the regex (`^`, `$`) to avoid unintended substring matches.
### Standalone Processor
```yaml
apiVersion: bindplane.observiq.com/v1
kind: Processor
metadata:
name: filter-by-regex
spec:
type: google_filter_regex
parameters:
- name: action
value: exclude
- name: regex
value: '.+(?:ql)'
- name: field_type
value: Body
- name: body_field
value: path
```
### Related Resources
* [Filter Processor — OpenTelemetry Collector Contrib](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/filterprocessor/README.md)
#### Bindplane Resources
* [Filter by Condition](/integrations/processors/filter-by-condition.md)
* [Filter by Field](/integrations/processors/filter-by-field.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-regex.md?ask=&goal=
```
`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.