I built a read-only disk check for self-hosted SigNoz's ClickHouse

[Protemir]

On SigNoz installs from the old docker compose files, ClickHouse®'s own log tables have no TTL and can eat most of the disk. In #12050 that was 80+ GB of system logs, including an old trace_log_0 copy, next to less than 500 MB of actual telemetry. Foundry sets TTLs now, but older installs that were never migrated still have this.

So I wrote diskvet, a small open-source shell script that checks for this and prints the fix commands for your tables. It only runs SELECTs on system.*, changes nothing and sends nothing anywhere.

curl -fsSLO https://github.com/Protemir/diskvet/releases/latest/download/diskvet.sh
curl -fsSLO https://github.com/Protemir/diskvet/releases/latest/download/checks.sql
less checks.sql    # only SELECTs from system.* tables
sh diskvet.sh report --docker auto > report.md

--docker auto finds the ClickHouse container for both install methods (signoz-clickhouse or signoz-telemetrystore-clickhouse-0-0). On Kubernetes it's --k8s auto, and the fix comes out as values for the SigNoz chart.

It also looks for leftover *_log_N copies, disk space used outside ClickHouse's parts, growth per day, too many parts, stuck or detached parts, and deleted rows that still take space. The TTL file it generates only covers the logs your server actually has, since SigNoz's config leaves some of them off. For tables over 50 GB it adds SETTINGS max_table_size_to_drop = 0 so the TRUNCATE doesn't fail with Code 359.

If you'd rather do it by hand, the same steps are here: https://diskvet.dev/guide/

I've tested it on the ClickHouse versions SigNoz has shipped (24.1, 25.5, 25.12) and on a kind cluster, but not on a full SigNoz install yet. If you run it, tell me what it found or missed, here or in an issue.

ClickHouse is a registered trademark of ClickHouse, Inc. diskvet is not affiliated with ClickHouse, Inc.