routingprocessor

README

Routing processor

Status
Stability	beta
Supported pipeline types	traces, metrics, logs
Distributions	contrib

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.

processors:
  routing:
    default_exporters:
    - jaeger
    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") == 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 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.
• 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

Documentation

Index

• func NewFactory() component.ProcessorFactory
• type AttributeSource
• type Config
  • func (c *Config) Validate() error
• type RoutingTableItem

Functions

func NewFactory

func NewFactory() component.ProcessorFactory

NewFactory creates a factory for the routing processor.

Types

type AttributeSource

type AttributeSource string

type Config

type Config struct {
	config.ProcessorSettings `mapstructure:",squash"` // squash ensures fields are correctly decoded in embedded struct

	// DefaultExporters contains the list of exporters to use when a more specific record can't be found in the routing table.
	// Optional.
	DefaultExporters []string `mapstructure:"default_exporters"`

	// AttributeSource defines where the attribute defined in `from_attribute` is searched for.
	// The allowed values are:
	// - "context" - the attribute must exist in the incoming context
	// - "resource" - the attribute must exist in resource attributes
	// The default value is "context".
	// Optional.
	AttributeSource AttributeSource `mapstructure:"attribute_source"`

	// FromAttribute contains the attribute name to look up the route value. This attribute should be part of the context propagated
	// down from the previous receivers and/or processors. If all the receivers and processors are propagating the entire context correctly,
	// this could be the HTTP/gRPC header from the original request/RPC. Typically, aggregation processors (batch, groupbytrace)
	// will create a new context, so, those should be avoided when using this processor.Although the HTTP spec allows headers to be repeated,
	// this processor will only use the first value.
	// Required.
	FromAttribute string `mapstructure:"from_attribute"`

	// DropRoutingResourceAttribute controls whether to remove the resource attribute used for routing.
	// This is only relevant if AttributeSource is set to resource.
	// Optional.
	DropRoutingResourceAttribute bool `mapstructure:"drop_resource_routing_attribute"`

	// Table contains the routing table for this processor.
	// Required.
	Table []RoutingTableItem `mapstructure:"table"`
}

Config defines configuration for the Routing processor.

func (*Config) Validate

func (c *Config) Validate() error

Validate checks if the processor configuration is valid.

type RoutingTableItem

type RoutingTableItem struct {
	// Value represents a possible value for the field specified under FromAttribute.
	// Required when Statement isn't provided.
	Value string `mapstructure:"value"`

	// Statement is a OTTL statement used for making a routing decision.
	// Required when 'Value' isn't provided.
	Statement string `mapstructure:"statement"`

	// Exporters contains the list of exporters to use when the value from the FromAttribute field matches this table item.
	// When no exporters are specified, the ones specified under DefaultExporters are used, if any.
	// The routing processor will fail upon the first failure from these exporters.
	// Optional.
	Exporters []string `mapstructure:"exporters"`
}

RoutingTableItem specifies how data should be routed to the different exporters