Closed NicolasBissig closed 1 month ago
Hi @NicolasBissig, thank you for the report. Does this happen when the duration unit is in nanoseconds? Is the same behaviour observed if the unit is in milliseconds?
It seems like Grafana prefers the float
timestamps for tracing purposes since JavaScript Date
can't go sub-millisecond.
We will need to do a similar formula to what we do for duration, but this should be an easy change.
@aangelisc changing duration unit only affects duration for now, but now I see we might need to apply it to startTime as a float
Thanks for the response @SpencerTorres, perhaps we could generalise this to handle any column appropriately, wdyt?
I think it could be a constant function actually, since we would know the precision from the query.
That function is used for when we don't know the intended scale of duration
, but if we're the ones converting the startTime
then we can always go straight to nanoseconds and then shift the decimal to milliseconds.
Should be an easy change. See #720 for a visualization of this issue occurring on duration
@aangelisc as I see that there already is an open pull request, can I assume that the question with the duration unit has been answered? :)
Hi @NicolasBissig, yep that question has been answered. I believe the open PR should fix this problem!
Cool, thanks for the fast fix guys! :clap:
What happened: When viewing an OpenTelemetry Trace stored in ClickHouse, the trace is displayed with wrong timing information
Figure 1: The ClickHouse trace viewed in grafana
Figure 2: The same trace stored and queried from Tempo viewed in Grafana
The durations of the spans are correct, however the starting positions are not. The tempo trace is correct here.
What you expected to happen: I expect the ClickHouse trace representation to be the correct one.
How to reproduce it (as minimally and precisely as possible): Setup any tracing solution and configure an OpenTelemetry collector to export the data at the same time to the ClickHouse database AND a Tempo Backend. View the same trace in both systems. Use the ClickHouse exporter contained in the contrib version of the collector.
Screenshots
Anything else we need to know?: This seems to relate to https://github.com/grafana/clickhouse-datasource/issues/771
This is the default query produced for viewing a trace:
If it is adapted to
mainly with
toUnixTimestamp64Nano(Timestamp) / 1000000 as startTime
will result in the correct trace representation:Figure 3: Trace view from ClickHouse with adapted query, now displayed correctly.
This is just a workaround / solution suggestion, if there are better ways to provide the same result, please let me know
Environment: