processor/routing supports matching the statement only once.

[huange7]

Component(s)

processor/routing

Is your feature request related to a problem? Please describe.

If multiple statements are configured in the configuration file, the routing processor will judge each statement. Whenever a match is made, data will be sent to the exporters defined in the configuration. Can we support interrupting the match after matching only once?

Describe the solution you'd like

Use a switch to allow the routing processor to match only once.

Describe alternatives you've considered

No response

Additional context

 routing:
    default_exporters:
      - jaeger
    error_mode: ignore
    table:
      - statement: route() where resource.attributes["service.name"] == "demo"
        exporters: [ logging ]
      - statement: route() where resource.attributes["service.name"] == "demo" and resource.attributes["token"] == "xxx"
        exporters: [ logging/2 ]

As shown in the configuration file above, I hope that some traces/metrics/logs will be sent to logging exporter if they only match the service.name attribute, and if they match both the service.name and the token, they will be sent to logging/2 exporter. This is possible in practice.

If this seems reasonable, I sincerely hope that I can make some contributions.

[github-actions]

Pinging code owners:

• processor/routing: @jpkrohling

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[crobert-1]

Hello @huange7, would it be possible to simply make your routing statements more specific to accomplish this functionality?

It sounds like your goal is to match only the most specific routing statement possible, and ignore any statement more general. If this is correct, we can simply update the general statement in your configuration to be more specific, so the match isn't overlapping anymore (a given log/metric/trace will then only match one statement). In your example, you could simply do the following:

 routing:
    default_exporters:
      - jaeger
    error_mode: ignore
    table:
      - statement: route() where resource.attributes["service.name"] == "demo" and resource.attributes["token"] != "xxx"
        exporters: [ logging ]
      - statement: route() where resource.attributes["service.name"] == "demo" and resource.attributes["token"] == "xxx"
        exporters: [ logging/2 ]

Apologies if I've misunderstood or missed anything here.

[huange7]

would it be possible to simply make your routing statements more specific to accomplish this functionality?

@crobert-1 Thanks for your reply. This sounds feasible.

However, let's consider a scenario where there is a processor that adds data.index attribute as the first layer of routing, and a second processor that adds exporter.index attribute as the second layer of routing. In this case, we want to configure a default route for the first layer of routing (data.index), and then configure individual routes for each value of exporter.index.

In that case, the configuration file would look like this:

routing:
    default_exporters:
      - jaeger
    error_mode: ignore
    table:
      - statement: route() where resource.attributes["data.index"] == "1" and resource.attributes["exporter.index"] != "1" and resource.attributes["exporter.index"] != "2"
         exporters: [ logging ]
      - statement: route() where resource.attributes["data.index"] == "1" and resource.attributes["exporter.index"] == "1"
        exporters: [ logging/1 ]
      - statement: route() where resource.attributes["data.index"] == "1" and resource.attributes["exporter.index"] == "2"
        exporters: [ logging/2 ]

As the number of different exporter.index values increases, the configuration for the default route could become more complex and lengthy. It's important to consider how to maintain the readability and manageability of the configuration file in such cases.

[jpkrohling]

Can you confirm the same applies to the connector? I'd be more inclined to accept this new feature there instead of the processor.

[huange7]

Can you confirm the same applies to the connector? I'd be more inclined to accept this new feature there instead of the processor.

Hello, @jpkrohling. Do you mean to add this feature to the routing connector rather than the routing processor? If so, I can implement this feature in the connector.

[crobert-1]

/label -needs-triage

[crobert-1]

/label connector/routing -processor/routing

[github-actions]

Pinging code owners for connector/routing: @jpkrohling @mwear. See Adding Labels via Comments if you do not have permissions to add labels yourself.