ClickHouse, saniyede milyonlarca satırı ingest ederken milisaniyeler bazında sorgu dönebilen bir canavar. Ancak her SRE’nin acı yoldan öğrendiği gibi, veri tabanı izleme süreçlerini doğru kurgulamadığınızda, o canavar bir anda kendi kendini yiyen bir karadeliğe dönüşebilir. Özellikle petabyte ölçeğinde production cluster’ları yönetiyorsanız, yanlış yapılandırılmış bir clickhouse monitoring mimarisi, izlemekle yükümlü olduğu sistemin kendisinde darboğaz (bottleneck) yaratacaktır. Bu rehberde, geleneksel yöntemlerin neden çöktüğünü inceleyecek, gerçek zamanlı big data observability pratiklerini ele alacak ve production ortamında güvenle kullanabileceğiniz bir grafana clickhouse izleme mimarisi inşa edeceğiz.

Geleneksel İzleme Yöntemleri ClickHouse’da Neden Patlar?

Geleneksel RDBMS dünyasından kalma alışkanlıklarla ClickHouse izlemeye çalışmak, tır ile drift yapmaya benzer; teoride eğlenceli görünse de ilk virajda devrilirsiniz. Klasik agent’ların her 5 saniyede bir system tablolarına gidip ağır SELECT COUNT(*) veya agresif system.parts sorguları atması, zaten yoğun write/merge döngüsünde olan ClickHouse’u kilitler.

ClickHouse, doğası gereği asenkron çalışır. Disk üzerindeki data part’ları sürekli arka planda birleştirilir (merge), mutasyonlar (mutations) asenkron olarak işlenir ve replication kuyrukları ZooKeeper/Keeper üzerinden koordine edilir. Eğer siz bu dinamikleri anlamadan sadece CPU/Memory odaklı bir veri tabanı izleme stratejisi kurarsanız, şu klasik felaket senaryolarıyla karşılaşırsınız:

• System Table Şişmesi: system.query_log ve system.trace_log tablolarının temizlenmemesi sonucu diskin dolması.
• ZooKeeper Lock’ları: Replicated tabloların saniyede yüzlerce kez izleme aracı tarafından sorgulanmasıyla ZooKeeper’ın session kaybetmesi.
• Thread Pool Exhaustion: İzleme sorgularının, gerçek analitik sorguların öncelikli thread’lerini işgal etmesi.

1. Adım: Native Prometheus Endpoint’ini Doğru Yapılandırmak

ClickHouse, 20.1 sürümünden beri harici bir exporter’a ihtiyaç duymadan Prometheus formatında metrik üretebiliyor. Ancak default gelen konfigürasyon çoğu zaman production iş yükleri için yetersizdir veya çok fazla gürültü (noise) üretir. İlk iş olarak, native endpoint’i optimize edilmiş bir şekilde aktif edelim.

Aşağıdaki XML bloğunu, cluster üzerindeki tüm node’larda /etc/clickhouse-server/config.d/prometheus.xml olarak kaydedin:

<clickhouse>
    <prometheus>
        <endpoint>/metrics</endpoint>
        <port>9363</port>
        <metrics>true</metrics>
        <events>true</events>
        <asynchronous_metrics>true</asynchronous_metrics>
        <status_info>true</status_info>
    </prometheus>
</clickhouse>

Neden böyle yaptık? asynchronous_metrics parametresi hayati önem taşır. ClickHouse, işletim sistemi seviyesindeki metrikleri ve arka plan thread durumlarını her an güncel tutmak yerine, arka planda belirli aralıklarla asenkron olarak toplar. Bu parametreyi aktif ederek, kazıma (scraping) anında motorun ekstra yük altına girmesini engellemiş oluyoruz.

2. Adım: SRE Gözünden Takip Edilmesi Gereken Kritik Metrikler

Her şeyi izlemek, hiçbir şeyi izlememektir. ClickHouse izlerken panellerinizde mutlaka bulunması gereken, doğrudan “aksiyon alınabilir” metrikler şunlardır:

Active Parts ve Too Many Parts Hatası

ClickHouse’a çok sık ve küçük batch’ler halinde insert yaparsanız, arka plandaki merge mekanizması yetişemez. Bu durum Too many parts in all parts in table hatasına yol açar ve insert’ler blocklanır. Bunu önceden yakalamak için şu metriği alarm listenizin en başına koyun:

# Anlık aktif part sayısı alarm eşiği (Genellikle tablo başına > 300 tehlikedir)
clickhouse_asynchronous_number_of_active_parts

ZooKeeper / ClickHouse Keeper Gecikmeleri

Replicated (örneğin ReplicatedMergeTree) tablolar kullanıyorsanız, ZooKeeper cluster’ınızın sağlığı doğrudan ClickHouse’un sağlığı demektir. ZooKeeper üzerindeki queue birikmelerini şu metrikle izleyin:

# ZooKeeper'da bekleyen asenkron task sayısı
clickhouse_asynchronous_metrics_ZooKeeperHasPendingMutations
# Replicated tablolar için kuyruktaki iş sayısı
clickhouse_metrics_ReplicatedPendingInserts

3. Adım: Grafana Entegrasyonu ve Verimli Dashboard Tasarımı

Grafana clickhouse entegrasyonu için toplulukta iki popüler yaklaşım var: İlki Prometheus üzerinden metrikleri çekmek, ikincisi ise doğrudan ClickHouse sistem tablolarını sorgulayan bir veri kaynağı (örneğin Altinity ClickHouse Datasource) kullanmak. En efektif yöntem, bu ikisini hibrit kullanmaktır.

Grafana üzerinde yavaş sorguları (slow queries) izlemek için doğrudan system tablosunu sorgularken asla limit koyulmamış sorgular atmayın. Aşağıdaki optimize edilmiş SQL örneği, son 1 saatte en çok kaynak tüketen ilk 5 sorguyu cluster genelinde getirir:

SELECT
    query_duration_ms,
    query,
    user,
    formatReadableSize(memory_usage) AS mem
FROM clusterAllReplicas('default', system.query_log)
WHERE event_time > now() - INTERVAL 1 HOUR
  AND type = 'QueryFinish'
ORDER BY query_duration_ms DESC
LIMIT 5;

Neden böyle? clusterAllReplicas tablosal fonksiyonunu kullanarak tüm node’lardaki system.query_log verilerini dağıtık bir şekilde sorguluyoruz. Bu sayede tek bir node’un hafızasını (RAM) şişirmeden, tüm cluster’ın röntgenini çekebiliriz.

4. Adım: Sistem Tablolarının Gizli Tehlikesi ve TTL Yönetimi

ClickHouse default ayarlarda system.query_log, system.trace_log, system.metric_log gibi kritik tabloları sonsuza kadar saklama eğilimindedir. Eğer saniyede binlerce sorgunun döndüğü bir big data observability altyapınız varsa, bu tablolar birkaç hafta içinde disk alanınızı yutacaktır.

Sistem tablolarına akıllıca bir TTL (Time-To-Live) politikası uygulamak şarttır. Bunu yapmak için /etc/clickhouse-server/config.d/system_tables_ttl.xml dosyası oluşturun:

<clickhouse>
    <query_log>
        <partition_by>toYYYYMM(event_date)</partition_by>
        <ttl>event_date + INTERVAL 15 DAY DELETE</ttl>
    </query_log>
    <trace_log>
        <partition_by>toYYYYMM(event_date)</partition_by>
        <ttl>event_date + INTERVAL 7 DAY DELETE</ttl>
    </trace_log>
</clickhouse>

Bu konfigürasyonla birlikte, sorgu geçmişinizi 15 gün, çok daha fazla yer kaplayan execution trace log’larınızı ise sadece 7 gün saklayarak diskin gereksiz yere şişmesini önlemiş oluyoruz. Unutmayın, disk doluluğu %90’ın üzerine çıktığında ClickHouse kendini korumaya alıp read-only moda geçebilir.

Özet: SRE Kontrol Listesi

Büyük ölçekli ClickHouse cluster’ınızı izlerken şu üç kuralı asla aklınızdan çıkarmayın:

1. Dışarıdan (external) agresif polling yapan agent’lar yerine, her zaman ClickHouse’un native Prometheus endpoint yapısını tercih edin.
2. Sadece genel sistem metriklerine (CPU/Memory) bakarak aldanmayın; Active Parts ve Keeper latency metriklerini mutlak kırmızı çizginiz yapın.
3. System tablolarınızı başıboş bırakmayın; mutlaka uygun partition ve TTL politikaları tanımlayarak diskinizin sağlığını koruyun.