When downloading traces json while using Tempo data source, trace/span ids don't match displayed values

In Grafana Explore, I picked a Tempo data source and search using a specific trace ID, let’s say af91cb297a0f485f9bc1eb27bfad2706. The trace is displayed. I then go to Inspector → Data and click Download traces to get a json file.

In the resulting json file, al the trace ids have this value “r5HLKXoPSF+bwesnv60nBg==” it does not show the original trace id. Similarly all span ids are encoded.

Is there a way to get the original trace id and span ids? I want to do some additional processing with the downloaded json and it is difficult to communicate the results when the trace/span ids don’t match the original.

The csv download doesn’t have this problem, the trace ids and the span ids are preserved

Hi @slto. So, both strings are different representations of the same bytes. af91cb297a0f485f9bc1eb27bfad2706 is the hexadecimal representation, and r5HLKXoPSF+bwesnv60nBg== is base64 encoded, which is what JSON uses by default. That’s why you see it that way when you download JSON. Check this snippet, which changes from one representation to the other.

To work with those traces, there are a couple of options: you can convert the IDs to bytes, and work with that, or you can use either hex or base64 encodings.

Hope this helps :slight_smile:

Thanks @mariorodriguez for the explanation and the code example. Very helpful. Is there a reason why the Tempo JSON download can’t just use the hexadecimal representation? This will make the ids consistent with what is displayed in the UI. If I use the Jaeger data source, the ids in the downloaded json matches the display value and they are both the hexadecimal representation.

I don’t think there is an explanation, other than base64 being the default encoding used in JSON. I agree that using the same encoding would be more consistent. I’ve opened this issue to discuss the topic. Thanks for bringing it to our attention.