ClickHouse'un sınırsız sistem logları, self-hosted Langfuse ve SigNoz'da diskleri sessizce dolduruyor

Self-hosted gözlemlenebilirlik (observability) yığınlarının göz alıcı olmayan bir disk yiyicisi var: ClickHouse'un kendi kayıtları. dev.to'daki bir rehber, Langfuse ve SigNoz kurulumlarının izleme (trace) hacmi çok küçük olsa bile neden diskten yetersiz kaldığını açıklıyor ve dört adımlı bir kurtarma sürecini ele alıyor: sorumluyu tespit et, şişmiş tabloları truncate et, saklama limitleri ekle ve sonrasında temizle. Yazar, adımları standart clickhouse/clickhouse-server imajları 24.8, 25.12 ve 26.9 üzerinde test etti; SigNoz komutları ise 25.5 ve 25.12 üzerinde doğrulandı.

Sorumluyu tespit etmek

Halka açık raporların çoğunda alan, uygulama verisine değil; varsayılan olarak boyut limiti bulunmayan system.trace_log ve system.text_log gibi ClickHouse'un iç tablolarına gidiyor. ClickStack da aynı davranışı gösteriyor. Tanılama, system.parts'a karşı, tabloları diskteki boyuta göre en büyükten listeleyen tek bir salt-okunur sorgu:

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

Bunu --readonly=1 ile çalıştırın ki ClickHouse veride herhangi bir değişikliği reddetsin. Langfuse'un docker compose kurulumunda kimlik bilgileri konteyner içinde zaten CLICKHOUSE_USER ve CLICKHOUSE_PASSWORD olarak ayarlıdır; SigNoz'da konteynerin adı genellikle signoz-clickhouse'dır ve varsayılan kullanıcının şifresi yoktur. Gerçek verinizden önce sistem tabloları listeye hâkimse, sorun ClickHouse'un kendi loglarıdır.

Alanı hemen boşaltmak

Yazma erişimine sahip bir istemci açın ve suçluları truncate edin: system.trace_log, system.text_log, system.metric_log ve system.query_log. Bu, yalnızca ClickHouse'un tanılamalarını siler, izlemelerinizi değil; ve yeniden başlatma gerektirmez. Rehberden bir uyarı: Langfuse, kendi sorgularından bazılarını takip etmek için system.query_log'u okuyor, dolayısıyla boşaltın ama devre dışı bırakmayın.

Yaklaşık 46,6 GiB'tan büyük tablolar — TRUNCATE'a da uygulanan, 50 milyar baytlık varsayılan max_table_size_to_drop — Code 359 hatasıyla başarısız olur. ClickHouse 23.12 ve üzerinde bu limit tek bir ifade için kaldırılabilir:

sql TRUNCATE TABLE system.text_log SETTINGS max_table_size_to_drop = 0;

Alternatif olarak, /var/lib/clickhouse/flags/force_drop_table bayrak dosyasını 666 moduyla oluşturun ve düz TRUNCATE'ı yeniden çalıştırın. ClickHouse bu bayrağı, ona ihtiyaç duyan ilk işlemden sonra kaldırır; bu yüzden her aşırı büyük tablo için yeniden oluşturulması gerekir.

Bu tablolar neden şişiyor

Rehberde alıntılanan ClickHouse'un kendi dokümantasyonu, tablo büyümesinin varsayılan olarak sınırsız olduğunu belirtir. Büyük tabloları iki varsayılan sürükler: query profiler, çalışan sorguların stack örneklerini trace_log'a yazar ve text_log, sunucu logunu trace seviyesinde saklar. 25.9'dan beri varsayılan yapılandırmalar yalnızca processors_profile_log için 30 günlük bir TTL belirler, büyük olanlar için değil.

Halka açık kayıtlar ölçeği gösteriyor. Langfuse tartışması #13123'te system.trace_log 66,86 GiB'a ulaşmışken traces, observations ve scores tabloları toplamda yaklaşık 51 MiB kullanıyordu; geliştiriciler ClickHouse'un varsayılanlarını geçersiz kılmamayı seçtiler ve bunun yerine sorunu bir SSS'de belgelediler. SigNoz issue #12050'de, 500 MB'tan az telemetrinin yanında 80 GB'tan fazla sistem logu duruyordu ve truncate etmek yaklaşık 80 GB kurtardı. SigNoz'un daha yeni Foundry kurulum aracı TTL'ler ayarlıyor, ancak eski docker compose kurulumları ayarlamıyor. Eylül 2026'da birleştirilen bir ClickStack Helm chart pull request'i, on günde dolan 10 Gi'lik bir volume raporunu izleyerek 7 günlük bir TTL ekledi.

Düzeltmeyi kalıcı kılmak

Bir TTL, ClickHouse'un eski log satırlarını kendi başına expired etmesini sağlar. Sıralama önemlidir: ClickHouse yeni bir TTL ile yeniden başladığında eski tabloyu, satırlarıyla birlikte, trace_log_0 gibi bir isimle yeniden adlandırır ve TTL altında taze bir tablo oluşturur. Önce truncate etmek bu kopyaları küçük tutar ve sonradan drop edilebilirler.

Saklama kuralları docker-compose.yml'in yanındaki bir config.d XML dosyasına girer — query_log, trace_log, text_log, metric_log, asynchronous_metric_log ve part_log'un her biri için event_date + INTERVAL 7 DAY DELETE gibi bir giriş — ve ardından yeniden başlatma yapılır. system.tables'a karşı bir sorgu, hangi logların halihazırda TTL'siz olduğunu gösterir. Öne çıkan bir tuzak: opentelemetry_span_log standart yapılandırmada bir engine elementi üzerinden tanımlanır ve ayrı bir ttl girişi sunucunun başlamasını engeller (ClickHouse issue #88366). TTL'si engine tanımının içinde olmalıdır.

Disk hâlâ doluysa

Alan geri gelmiyorsa, rehber sırada Docker'ın kendi konteyner loglarına, diskte hâlâ tutulan silinmiş satırlara ve takılmış part'lara işaret ediyor. Ayrıca Langfuse kullanıcılarını, ClickHouse'u 26.8 veya üzerine geçirmeden önce Langfuse'u güncellemeleri konusunda uyarıyor.

Neden önemli

Gözlemlenebilirlik altyapısı sistemleri izlemek için vardır, onları aç bırakmak için değil; ama bu varsayılan tam olarak bunu yapıyor: sağlıklı görünen bir izleme yığını, disk dolana kadar kendi volume'unu sessizce tüketiyor. Büyüme kullanıcı verisinde değil sistem tablolarında olduğundan, yalnızca uygulama metriklerini izleyenler için görünmezdir; ve ne Langfuse ne de eski SigNoz compose kurulumları bir limit sunar. Çare ucuz — tek bir salt-okunur sorgu, bir truncate, küçük bir yapılandırma dosyası — ve doğru sıralamak, 50 GB'lık drop korumasından engine kapsamlı TTL'ye kadar bilinen tuzaklardan kaçınmanızı sağlar. Langfuse, SigNoz, ClickStack veya başka herhangi bir ClickHouse tabanlı yığını self-host eden herkes, bir disk uyarısı sizin yerinize yapmadan önce system.parts'ı kontrol etmeli.