> 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/custom.md).

# Custom

Insert an arbitrary OpenTelemetry processor configuration into a pipeline by pasting its YAML. Use it to run any processor included in the Bindplane Distro for OpenTelemetry Collector that Bindplane does not yet expose as a dedicated processor type. It can act on logs, metrics, and traces; you choose which signals each instance applies to.

### Supported Telemetry Types

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

The Custom processor supports all telemetry types. It is up to you to enable only the signals the pasted processor actually supports, and to paste a configuration that is valid for the collector running it.

### Configuration

#### Basic Configuration

<figure><img src="/files/oXuv15qJxhmvdJOaOeuD" alt="Bindplane docs - Custom - image 1"><figcaption></figcaption></figure>

**Parameters**

| Parameter             | Type               | Required | Default                 | Description                                                                                                                         |
| --------------------- | ------------------ | -------- | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| Choose Telemetry Type | Telemetry Selector | No       | `Logs, Metrics, Traces` | The signals this instance applies the pasted processor to. Deselect any signal the pasted processor does not support.               |
| Configuration         | YAML               | Yes      | *(empty)*               | The YAML configuration for the processor, keyed by the processor's type. Bindplane inserts it verbatim into the selected pipelines. |

The `Configuration` value is a single processor entry: the top-level key is the processor type, and its body is that processor's settings. Do not wrap it in a `processors:` block or add a pipeline reference; Bindplane handles wiring it into each selected pipeline.

### Examples

#### Inject a resource processor

Add a static resource attribute by pasting a [resource processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/resourceprocessor) configuration. The top-level `resource` key is the processor type.

```yaml
resource:
  attributes:
    - action: upsert
      key: custom
      value: true
```

#### Inject a filter processor

Drop spans below a latency threshold by pasting a [filter processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/filterprocessor) configuration. Select only the `Traces` signal for this instance, since the OTTL paths below are span-specific.

```yaml
filter:
  error_mode: ignore
  traces:
    span:
      - 'attributes["http.route"] == "/health"'
```

### Configuration Tips

* The top-level key in `Configuration` must be a valid processor type built into the collector running it. See the [supported processors list](https://github.com/observIQ/bindplane-otel-collector/blob/main/docs/processors.md) for what the Bindplane Distro for OpenTelemetry Collector includes.
* Match `Choose Telemetry Type` to what the pasted processor supports. A processor that only operates on traces should run on a Custom instance with only `Traces` selected, otherwise the collector may fail to start when the processor is wired into a logs or metrics pipeline.
* The pasted configuration is not validated by the Bindplane UI. Validation happens when the collector loads the rendered configuration, so a typo surfaces as a collector startup error rather than a UI error.
* Where a dedicated Bindplane processor exists for your use case (filter, transform, batch, and similar), prefer it. The dedicated types provide form-based fields, validation, and version-managed defaults that the Custom processor does not.

### Troubleshooting

#### The collector fails to start after adding the processor

Symptoms: the collector reports an unknown processor type, a YAML parse error, or an invalid-config error on startup.

Solutions:

1. Confirm the top-level key is a processor type included in the running collector. Check it against the [supported processors list](https://github.com/observIQ/bindplane-otel-collector/blob/main/docs/processors.md).
2. Verify the pasted YAML is a single processor entry keyed by type, not wrapped in a `processors:` block and not indented as if it were already inside one.
3. Check the indentation. The value is inserted verbatim, so inconsistent indentation produces a parse error in the rendered collector configuration.

#### The processor has no effect on telemetry

Symptoms: the collector starts cleanly but the data is unchanged.

Solutions:

1. Confirm `Choose Telemetry Type` includes the signal you expect the processor to act on. A processor only runs on the signals selected for that instance.
2. Verify the pasted processor's own conditions or matchers (OTTL paths, attribute keys, match expressions) actually match your records.

#### A processor that works for one signal errors on another

Symptoms: the collector starts when only one signal is selected but fails when others are added.

Solution: Many processors support only specific signal types or use signal-specific paths. Deselect the unsupported signals in `Choose Telemetry Type`, or split the configuration across multiple Custom instances, one per signal.

### Standalone Processor

```yaml
apiVersion: bindplane.observiq.com/v1
kind: Processor
metadata:
  name: custom
spec:
  type: custom
  parameters:
    - name: telemetry_types
      value:
        - Logs
        - Metrics
        - Traces
    - name: configuration
      value: |
        resource:
          attributes:
            - action: upsert
              key: custom
              value: true
```

### Related Resources

* [Bindplane Distro for OpenTelemetry Collector — supported processors](https://github.com/observIQ/bindplane-otel-collector/blob/main/docs/processors.md)
* [OpenTelemetry Collector Contrib processors](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor)


---

# 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/custom.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.