Routes logs, metrics or traces to specific exporters.

This processor will either read a header from the incoming HTTP request (gRPC or plain HTTP), or it will read a resource attribute, and direct the trace information to specific exporters based on the value read.

This processor does not let traces to continue through the pipeline and will emit a warning in case other processor(s) are defined after this one. Similarly, exporters defined as part of the pipeline are not authoritative: if you add an exporter to the pipeline, make sure you add it to this processor as well, otherwise it won't be used at all. All exporters defined as part of this processor must also be defined as part of the pipeline's exporters.

Given that this processor depends on information provided by the client via HTTP headers or resource attributes, caution must be taken when processors that aggregate data like batch or groupbytrace are used as part of the pipeline.

The following settings are required:

• from_attribute: contains the HTTP header name or the resource attribute name to look up the route's value. Only the OTLP exporter has been tested in connection with the OTLP gRPC Receiver, but any other gRPC receiver should work fine, as long as the client sends the specified HTTP header.
• table: the routing table for this processor.
• table.value: a possible value for the attribute specified under FromAttribute.
• table.exporters: the list of exporters to use when the value from the FromAttribute field matches this table item.

The following settings can be optionally configured:

• attribute_source defines where to look for the attribute in from_attribute. The allowed values are:
  • context (the default) - to search the context, which includes HTTP headers
  • resource - to search the resource attributes.
• drop_resource_routing_attribute - controls whether to remove the resource attribute used for routing. This is only relevant if AttributeSource is set to resource.
• default_exporters contains the list of exporters to use when a more specific record can't be found in the routing table.

Example:

processors:
  routing:
    from_attribute: X-Tenant
    default_exporters:
    - jaeger
    table:
    - value: acme
      exporters: [jaeger/acme]
exporters:
  jaeger:
    endpoint: localhost:14250
  jaeger/acme:
    endpoint: localhost:24250

Alternatively, it is possible to use subset of the OpenTelemetry Transformation Language (OTTL) expressions as routing conditions.

To configure the routing processor with OTTL routing conditions use the following options:

• table (required): the routing table for this processor.
• table.expression (required): the routing condition provided as the OTTL expression.
• table.exporters (required): the list of exporters to use when the routing condition is met.
• default_exporters (optional): contains the list of exporters to use when a record does not meet any of specified conditions.

processors:
  routing:
    default_exporters:
    - jaeger
    table:
      - expression: route() where resource.attributes["X-Tenant"] == "acme"
        exporters: [jaeger/acme]
      - expression: delete_key(resource.attributes, "X-Tenant") where IsMatch(resource.attributes["X-Tenant"], ".*corp") == true
        exporters: [jaeger/ecorp]

exporters:
  jaeger:
    endpoint: localhost:14250
  jaeger/acme:
    endpoint: localhost:24250
  jaeger/ecorp:
    endpoint: localhost:34250

A signal may get matched by routing conditions of more than one routing table entry. In this case, the signal will be routed to all exporters of matching routes. Respectively, if none of the routing conditions met, then a signal is routed to default exporters.

It is also possible to use both the conventional routing items configuration and the routing items with OTTL conditions.

• OTTL expressions can be applied only to resource attributes.
• Currently, it is not possible to specify the boolean expression without function invocation as the routing condition. It is required to provide the NOOP route() or any other supported function as part of the routing expression, see #13545 for more information.
• Supported OTTL functions:
  • IsMatch
  • delete_key
  • delete_matching_keys

The full list of settings exposed for this processor are documented here with detailed sample configuration files:

• logs
• metrics
• traces