# Routing

#### Description

This connector routes logs, metrics, or traces to different pipeline paths based on OTTL conditions. Telemetry is evaluated against each route in order and sent to the first matching route. If no condition matches, telemetry flows to the last route without a condition (acting as a default).

#### Use

Use this connector to:

* Split telemetry by environment, region, tenant, or any resource/record attribute
* Send different severity levels to different destinations (e.g., errors to a dedicated store, debug logs to cheap storage)
* Route specific services or namespaces to specialized processing pipelines
* Fan out telemetry to multiple destinations based on content

#### Supported Types

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

Each selected input type is routed independently. For example, selecting Logs and Traces creates separate routing tables for each.

#### Configuration

| Field           | Description                                                                                            |
| --------------- | ------------------------------------------------------------------------------------------------------ |
| Telemetry Types | Select which signal types to route: **Logs**, **Metrics**, **Traces**. Multiple types can be selected. |
| Routes          | An ordered list of routes. Each route can have an optional OTTL condition. See route fields below.     |

**Route Fields**

| Field     | Description                                                                                                                                      |
| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| Condition | An OTTL condition that determines whether telemetry matches this route. If omitted, the route matches all remaining telemetry (acts as default). |

Routes are evaluated in order. Telemetry is sent to the **first** route whose condition matches. A route without a condition should be placed last to catch all unmatched telemetry.

**OTTL Condition Context**

Conditions are automatically evaluated in the appropriate context for each telemetry type:

| Telemetry Type | Context     |
| -------------- | ----------- |
| Logs           | `log`       |
| Metrics        | `datapoint` |
| Traces         | `span`      |

Resource-level attributes are accessible in all contexts using `resource.attributes["key"]`.

#### Example Configurations

**Route Logs by Severity**

Send error logs to one destination and everything else to another.

* Telemetry Types: `Logs`
* Route 1 Condition: `severity_number >= SEVERITY_NUMBER_ERROR`
* Route 2: *(no condition — catches all remaining logs)*

<figure><img src="https://1405008107-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgmiOMzBfoNFwmKJFHMcJ%2Fuploads%2FJ5TVLY0BzA864N5vBxd1%2Fimage.png?alt=media&#x26;token=d7caec29-e53c-4970-87a9-f70916022d3e" alt=""><figcaption></figcaption></figure>

**Route Traces by Environment**

Separate production and non-production traces.

* Telemetry Types: `Traces`
* Route 1 Condition: `resource.attributes["deployment.environment"] == "production"`
* Route 2: *(no condition — catches all remaining traces)*

<figure><img src="https://1405008107-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgmiOMzBfoNFwmKJFHMcJ%2Fuploads%2FRAEbeEivRr9bmvKCWKd2%2Fimage.png?alt=media&#x26;token=4556c8b6-8201-412f-a89b-1773107c7c0c" alt=""><figcaption></figcaption></figure>

**Route Metrics by Service Name**

Send metrics from specific services to dedicated pipelines.

* Telemetry Types: `Metrics`
* Route 1 Condition: `resource.attributes["service.name"] == "checkout-service"`
* Route 2 Condition: `resource.attributes["service.name"] == "payment-service"`
* Route 3: *(no condition — catches all remaining metrics)*

<figure><img src="https://1405008107-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgmiOMzBfoNFwmKJFHMcJ%2Fuploads%2FIqVNdAjX8y8QlAhrwPTc%2Fimage.png?alt=media&#x26;token=70843e98-16ff-44a6-b77f-571c9d7c0ec0" alt=""><figcaption></figcaption></figure>

**Route Logs by Namespace**

Split Kubernetes logs by namespace for team-based routing.

* Telemetry Types: `Logs`
* Route 1 Condition: `resource.attributes["k8s.namespace.name"] == "frontend"`
* Route 2 Condition: `resource.attributes["k8s.namespace.name"] == "backend"`
* Route 3: *(no condition — catches all remaining logs)*

<figure><img src="https://1405008107-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgmiOMzBfoNFwmKJFHMcJ%2Fuploads%2F7tQCYxlgUO3NgQ76XhGy%2Fimage.png?alt=media&#x26;token=fb7b3b43-61f1-4de8-91f6-a74e13198e87" alt=""><figcaption></figcaption></figure>

#### Technical Notes

* Errors in OTTL condition evaluation are silently ignored. Telemetry that fails condition evaluation will fall through to subsequent routes.
* Each route creates a separate sub-pipeline. Processors and destinations can be configured independently per route in the Bindplane pipeline editor.
* The routing connector requires Bindplane OTel Collector v1.69.0 or later.

#### Related Resources

* [OTTL Syntax Reference](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/ottl/README.md)
* [OTTL Functions](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/ottl/ottlfuncs/README.md)
* [OTel Routing Connector Documentation](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/connector/routingconnector/README.md)