github.com/open-telemetry/opentelemetry-collector-contrib/processor/routingprocessor

Routing processor

Status
Stability	beta: traces, metrics, logs
Distributions	contrib
Issues
Code Owners	@jpkrohling

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/metrics/logs 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.

Configuration

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

Tech Preview: OpenTelemetry Transformation Language statements as routing conditions

Alternatively, it is possible to use subset of the OpenTelemetry Transformation Language (OTTL) statements 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.statement (required): the routing condition provided as the OTTL statement.
• 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.
• error_mode (optional): determines how errors returned from OTTL statements are handled. Valid values are ignore and propagate. If ignored or silent is used and a statement's condition has an error then the payload will be routed to the default exporter. When silent is used the error is not logged. If not supplied, propagate is used.

processors:
  routing:
    default_exporters:
    - jaeger
    error_mode: ignore
    table:
      - statement: route() where resource.attributes["X-Tenant"] == "acme"
        exporters: [jaeger/acme]
      - statement: delete_key(resource.attributes, "X-Tenant") where IsMatch(resource.attributes["X-Tenant"], ".*corp")
        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 mix both the conventional routing configuration and the routing configuration with OTTL conditions.

Limitations:

• OTTL statements can be applied only to resource attributes.
• Currently, it is not possible to specify the boolean statements 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 statement, see #13545 for more information.
• If data is received on OTLP http server, include_metadata must be set to true in order to use context based routing.
• 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