> 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-metric-name.md).
# Filter Metric Name
Filters metrics out of a pipeline by matching on the metric name. Choose whether matches are excluded (dropped) or included (kept while everything else is dropped), and whether names are matched exactly (strict) or by regular expression (regexp). Operates on metrics only.
### Supported Telemetry
| Metrics | Logs | Traces |
| ------- | ---- | ------ |
| ✓ | | |
### Configuration
**Metrics**
| Parameter | Type | Required | Default | Description |
| ---------- | ---------------------- | -------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Action | Enum: include, exclude | No | exclude | What to do with metrics that match. `exclude` drops matching metrics. `include` keeps matching metrics and drops everything that does not match. |
| Match Type | Enum: strict, regexp | No | strict | How names are compared. `strict` requires an exact metric-name match. `regexp` uses [re2](https://github.com/google/re2/wiki/Syntax) to match the metric name. |
| Metrics | Strings | Yes | *(empty)* | List of metric names to match against. With `regexp`, each entry is a re2 pattern. All matches are acted on per the Action. |
### Examples
#### Exclude host metrics by regular expression
Drop all metrics whose name begins with `system.network.` and any `k8s.node.` metric, leaving the rest of the pipeline untouched.
```yaml
apiVersion: bindplane.observiq.com/v1
kind: Processor
metadata:
name: filter-metric-name
spec:
type: filter_metric_name
parameters:
- name: action
value: exclude
- name: match_type
value: regexp
- name: metric_names
value:
- "system.network\\..*"
- "k8s.node\\..*"
```
#### Keep only specific metrics by exact name
Keep only the three named metrics and drop everything else from the pipeline.
```yaml
apiVersion: bindplane.observiq.com/v1
kind: Processor
metadata:
name: filter-metric-name
spec:
type: filter_metric_name
parameters:
- name: action
value: include
- name: match_type
value: strict
- name: metric_names
value:
- system.cpu.utilization
- system.memory.usage
- k8s.pod.memory.usage
```
### Configuration Tips
* `include` is an allow-list: any metric not listed is dropped. `exclude` is a deny-list: only listed metrics are dropped. Reach for `include` when you want to keep a small, known set, and `exclude` when you want to drop a few noisy metrics from an otherwise-complete stream.
* With `strict` match type each entry must be the full metric name. With `regexp` each entry is a re2 pattern; anchor patterns (for example `^system\.cpu\.`) when you want to avoid unintended partial matches.
* Strict matching is a simple set lookup and is effectively free. Regexp matching compiles and evaluates a pattern against every metric name flowing through the pipeline, so prefer strict matching, keep the pattern list short, and write specific patterns when filtering high-cardinality or high-throughput metric streams.
### Troubleshooting
#### Metrics are not being filtered
Symptoms: matching metrics still arrive at the destination.
Solutions:
1. Confirm the Action is what you intend. `exclude` drops matches, `include` drops everything that does *not* match.
2. With `strict` match type the metric name must match exactly, including casing and the full dotted name. Switch to `regexp` if you need pattern matching.
#### Too many metrics are being dropped
Symptoms: metrics you expected to keep are missing from the destination.
Solutions:
1. With `include`, every metric not in the list is dropped by design. Add the metrics you want to keep to the Metrics list, or switch to `exclude`.
2. With `regexp`, an unanchored pattern can match more names than intended. Anchor the pattern (for example `^k8s\.node\.`) and test it against the actual metric names.
#### Regular expression matches nothing
Symptoms: a `regexp` filter has no effect.
Solutions:
1. Bindplane uses [re2](https://github.com/google/re2/wiki/Syntax) syntax, which does not support lookahead or backreferences. Rewrite unsupported constructs.
2. Remember that `.` matches any character. Escape literal dots in metric names (`system\.cpu\.utilization`) so the pattern matches only the intended names.
### Standalone Processor
```yaml
apiVersion: bindplane.observiq.com/v1
kind: Processor
metadata:
name: filter-metric-name
spec:
type: filter_metric_name
parameters:
- name: action
value: exclude
- name: match_type
value: regexp
- name: metric_names
value:
- "system.network\\..*"
- "k8s.node\\..*"
```
### Related Resources
* [Filter Processor — OpenTelemetry Collector Contrib reference](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/filterprocessor/README.md)
* [re2 regular-expression syntax](https://github.com/google/re2/wiki/Syntax)
---
# 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-metric-name.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.