[connector/routing] Using OTTL inferred context capability

[TylerHelmuth]

Component(s)

connector/routing

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

Today when reading a routingconnect config that uses OTTL statements or conditions, it is not immediately clear which OTTL context is being used. If a config contains the condition

attributes["env"] == "prod" and attributes["region"] == "east"

you have to know that the component uses ottlresource context by default. This can be confusing for new users and is a failing of OTTL.

Describe the solution you'd like

We added a new feature to OTTL to allow parsers to infer the context based on the statement's paths, functions, and enums. This means that instead of writing:

attributes["env"] == "prod" and attributes["region"] == "east"

and not being sure whose attributes are being used, you'd write

resource.attributes["env"] == "prod" and resource.attributes["region"] == "east"

and now it is immediately clear that we're using the resource's attributes.

We've added this feature to the transformprocessor already. We'll need work from #37904 to get the infer context stuff working for OTTL Conditions.

Describe alternatives you've considered

No response

Additional context

When this work is done users will be able to safely copy and paste statements/conditions between transformprocessor, filterprocessor, and routingconnector.

[github-actions]

Pinging code owners:

• connector/routing: @jpkrohling @mwear

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

[ethuleau]

Does it will permit to have conditions across different contexts like resource.attributes["env"] == "prod" and scope.name == "foo"?
For the moment, it is tricky to do that. I think we can achieve this with a routing layered approach.

[TylerHelmuth]

resource.attributes["env"] == "prod" and scope.name == "foo" would be run in the instrumentation scope ottl context.
OTTL contexts always support reaching "up" to higher context in the OTLP hierarchy. So the statement will not be run in multiple contexts, but context inference will choose the most efficient context to run the statement.

[shalk]

@TylerHelmuth The feature is great, it is just what we need.

But before the feature is done ,Is there any workaround ?

Here is my case ,i want to combine the follow condition with and

      - context: span
        condition: attributes["rpc.system.method"] == "funcA2" and attributes["rpc.system"] == "grpc" 
        pipelines: [traces/core]
     - context: resource
        condition: attributes["service.name"] == "service1"
        pipelines: [traces/core]

be Equivalent to

resource.attributes["service.name"] == "service1" and span.attributes["rpc.system.method"] == "funcA2" and span.attributes["rpc.system"] == "grpc" 

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• connector/routingconnector: @mwear

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