pkg/ottl: add request context

[axw]

Component(s)

pkg/ottl

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

There are cases where it is useful to operate on request metadata, e.g. to use metadata (headers) for routing, as proposed in #38888 and as already supported in routingprocessor.

This would also solve the need in #37616.

Describe the solution you'd like

I would like to add a standard "request" context to OTTL. This would be a level above "resource", and would provide the following paths based on https://github.com/open-telemetry/opentelemetry-collector/blob/main/client/client.go:

• request.addr: the client address
• request.auth.attributes: the full map of client auth data
• request.auth.attributes[""]: a specific key in the client auth data, supporting multiple keys for nested data
• request.metadata: the full map of client metadata
• request.metadata[""]: a specific key in the client metadata; if 2 keys are provided, the second one will index into the slice of values

Describe alternatives you've considered

Instead of creating a generic "request" context, we could create receiver-specific contexts, e.g. http, or kafka. This may provide a cleaner solution to #35231 (comment)

I'm not sure how practical this is at the moment. My understanding is that each subsequently more narrowly-scoped context (e.g. resource -> scope -> log) knows about and implements access to the more general scope. I don't think we would want a kafka context inside pkg/ottl, so we would probably want instead to somehow inject that through context.Context.

Additional context

No response

[github-actions]

Pinging code owners:

• pkg/ottl: @TylerHelmuth @kentquirk @bogdandrutu @evan-bradley @edmocosta

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

[Erog38]

This is a problem across multiple areas. OTTL transformations on contexts in the transform processor would allow for things like header-setter extension to work based on resource attributes, batch processor to be based on attributes / resource attributes, etc.

This addition would be awesome.

[TylerHelmuth]

I believe this is a duplicate of #33288, please ping me if you disagree

[axw]

Copying my message from Slack for posterity:

Not certain if it's a duplicate. I see this issue enabling #33288:

• [processor/transform] Set attribute values using connection context #33288 is specifically about the transform processor, whereas I want to make sure the request context is available to any OTTL user (such as the partitioning processor I've proposed in New component: OTTL-based request partitioning processor #39199 -- my primary motivation).
• This proposal includes access to other request metadata, including the client address and auth details, which is not covered by [processor/transform] Set attribute values using connection context #33288. We have some other use cases that would need these, e.g. for recording the browser client IP address of instrumented web apps, and for recording the authenticated identity of a client

[axw]

Another point: #39157 is about accessing request-level metadata and using it to set attributes in the data, whereas there are use cases for transforming request-level metadata.

@TylerHelmuth ping