opentelemetry-collector-contrib: [processor/transform] Unable to get item from slice resource attributes value

Component(s)

processor/transform

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

Hi, I’m trying to use the generated slice result by the Split function in transform processor statements. But I didn’t find any working solution to access the item in slice result.

Describe the solution you’d like

Expected statements:

      - context: resource
        statements:
          - set(attributes["db.instance"], Split(attributes["net.peer.name"], ".")[0]) where attributes["net.peer.name"] != nil

      - context: resource
        statements:
          - set(attributes["db.instance"], Split(attributes["net.peer.name"], ".").Get(0)) where attributes["net.peer.name"] != nil

Describe alternatives you’ve considered

No response

Additional context

No response

About this issue

Original URL
State: closed
Created 2 years ago
Reactions: 1
Comments: 15 (15 by maintainers)

Most upvoted comments

Reflecting on this a little more, I think disallowing . after indexing is appropriate. As interesting as something like set(name, datapoints[0].attributes["test"]) looks, it breaks a current fundamental concept we have in OTTL, which is that you can go “down” in the hierarchical structure of pdata.

datapoints[0].attributes["test"] implies accessing the an attribute named “test” on first datapoint of the metric. But this would mean going from the metric context “down” into the datapoint context, which is something we have disallowed. I think it would be possible to implement (especially if we made indexing paths a responsible of the context), but it does go against our current rules.

If we do choose to continue disallowing “downward” access it would mean that [] has to terminate a path and could be handled during hot path execution similar to Converters. It would also open up a clear path to allowing other paths or Converters as index values.

TylerHelmuth on Mar 25, 2023

It shouldn’t be difficult since the invocation struct is already separate from the path struct that uses indexing. I was more talking about reading the language and comprehending that we’re accessing a slice instead of a map. We need to make sure statements are easy to understand.

TylerHelmuth on Dec 9, 2022

Thanks for reporting this. You’re right that the OTTL currently doesn’t support indexing slices. I think the solution that would be most obvious to most users would be the first statement you suggested that uses array indexing notation. Calling a method on a slice is an interesting concept, but I’m not sure whether we’d want to introduce OOP concepts to the OTTL.

I see two potential solutions to offer slice indexing:

Implement slice indexing in the OTTL grammar. This would need to work with paths with slice values and with invocations that return slices. I don’t think it would need to work with slice literals. It would likely be implemented as another type of Getter.
Implement an index factory function that returns the value at a particular index from a slice Getter. This usage would be less obvious to users who are used to array indexing in most programming languages, but would be a little simpler to implement.

I think the first option is likely the best path forward, but would be interested in others’ opinions.

evan-bradley on Dec 8, 2022