ClickHouse remplit le disque avec ses propres logs

Ce qui se passe

Un guide publié sur DEV Community fait le point sur un problème récurrent des outils d'observabilité auto-hébergés : Langfuse, SigNoz ou ClickStack remplissent le disque alors que les traces stockées pèsent peu. La place part presque toujours dans les tables de logs de ClickHouse lui-même, dont la documentation précise que leur croissance est illimitée par défaut.

Les commandes ont été testées sur les images clickhouse/clickhouse-server 24.8, 25.12 et 26.9.

Pourquoi ça grossit

ClickHouse écrit ses diagnostics dans la base system : query_log, trace_log, text_log, metric_log… Les configurations récentes ne posent une durée de conservation que sur quelques petites tables. Deux réglages d'usine font enfler les autres : le profileur de requêtes, actif, qui échantillonne les piles dans trace_log, et le journal du serveur au niveau trace, recopié dans text_log.

Les cas publics : 66,86 Gio de trace_log pour environ 51 Mio de données Langfuse (#13123) ; plus de 80 Go de logs système pour moins de 500 Mo de télémétrie SigNoz (#12050) ; un volume de 10 Gi saturé en dix jours sous ClickStack, dont le chart Helm pose depuis septembre une conservation de 7 jours.

Comment s'y prendre

1. Mesurer, dans un client lancé avec --readonly=1 :

SQL

SELECT database, table, formatReadableSize(sum(bytes_on_disk)) AS taille
FROM system.parts
WHERE active
GROUP BY database, table
ORDER BY sum(bytes_on_disk) DESC
LIMIT 15;

Si des tables system.*_log dépassent vos données (default pour Langfuse, signoz_* pour SigNoz), la cause est trouvée.

2. Libérer avec TRUNCATE TABLE system.trace_log; et ses voisines ; vos traces ne sont pas touchées. Au-delà de max_table_size_to_drop (50 000 000 000 octets, environ 46,6 Gio), la commande échoue avec le code 359 : ajouter SETTINGS max_table_size_to_drop = 0 (ClickHouse 23.12 et suivants). Langfuse lit system.query_log : la vider, mais ne pas la désactiver.

3. Borner avec un fichier monté dans /etc/clickhouse-server/config.d/, puis redémarrer le serveur — un simple rechargement ne prend pas la durée en compte :

clickhouse-ttl.xmlXML

<clickhouse>
    <trace_log><ttl>event_date + INTERVAL 7 DAY DELETE</ttl></trace_log>
    <text_log><ttl>event_date + INTERVAL 7 DAY DELETE</ttl></text_log>
    <query_log><ttl>event_date + INTERVAL 7 DAY DELETE</ttl></query_log>
</clickhouse>

4. Nettoyer : au redémarrage, ClickHouse renomme l'ancienne table en trace_log_0, avec toutes ses lignes et sans durée de conservation. Vider d'abord (étape 2) la rend minuscule ; il reste à la supprimer.

Les pièges

opentelemetry_span_log est définie avec une clause <engine> : un <ttl> séparé empêche le serveur de démarrer (ClickHouse #88366). La durée va à l'intérieur de l'<engine>.
Ne déclarer que les logs qui existent : une section de configuration active le log correspondant.
Couper le profileur se fait dans users.d, pas dans config.d, où le réglage est ignoré sans message.
Hors ClickHouse, les journaux Docker json-file n'ont aucune limite par défaut : 89,1 Gio sur un cas Langfuse. Un bloc logging avec max-size: "50m" et max-file: "3" par service, puis une recréation des conteneurs.

Avant de mettre à jour

ClickHouse 26.8 a changé la valeur par défaut de input_format_read_datetime_number_as_raw_value. Avec une version ancienne de Langfuse, une partie des dates s'enregistre en 9999-12-31 23:59:59 — de 0,59 % à 21,43 % des écritures selon les projets (#16858). Passer d'abord en Langfuse v4.28.0 ou v3.225.7.

Source : Why ClickHouse® fills the disk in self-hosted Langfuse and SigNoz, and how to fix it, DEV Community, 26 septembre 2026. L'auteur y présente aussi son script diskvet ; les étapes ci-dessus s'en passent.