Okay, I completely reset the clickhouse database, ...
# supportp
Pedro Carvalho
05/08/2025, 4:26 AMOkay, I completely reset the clickhouse database, updated it and keeper too.
Issue persists.
Incidentally, the data appears to actually be there as switching to a time series or the table view shows the count of traces.
Error for list view
Copy code
"encountered multiple errors: code: 20, message: Number of columns doesn't match (source: 7 and result: 8)" Copy code
"encountered multiple errors: code: 179, message: Multiple expressions __table1.trace_id and __table2.traceID for alias traceID. In scope SELECT __table2.serviceName AS `subQuery.serviceName`, __table2.name AS `subQuery.name`, count() AS span_count, __table2.durationNano AS `subQuery.durationNano`, __table2.traceID AS traceID FROM signoz_traces.signoz_index_v3 AS __table1 ALL INNER JOIN (SELECT __table3.traceID AS traceID, __table3.durationNano AS durationNano, __table3.serviceName AS serviceName, __table3.name AS name FROM (SELECT __table4.trace_id AS traceID, __table4.duration_nano AS durationNano, __table4.`resource_string_service$$name` AS serviceName, __table4.name AS name FROM signoz_traces.signoz_index_v3 AS __table4 WHERE ((__table4.parent_span_id AS parentSpanID) = '') AND ((__table4.timestamp >= '1746676435000000000') AND (__table4.timestamp <= '1746678235000000000')) AND ((__table4.ts_bucket_start >= 1746674635) AND (__table4.ts_bucket_start <= 1746678235)) ORDER BY durationNano DESC LIMIT _CAST(1, 'UInt64') BY traceID) AS __table3) AS __table2 ON (__table1.trace_id AS traceID) = __table2.traceID WHERE ((__table1.timestamp >= '1746676435000000000') AND (__table1.timestamp <= '1746678235000000000')) AND ((__table1.ts_bucket_start >= 1746674635) AND (__table1.ts_bucket_start <= 1746678235)) AND (__table1.resource_fingerprint GLOBAL IN (_data_3728864367099028535_17756687707892329677 AS __table5)) GROUP BY __table2.traceID, __table2.durationNano, __table2.name, __table2.serviceName ORDER BY __table2.durationNano DESC LIMIT _CAST(1, 'UInt64') BY __table2.traceID LIMIT _CAST(100, 'UInt64')"Pedro Carvalho
05/08/2025, 7:03 AMThe key appears to be
Copy code
DB::Exception: Multiple expressions __table1.trace_id and __table2.traceID for alias traceID.Pedro Carvalho
05/08/2025, 7:25 AMOr rather, why it causes an issue with the frontend query. I checked the table schema
SHOW CREATE TABLE signoz_traces.signoz_index_v3; Copy code
│↳ `traceID` FixedString(32) ALIAS trace_id, ↴│Pedro Carvalho
05/08/2025, 10:28 AMI can also doubly confirm that the data is fine because I can query for it, or directly address it in the url and see the trace details
m
Mykola Marchuk
05/08/2025, 11:53 AMTry to clean up local storage in the browser, maybe it will help. As far as I know, columns for trace view are saved on the client/browser side.
p
Pedro Carvalho
05/09/2025, 1:02 AMThank you for the suggestion, but unfortunately, this does not appear to be the case
Pedro Carvalho
05/09/2025, 1:14 AMI have found that I can see some traces in the traces explorer when entering from a service vie. Not all of them, but enough that I see it multiple times. And something is awfully wrong with it. The data is in the wrong fields.
Pedro Carvalho
05/09/2025, 1:29 AMMessing around further (on an incognito tab), I can get even more incomprehensible situations of mispalced data in the columns.
This looked like the work of a view or a function placed against the traces table, but I saw nothing of the sort. Again, I have not touched the DB past a fresh install except the query data or look at the schema.
Pedro Carvalho
05/09/2025, 8:41 AMFollow up on this, as I have fixed the issue. The problem was... We updated Clickhouse a weeks back. Signoz doesn't support latter versions, and it must have taken a while to get to the point where something that affects it pops up.
I downgraded it and everything is working.
n
Nagesh Bansal
05/09/2025, 10:46 AMThanks @Pedro Carvalho for pointing out this issue
What version did you downgrade to? And what version you were using earlier?
p
Pedro Carvalho
05/12/2025, 1:32 AMThe original version that it got updated to that it got updated to was 25.2.2.XX where saw the issue, but when I tried a fresh instance it was set to 25.4.2.31, as that's what I saw from clickhouse itself while debugging for issues. Allowing this db update through without foresight is ultimately my mistake.
The working version is 24.1.2.5. I picked it on the basis of the helm chart.
https://github.com/SigNoz/charts/blob/main/charts/signoz/values.yaml#L121
n
Nagesh Bansal
05/14/2025, 8:04 AMokay Thanks for letting us know @Pedro Carvalho
5 Views