Prometheus Yüksek Kardinalite Krizi: Sessiz Metrik İstilası

Prometheus Yüksek Kardinalite Krizi Nedir?

Prometheus, modern bulut yerel altyapıların vazgeçilmez bir izleme aracıdır. Güçlü veri modeli ve esnek sorgulama dili (PromQL) sayesinde sistemlerinizden derinlemesine içgörüler elde etmenizi sağlar. Ancak bu gücün arkasında, eğer dikkatli yönetilmezse ciddi sorunlara yol açabilecek bir tuzak yatar: Yüksek Kardinalite Krizi.

Yüksek kardinalite, bir metrik için çok sayıda benzersiz etiket (label) değeri kombinasyonunun bulunması durumunu ifade eder. Örneğin, bir HTTP isteği metriklerinin her bir istekle birlikte değişen benzersiz bir ID veya zaman damgası etiketi içermesi, milyonlarca hatta milyarlarca benzersiz zaman serisi oluşturabilir. Bu durum, Prometheus’un performansını, depolama maliyetlerini ve operasyonel verimliliğini olumsuz etkileyen sessiz bir istilaya dönüşebilir.

Yüksek Kardinaliteye Neden Olan Faktörler

Yüksek kardinalite sorunu genellikle yanlış metrik tasarımı veya yanlış yapılandırılmış exporter’lar nedeniyle ortaya çıkar. Bu faktörleri anlamak, sorunu kökünden çözmek için kritik öneme sahiptir. İşte yüksek kardinaliteye yol açan başlıca sebepler:

Dinamik etiketler, metriklerinizi aşırı derecede detaylandırarak her bir yeni değer için ayrı bir zaman serisi oluşturur. Granüler metrikler ise zaten kendiliğinden çok fazla benzersiz veri noktası üretme eğilimindedir. Bu durumlar, Prometheus sunucunuzun hızla şişmesine ve performans sorunları yaşamasına neden olur.

Dinamik Etiketlerin Tehlikesi

Dinamik etiketler, genellikle her bir kullanıcı, oturum, istek veya işlem için benzersiz değerler içeren etiketlerdir. Bu tür etiketler, Prometheus’un zaman serisi veritabanında (TSDB) her bir kombinasyon için yeni bir giriş oluşturmasına neden olur. Örneğin, bir API isteğinin URL’sinde kullanıcı ID’sinin etiket olarak kullanılması, her yeni kullanıcı ID’si için yeni bir zaman serisi demektir.

http_requests_total{path="/api/v1/users/123", method="GET"}
http_requests_total{path="/api/v1/users/456", method="GET"}
...

Yukarıdaki örnekte path etiketi, her benzersiz kullanıcı ID’si için farklı bir değer alarak zaman serisi sayısını inanılmaz derecede artırır. Oysa daha uygun bir yaklaşım, dinamik kısmı parametreleştirerek tek bir path değeri altında toplamak olacaktır:

http_requests_total{path="/api/v1/users/:id", method="GET"}

Bu şekilde, path etiketi için yalnızca bir benzersiz değer oluşur ve kardinalite sorunu büyük ölçüde azalır. Dinamik etiketler, genellikle geliştiricilerin sistemdeki her detayı izlemek istemesinden kaynaklanan iyi niyetli ancak yanlış bir yaklaşımdır.

Aşırı Detaylı Metrikler

Bazı durumlarda, metrikler gereğinden fazla detaya iner ve bu da yüksek kardinaliteye yol açar. Örneğin, her bir veritabanı sorgusunun tam metnini veya her bir hata mesajının içeriğini etiket olarak kaydetmek aşırı detaylı bir yaklaşımdır. Bu tür bilgiler genellikle log sistemlerinde daha iyi işlenir ve izleme metrikleri için uygun değildir.

database_query_duration_seconds{query="SELECT * FROM users WHERE id=123", database="prod"}

Burada query etiketi, her benzersiz sorgu metni için yeni bir zaman serisi oluşturur. Bunun yerine, sorgu türü veya tablo adı gibi daha genel etiketler kullanmak çok daha verimli olacaktır. Aşırı detaylı metrikler, sistemdeki her olayı bir metrik olarak kaydetme arzusundan kaynaklanır, ancak bu durum Prometheus’un doğasına uygun değildir.

Yüksek Kardinalitenin Prometheus Üzerindeki Etkileri

Yüksek kardinalite, Prometheus altyapınız üzerinde bir dizi olumsuz etkiye sahiptir. Bu etkiler, sistem performansından maliyetlere, operasyonel karmaşıklıktan güvenilirliğe kadar geniş bir yelpazeyi kapsar. Bu sorunları görmezden gelmek, uzun vadede ciddi sıkıntılara yol açabilir.

Bu etkiler, Prometheus sunucunuzun istikrarsız hale gelmesine, sorguların yavaşlamasına ve hatta OOM hatalarına yol açabilir. Bu nedenle, yüksek kardinaliteyi anlamak ve yönetmek, sağlıklı bir izleme altyapısı için hayati öneme sahiptir.

Depolama Maliyeti ve Performans

Prometheus’un zaman serisi veritabanı (TSDB), her benzersiz etiket kombinasyonu için ayrı bir zaman serisi kaydeder. Yüksek kardinalite, bu benzersiz serilerin sayısını astronomik seviyelere çıkarır. Bu durumun doğrudan sonuçları şunlardır:

• Artan Disk Alanı: Her yeni zaman serisi, diske yazılması gereken ek veri blokları anlamına gelir. Bu da depolama gereksinimlerini ve dolayısıyla maliyetleri önemli ölçüde artırır.
• Yavaş Veri Alımı (Ingestion): Prometheus, yeni gelen metrikleri mevcut serilerle eşleştirmek zorundadır. Milyonlarca aktif serinin olduğu bir ortamda, bu eşleştirme işlemi CPU ve I/O kaynaklarını yoğun bir şekilde tüketir, veri alım hızını düşürür.
• Yavaş Sorgu Yürütme (PromQL): PromQL sorguları, belirtilen zaman aralığında ve etiket eşleşmelerine göre ilgili zaman serilerini tarar. Yüksek kardinalite, sorguların taranması gereken veri miktarını artırır ve bu da sorguların tamamlanma süresini uzatır. Basit bir metrik sorgusu bile dakikalar sürebilir.

Bellek (RAM) Tüketimi

Prometheus, aktif zaman serilerini bellekte (RAM) tutar. Bu, yeni gelen veri noktalarının hızlı bir şekilde işlenmesini ve sorguların verimli bir şekilde yürütülmesini sağlar. Ancak yüksek kardinalite durumunda:

• Artan Bellek Kullanımı: Milyonlarca aktif zaman serisi, Prometheus sunucusunun belleğini hızla doldurur. Her bir zaman serisi, kendi meta verileri ve son veri noktaları için belli bir miktar bellek tüketir.
• Out-Of-Memory (OOM) Hataları: Bellek kullanımı kritik seviyelere ulaştığında, işletim sistemi Prometheus sürecini OOM Killer ile sonlandırabilir. Bu da izleme sisteminizin kesintiye uğramasına neden olur ve güvenilirliği ciddi şekilde etkiler.
• Sistem İstikrarsızlığı: Sürekli OOM hataları veya bellek basıncı, Prometheus sunucusunun genel istikrarını bozar ve sürekli yeniden başlatmalara yol açabilir.

Operasyonel Karmaşıklık

Yüksek kardinalite, sadece teknik performans sorunları yaratmakla kalmaz, aynı zamanda operasyonel ekipler için de ciddi zorluklar doğurur:

• Sorun Giderme Zorluğu: Çok sayıda etiket kombinasyonu, belirli bir sorunun kök nedenini bulmayı zorlaştırır. Hangi etiket değerinin soruna yol açtığını tespit etmek, karmaşık PromQL sorguları ve manuel incelemeler gerektirebilir.
• Uyarı Güvenilirliğinin Azalması: Yüksek kardinalite nedeniyle Prometheus’un performansı düştüğünde, uyarı kurallarının doğru zamanda tetiklenmesi veya hiç tetiklenmemesi riski artar. Bu da kritik sorunların gözden kaçırılmasına neden olabilir.
• Kaynak Planlama Zorluğu: Gelecekteki kaynak ihtiyaçlarını tahmin etmek, kardinalite kontrol altında değilse neredeyse imkansız hale gelir. Aniden yükselen metrik serileri, planlanmamış donanım yükseltmeleri veya ölçeklendirme gereksinimleri doğurabilir.

Yüksek Kardinalite Krizini Tespit Etme Yöntemleri

Yüksek kardinalite krizini yönetmenin ilk adımı, bu sorunu erken aşamada tespit edebilmektir. Prometheus’un kendisi ve bazı yardımcı araçlar, metriksel büyümenizi izlemenize ve potansiyel sorunları belirlemenize olanak tanır. Düzenli denetimler ve doğru izleme araçlarının kullanımı, sürprizleri en aza indirmenize yardımcı olur.

Bu araçlar ve metrikler sayesinde, Prometheus sunucunuzun sağlık durumunu sürekli olarak gözlemleyebilir ve kardinalite sorunları baş göstermeden önce müdahale edebilirsiniz. Erken tespit, krizi önlemenin anahtarıdır.

Prometheus UI ve Metrikleri İzleme

Prometheus’un kendi web arayüzü ve iç metrikleri, kardinaliteyi izlemek için güçlü bir başlangıç noktasıdır. Aşağıdaki PromQL sorgularını kullanarak sisteminizin durumunu değerlendirebilirsiniz:

• Toplam Zaman Serisi Sayısı:

  prometheus_tsdb_head_series

  Bu metrik, Prometheus’un belleğinde aktif olarak tutulan zaman serilerinin toplam sayısını gösterir. Ani ve sürekli artışlar, yüksek kardinalite sorununa işaret edebilir.

• Etiket Bazında Kardinalite Analizi: Belirli bir metrik için hangi etiketlerin en çok benzersiz değer ürettiğini anlamak için aşağıdaki gibi sorgular kullanılabilir. Bu, sorunun kaynağını belirlemenize yardımcı olur.

  count by (label_name) ({__name__=~".+"})

  Bu sorgu, tüm metrikler genelinde her bir etiketin benzersiz değer sayısını gösterir. Daha spesifik bir metrik için:

  count by (bad_label_name) (your_metric_name)

  Bu sorgu, your_metric_name adlı metrikteki bad_label_name etiketinin benzersiz değer sayısını gösterir.

• scrape_series_added Metriği: Bu metrik, her bir scrape hedefinden alınan ve yeni eklenen zaman serisi sayısını gösterir. Ani artışlar, yeni bir exporter’ın veya uygulamanın yüksek kardinalite metrikleri üretmeye başladığını gösterebilir.

  rate(scrape_series_added[5m])

tsdb Komutu Kullanımı

Prometheus ile birlikte gelen promtool aracı, tsdb komutu altında güçlü analiz yetenekleri sunar. Özellikle promtool tsdb analyze komutu, Prometheus TSDB’sinin içeriğini derinlemesine incelemenizi sağlar.

promtool tsdb analyze --dir=/var/lib/prometheus/data

Bu komutun çıktısı, disk üzerindeki veri bloklarının, bölümlerin ve zaman serilerinin dağılımı hakkında detaylı istatistikler sunar. Özellikle “Label pair cardinality” ve “Series cardinality by label name” bölümleri, hangi etiketlerin ve etiket kombinasyonlarının en yüksek kardinaliteye sahip olduğunu açıkça gösterir. Bu, sorunun en büyük kaynağını hızlıca belirlemenizi sağlar.

Grafana Panoları ile Gözlem

Grafana, Prometheus verilerini görselleştirmek için en popüler araçlardan biridir. Kardinaliteyi izlemek için özel Grafana panoları oluşturmak, durumu sürekli olarak gözlemlemenizi sağlar.

• Toplam Serisi Sayısı Grafiği: prometheus_tsdb_head_series metriğini zamanla gösteren bir grafik oluşturun. Bu, genel eğilimi ve ani yükselişleri gözlemlemenizi sağlar.
• En Yüksek Kardinaliteye Sahip Etiketler Tablosu: Yukarıda bahsedilen count by (label_name) ({__name__=~".+"}) veya count by (bad_label_name) (your_metric_name) gibi sorguları kullanarak, en çok benzersiz değer üreten etiketleri gösteren dinamik bir tablo oluşturabilirsiniz.
• Bellek ve CPU Kullanımı: Prometheus sürecinin bellek ve CPU kullanımını gösteren panolar, kardinalite artışının sistem kaynakları üzerindeki etkisini izlemenize yardımcı olur.

Yüksek Kardinaliteyi Yönetme ve Azaltma Stratejileri

Yüksek kardinalite krizini tespit ettikten sonra, sıra onu yönetmeye ve azaltmaya gelir. Bu, hem metrik üretimini optimize etmeyi hem de Prometheus sunucunuzun gelen veriyi daha verimli işlemesini sağlamayı içerir. Doğru stratejilerle, Prometheus’unuzu hem performanslı hem de maliyet etkin bir şekilde çalıştırabilirsiniz.

Bu stratejilerin uygulanması, sadece mevcut sorunları çözmekle kalmaz, aynı zamanda gelecekteki kardinalite krizlerini de önler. Prometheus altyapınızın sağlığı ve sürdürülebilirliği için bu adımlar hayati öneme sahiptir.

Etiketleri Dikkatli Kullanma

Etiketler, Prometheus’un veri modelinin temelini oluşturur ve sorgu esnekliği sağlar. Ancak etiketlerin yanlış kullanımı yüksek kardinaliteye yol açar. Bu nedenle etiket kullanımında dikkatli olmak gerekmektedir.

• Sınırlı ve Anlamlı Etiketler: Yalnızca anlamlı ve sınırlı sayıda benzersiz değeri olan etiketleri kullanın. Örneğin, instance, job, service, namespace, pod gibi etiketler genellikle faydalıdır.
• Dinamik Değerlerden Kaçının: Kullanıcı kimlikleri, oturum kimlikleri, tam URL yolları (parametreli kısımlar dahil), hata mesajları veya zaman damgaları gibi sürekli değişen veya benzersiz değerleri etiket olarak kullanmaktan kaçının. Bu tür veriler için log sistemleri veya distributed tracing araçları daha uygundur.
• Regex veya Hashing Kullanımı: Eğer bir etiketin değeri gerçekten benzersiz olmak zorundaysa ve izlemek istiyorsanız, bunu relabel_configs ile regex kullanarak daha genel bir forma dönüştürebilir veya değerin hash’ini alarak kardinaliteyi düşürebilirsiniz (ancak bu durumda orijinal değeri kaybedersiniz).

# Örnek: Dinamik bir ID içeren path etiketini genelleme
# Hedef: /api/v1/users/123 -> /api/v1/users/:id
- source_labels: [__metrics_path__]
  regex: '/api/v1/users/[0-9a-fA-F-]+'
  target_label: path
  replacement: '/api/v1/users/:id'
  action: replace

Bu yapılandırma, belirli bir regex kalıbına uyan __metrics_path__ değerlerini path etiketi altında '/api/v1/users/:id' olarak genelleştirir.

Metrik Seviyesini Optimize Etme

Bazen sorun, metriklerin kendisinin çok detaylı olmasından kaynaklanır. Bu durumda metriklerinizi daha üst bir seviyede toplamanız gerekebilir.

• Toplu Metrikler Oluşturma (Aggregation): Uygulama seviyesinde, metrikleri Prometheus’a göndermeden önce toplamak (aggregate) iyi bir yaklaşımdır. Örneğin, her bir isteğin benzersiz ID’sini etiketlemek yerine, belirli bir endpoint için toplam istek sayısını veya ortalama yanıt süresini göndermek daha uygun olacaktır.
• Client-side Filtering: Bazı Prometheus client kütüphaneleri, metrikleri Prometheus’a göndermeden önce belirli etiketleri filtreleme veya dönüştürme yeteneği sunar. Bu, yüksek kardinaliteye neden olan etiketlerin daha kaynağında elenmesini sağlar.
• Özet (Summary) ve Histogram (Histogram) Metrik Türlerini Kullanma: Bu metrik türleri, gözlemlenen değerlerin dağılımını özetlerken, bireysel gözlemlerin kardinalite sorunlarına yol açmasını engeller. Örneğin, bir isteğin tam süresini kaydetmek yerine, önceden tanımlanmış kovalar (buckets) ile histogram kullanmak daha verimlidir.

relabel_configs ile Yeniden Etiketleme

relabel_configs, Prometheus’un scrape hedeflerinden metrikleri alırken etiketleri manipüle etmenizi sağlayan güçlü bir özelliktir. Bu, yüksek kardinaliteyi azaltmak için en etkili yöntemlerden biridir.

• action: drop: Belirli bir regex’e uyan etiketleri veya tüm zaman serilerini düşürmek için kullanılır.

  # Belirli bir etikete sahip tüm serileri düşür
  - source_labels: [bad_label]
    regex: '.*'
    action: drop

• action: replace: Bir etiketin değerini başka bir etiketin veya yakalama grubunun değeriyle değiştirmek için kullanılır. Bu, dinamik değerleri daha genel bir forma dönüştürmek için idealdir.

  # URL yolundaki dinamik ID'yi genelleştir
  - source_labels: [__metrics_path__]
    regex: '/api/v1/products/([0-9]+)/details'
    target_label: path
    replacement: '/api/v1/products/:id/details'
    action: replace

• action: labeldrop: Belirli bir regex’e uyan etiketleri tamamen kaldırmak için kullanılır.

  # 'session_id' veya 'request_id' ile biten tüm etiketleri kaldır
  - regex: '(session_id|request_id)$'
    action: labeldrop

• action: labelkeep: Yalnızca belirli bir regex’e uyan etiketleri tutmak, diğerlerini kaldırmak için kullanılır.

  # Yalnızca 'job', 'instance', 'namespace', 'pod' etiketlerini tut
  - regex: '^(job|instance|namespace|pod)$'
    action: labelkeep

Uzun Vadeli Depolama Çözümleri

Prometheus, kısa vadeli izleme için mükemmeldir. Ancak çok uzun süreli veri saklama veya kümelenmiş (clustered) bir yapı ihtiyacı duyduğunuzda, yüksek kardinalite sorunları daha da büyüyebilir. Bu noktada, Thanos, Mimir veya VictoriaMetrics gibi uzun vadeli depolama çözümleri devreye girer.

Bu çözümler, Prometheus’un remote_write özelliğini kullanarak metrikleri daha ölçeklenebilir ve maliyet etkin bir şekilde depolamanıza olanak tanır. Bu sistemler genellikle yüksek kardinaliteyi daha iyi yönetebilen dağıtık depolama mimarilerine sahiptir. Ancak unutulmamalıdır ki, bu çözümler bile temel kardinalite sorunlarını sihirli bir şekilde ortadan kaldırmaz; yalnızca etkilerini hafifletir ve daha büyük ölçeklerde yönetmenize yardımcı olurlar. Temel sorunları kaynakta çözmek her zaman en iyi yaklaşımdır.

İyi Uygulamalar ve Önleyici Tedbirler

Yüksek kardinalite krizini önlemek, reaktif olmaktan çok proaktif olmayı gerektirir. Metrik üretiminden Prometheus yapılandırmasına kadar her aşamada iyi uygulamaları benimsemek, sağlıklı ve sürdürülebilir bir izleme altyapısının temelini oluşturur.

Bu önleyici tedbirler, kardinalite sorunlarının ortaya çıkışını minimize eder ve izleme sisteminizin güvenilirliğini artırır. Sürekli bir öğrenme ve iyileştirme süreci, bu tür krizlerin üstesinden gelmenin en iyi yoludur.

Metrik İsimlendirme Standartları

Tutarlı ve anlamlı metrik isimlendirme standartları, hem kardinaliteyi yönetmenize hem de metriklerinizi daha okunabilir hale getirmenize yardımcı olur. Prometheus metrik isimlendirme kılavuzlarına uymak, karmaşıklığı azaltır.

• Anlamlı İsimler: Metrik isimleri neyi ölçtüklerini açıkça belirtmelidir (örneğin, http_requests_total yerine http_server_requests_total).
• Birimi Dahil Etme: Eğer mümkünse, metrik adına birimi dahil edin (örneğin, request_duration_seconds).
• Tutarlı Etiketler: Farklı metrikler arasında aynı anlama gelen etiketler için aynı isimleri kullanın (örneğin, tüm hizmetlerde service_name yerine app etiketi kullanmak gibi).

Kod İncelemeleri (Metric Generation Part)

Geliştirme sürecinde metriklerin nasıl üretildiği, kardinalite sorunlarının ana kaynağıdır. Kod incelemeleri (code reviews) sırasında metrik üretimiyle ilgili aşağıdaki noktalara dikkat edilmelidir:

• Dinamik Etiket Kontrolü: Yeni eklenen veya mevcut metriklerde dinamik değerlerin etiket olarak kullanılıp kullanılmadığı kontrol edilmelidir. Özellikle kullanıcı ID’leri, oturum ID’leri gibi yüksek kardinaliteye neden olabilecek değerler aranmalıdır.
• Metrik Türü Seçimi: Metriğin amacına uygun Prometheus metrik türünün (counter, gauge, histogram, summary) kullanıldığına emin olun.
• Örnek Sayısı Kontrolü: Geliştiricilerin belirli bir metrik için çok fazla benzersiz etiket kombinasyonu oluşturmadığından emin olun.

Otomatik Kardinalite Uyarıları

Yüksek kardinalite sorunlarını manuel olarak tespit etmek yerine, Prometheus’un kendisini izleyerek otomatik uyarılar oluşturmak çok daha etkilidir.

• Toplam Seri Sayısı Uyarısı: prometheus_tsdb_head_series metriğinin belirli bir eşiği aşması durumunda uyarı tetikleyin.

  - alert: HighPrometheusSeriesCount
    expr: prometheus_tsdb_head_series > 1000000 # Eşiği ortamınıza göre ayarlayın
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Prometheus'ta aktif zaman serisi sayısı çok yüksek."
      description: "Prometheus sunucusundaki aktif zaman serisi sayısı {{ $value }}'a ulaştı. Yüksek kardinalite sorununu araştırmanız gerekiyor."

• Yeni Seri Ekleme Hızı Uyarısı: rate(scrape_series_added[5m]) metriğinin ani artışları için uyarılar ayarlayın.

  - alert: SuddenSeriesIncrease
    expr: rate(scrape_series_added[5m]) > 5000 # Eşiği ortamınıza göre ayarlayın
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "Prometheus'a yeni eklenen zaman serisi hızında ani artış."
      description: "Son 5 dakikada saniyede {{ $value }} yeni zaman serisi ekleniyor. Bu, potansiyel bir yüksek kardinalite sorununa işaret edebilir."

Eğitim ve Farkındalık

En iyi teknik çözümler bile, onları uygulayan ve kullanan ekiplerin bilgi ve farkındalığı olmadan eksik kalır. Geliştiriciler, operasyon ekipleri ve mimarlar arasında yüksek kardinalite riskleri hakkında farkındalık yaratmak çok önemlidir.

• Eğitim Oturumları: Prometheus’un veri modelini, etiket kullanımının önemini ve yüksek kardinalite risklerini açıklayan düzenli eğitim oturumları düzenleyin.
• Dokümantasyon: Metrik isimlendirme standartları, etiket kullanım kılavuzları ve relabel_configs örnekleri içeren kapsamlı bir dokümantasyon oluşturun.
• Paylaşım ve Tartışma: Farklı ekipler arasında metrik tasarımı ve izleme stratejileri hakkında düzenli toplantılar ve tartışmalar düzenleyerek en iyi uygulamaların yaygınlaşmasını sağlayın.

Sessiz İstilaya Karşı Sürekli Tetikte Olun

Prometheus yüksek kardinalite krizi, sinsi bir düşman gibidir. Başlangıçta fark edilmeyebilir ancak zamanla sistem performansınızı, maliyetlerinizi ve operasyonel verimliliğinizi ciddi şekilde etkileyebilir. Bu blog yazısında ele aldığımız gibi, sorunu anlamak, tespit etmek ve proaktif stratejilerle yönetmek, sağlıklı bir izleme altyapısı için hayati öneme sahiptir.

Metriklerinizi akıllıca tasarlayarak, relabel_configs gibi güçlü araçları kullanarak ve sürekli izleme ile önleyici tedbirler alarak bu sessiz istilaya karşı koyabilirsiniz. Unutmayın, izleme altyapınızın sağlığı, uygulamanızın ve hizmetlerinizin sağlığı kadar önemlidir. Sürekli öğrenmeye ve iyileştirmeye devam edin, böylece Prometheus’unuz her zaman en iyi şekilde çalışır.