Availability of Tempo Trace Proxying

[smauermann]

trafficstars

Hi team,

We are currently looking at using Multena as a proxy for our logs and traces. As far as I understand Trace proxying is currently not supported. Do you have a timeline of when this will be possible?

Cheers, Stephan

[Lucostus]

Hello Stephan,

Currently, we haven't established a schedule for the adoption of TraceQL enforcement. We're eager to arrange a discussion with you to learn more about your use cases. https://calendly.com/d/4y2-54r-gfy/60-min-1o1

[smauermann]

Hi @Lucostus, we simply need a way to manage access to traces via labels akin to what you are already doing with logs stored in Loki. I have booked a slot with you.

[outofrange]

Hi y'all,

I was wondering about Tempo support as well! Is there a particular reason it's not implemented yet?

Did you just not need it badly enough, or isn't it as straight forward as Loki and Thanos appears to be? After having a (very) quick glance over the code, it appears to just require another enforcer and routes, following the same pattern; if that's correct, submitting a PR might be easier than looking for three individual label proxies for Thanos, Loki and Tempo :)

[Lucostus]

Hey @outofrange,

You seem to be correct in both of your assumptions. We don't need it right now, and with the given pattern, it should be an okayish workload to implement it.

I thought about it, and it boils down to parsing the traceql which should be doable looking at the expressions files that Grafana provide for Tempo. However, this would be the first instance of handling parsing within Multena, as this is currently handled by prom-label-proxy or Observatorium, which explains the existing dependencies.

Also side note, parsing in both of these dependencies is handled different. Therefore, it requires different code lol

https://github.com/grafana/tempo/blob/main/pkg/traceql/expr.y

If your pain is big enough, I would be happy to see a PR from you :)