Gözlemlenebilirlik, modern dağıtık sistemlerin omurgasıdır ancak önemli bir performans vergisi getirir: kardinalite. Geliştiriciler, ince granüllü sorgulamayı etkinleştirmek için metriklere etiketler eklediklerinde, zaman serisi verilerinde kombine patlamalar yaratmak sıklıkla kaçınılmaz hale gelir. Bu "kardinalite patlaması", bellek dışı hatalara (out-of-memory), disk G/Ç darboğazlarına ve aşırı yüksek altyapı maliyetlerine yol açabilir. Bu yazıda, Prometheus'un yerel mimarisi ile VictoriaMetrics'in bulut-native verimliliğini karşılaştırarak, yüksek kardinaliteli zaman serisi veri alımını optimize etme stratejilerini inceleyeceğiz.
Kardinalite Tuzağını Anlamak
Kardinalite, metrik adları ve etiket çiftlerinin bir kombinasyonundan üretilen benzersiz zaman serilerinin sayısını ifade eder. Örneğin, user_id etiketiyle http_requests_total metriğini yayınlamak tehlikelidir. Eğer 1 milyon aktif kullanıcınız varsa, anında 1 milyon benzersiz zaman serisi oluşturursunuz. Prometheus, tüm verileri zaman aralığı sorgulamaları için optimize edilmiş ancak devasa etiket kombinasyonları için değil, yerel diskte depolar. Veri alım oranları yükseldiğinde veya benzersiz etiket değerlerinin sayısı çok büyüyorsa, Zaman Serisi Veritabanı (TSDB) bileşeni, WAL (Ön Yazma Günlüğü) segmentlerini ve bellek eşlemeli dosyaları yönetmekte zorlanır.
Strateji 1: Prometheus'ta Önleyici Etiket Filtreleme
Savunmanın ilk hattı, yüksek kardinaliteli etiketlerin sisteme hiç girmesini engellemektir. Prometheus'ta, kardinalite kurallarınızı ihlal eden metrikleri veya etiketleri atlamak için çekme (scraping) yapılandırmanızda metric_relabel_configs kullanabilirsiniz.
Örneğin, oturum kimlikleri gibi Kişisel Tanımlayıcı Bilgileri (PII) içeren bir uç nokta yanlışlıkla çektiyseniz, bu etiketi depolamadan önce çıkarmalısınız. prometheus.yml dosyanızda bir atma kuralını nasıl yapılandırabileceğinize aşağıda yer verilmiştir:
scrape_configs:
- job_name: 'web_app'
metrics_path: '/metrics'
relabel_configs:
- source_labels: [__name__]
regex: 'my_app_(.+)'
action: drop
metric_relabel_configs:
# Oturum kimliği gibi yüksek kardinaliteli etiketlere sahip metrikleri at
- source_labels: [session_id]
regex: '.+'
action: drop
Bu yaklaşım, veritabanının bu seriler için asla bellek ayırmamasını sağlar. Ancak bu "kayıplı" (lossy) bir yaklaşımdır; o belirli serileri sorgulama yeteneğini tamamen kaybedersiniz. Yalnızca izleme ihtiyaçlarınız için gerekli olmayan etiketleri attığınızdan emin olun.
Strateji 2: Yüksek Ölçekli Veri Alımı İçin VictoriaMetrics'ten Yararlanma
Prometheus, kısa vadeli, yüksek çözünürlüklü izleme için mükemmel olsa da, yüksek kardinaliteli verilerin uzun vadeli depolanması için tasarlanmamıştır. VictoriaMetrics burada parlar. Prometheus'un ölçeklenebilirlikteki sınırlamalarını ele almak üzere özel olarak inşa edilen VictoriaMetrics, daha verimli bir depolama motoru ve sıkıştırma algoritmaları kullanır.
VictoriaMetrics, uyarılar için "VMAlert"ı destekler ve Prometheus ile uyumlu bir uzak yazma (remote write) protokolü sunar. Temel avantajlarından biri, tek düğüm dağıtımları için parçalama (sharding) veya karmaşık küme yönetimi gerektirmeden yüksek alım oranlarını işleyebilme yeteneğidir. Tek bir makinede milyarlarca benzersiz zaman serisini işleyebilen tek düğümlü bir mimari kullanır ve operasyonel karmaşıklığı azaltır.
Geçiş yapmak için, Prometheus yapılandırmanızdaki remote_write uç noktasını VictoriaMetrics'i işaret edecek şekilde değiştirmeniz yeterlidir:
global:
scrape_interval: 15s
remote_write:
- url: 'http://victoriametrics:8428/api/v1/write'
queue_config:
max_samples_per_send: 5000
capacity: 25000
Strateji 3: Aşağı Örnekleme ve Veri Saklama Politikaları
Arka uç ne olursa olsun, aylarca ham milisaniye düzeyindeki verileri depolamak genellikle gerekli değildir. Hem Prometheus hem de VictoriaMetrics aşağı örnekleme (downsampling) destekler. VictoriaMetrics özellikle, eski verilerin otomatik olarak 1 dakikalık veya 1 saatlik çözünürlüklere agregalandığı agresif aşağı örnekleme politikalarına izin verir.
Bu, disk kullanımını önemli ölçüde azaltır. Maliyet ve gözlemlenebilirlik ihtiyaçlarını dengeleyen saklama süreleri yapılandırarak, yüksek çözünürlüklü verileri birkaç hafta (son olayları hata ayıklamak için yeterlidir) ve düşük çözünürlüklü verileri yıllarca (eğilim analizi için faydalıdır) tutabilirsiniz.
Sonuç
Yüksek kardinaliteli zaman serisi veri alımını optimize etmek yalnızca donanım ölçeklendirmesiyle ilgili değildir; mimari disiplin gerektirir. Kullanıcı kimlikleri, IP adresleri veya dinamik istek kimlikleri gibi "kötü" etiketler için metriklerinizi denetleyerek başlayın. Bu etiketleri kaynağında çıkarmak için Prometheus yeniden etiketleme kurallarını kullanın. Uzun vadeli depolama ve geçmiş analiz için, üstün sıkıştırma ve alım performansı sunan VictoriaMetrics'e veri yüklemeyi düşünün. Etiket hijyenini doğru depolama arka ucuyla birleştirerek, uygulamanızın büyümesiyle birlikte ölçeklenen sağlam ve maliyet etkin bir gözlemlenebilirlik yığını koruyabilirsiniz.