[pkg/ottl] Cannot access flags from span context

[niko-renko]

Component(s)

pkg/ottl

What happened?

Description

Cannot access flags from span context. Making a statement that uses flags will fail.

Steps to Reproduce

Make & Use a transformer:

  transform:
    error_mode: ignore
    trace_statements:
    - context: span
      statements:
      - set(attributes["flags"], flags)

Expected Result

Spans will have a flags attribute that contain the flags values from the span context.

Actual Result

2024/08/19 17:23:35 collector server run finished with error: invalid configuration: processors::transform: unable to parse OTTL statement "set(attributes[\"collector_test_2\"], flags)": error while parsing arguments for call to "set": invalid argument at position 1: segment "flags" from path "flags" is not a valid path nor a valid OTTL keyword for the Span context - review https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/pkg/ottl/contexts/ottlspan to see all valid paths

Collector version

v0.107.0

Environment information

Environment

OS: Ubuntu 20

OpenTelemetry Collector configuration

receivers:
...

processors:
  transform:
    error_mode: ignore
    trace_statements:
    - context: span
      statements:
      - set(attributes["flags"], flags)

exporters:
...

service:
  pipelines:
    receivers: [...]
    processors: [transform]
    exporters: [...]

Log output

2024/08/19 17:23:35 collector server run finished with error: invalid configuration: processors::transform: unable to parse OTTL statement "set(attributes[\"collector_test_2\"], flags)": error while parsing arguments for call to "set": invalid argument at position 1: segment "flags" from path "flags" is not a valid path nor a valid OTTL keyword for the Span context - review https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/pkg/ottl/contexts/ottlspan to see all valid paths

Additional context

No response

[github-actions]

Pinging code owners:

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

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

[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:

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

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

[Annosha]

@TylerHelmuth If this is a beginner friendly issue can I work on it?

[TylerHelmuth]

@Annosha Sure it is yours

[avanish-vaghela]

Hey @TylerHelmuth, Could you assign this to me please?

[evan-bradley]

@niko-renko Can you talk more about your use case? The W3C specification for the flags only contains two flags, and it's my understanding that the sampled flag isn't particularly meaningful at the point where we're processing data in the Collector (it must necessarily be 1 since we have the trace).

From what I can tell, we should offer a read-only flags.random_trace_id field or similar that provides a boolean representation of the random-trace-id flag.

[evan-bradley]

Reading more of the field definition, it looks like there are a few more flags that can be stored in the field, but I still think we should consider offering paths for each flag. We could potentially offer something like flags.raw_value or similar for direct access to the bit sequence.

[TylerHelmuth]

@evan-bradley to start can we implement it like we implemented flags for logs

[evan-bradley]

Didn't realize logs had a flags field as well, thanks for pointing that out. Are you ware of any usages of that field? I think the UX is likely not very good:

1. Reading out the flags as an integer doesn't seem immediately useful to me, I'm not clear what a user would be able to do with the raw value. Also since there are only a limited set of flags, it would probably make sense to have OTTL pull them out individually since we don't have the bitwise operations necessary to allow users to read them in a statement.
2. Right now the logs proto field says it only contains W3C trace context flags, which I've been told should be considered read-only in Collector processors until someone comes to us with a compelling use case for writing to them. At a minimum, without bitwise operators they're going to be hard to work with.

Unless users are looking for only access to the raw bit sequence, I think we should consider implementing something different for traces and look to update the logs context to match once we're happy with it.

[TylerHelmuth]

Are you ware of any usages of that field

I am not.

If the current logs implementation is not useful I am ok with implementing flags for spans with specific flags in mind, but I do think we should make a generic path like logs in case there is some custom function someone wants to build that does something with the raw flags.

[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:

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

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