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

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 configuration. The top-level resource key is the processor type.

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

Inject a filter processor

Drop spans below a latency threshold by pasting a filter processor configuration. Select only the Traces signal for this instance, since the OTTL paths below are span-specific.

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 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.
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

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
• OpenTelemetry Collector Contrib processors