Prometheus ve Grafana ile Sistem İzleme Rehberi

İzleme (monitoring), bir sistemin "şu an çalışıyor mu?" sorusundan çok daha fazlasını yanıtlar: ne kadar yavaş, nerede darboğaz var, hangi değişiklikten sonra bozuldu? Prometheus ve Grafana bu soruların çoğunu metrik tabanlı bir yaklaşımla ele alır. Prometheus metrikleri toplar ve sorgulanabilir hale getirir; Grafana bunları görselleştirir ve uyarı akışına bağlar.

Bu rehber, orta seviye geliştiricilerin kendi servisleri için çalışan bir izleme hattı kurmasını hedefler. Sürüm numaraları verilmediği sürece belirli bir sürüme bağlı kalmadan, kavramsal olarak geçerliliğini koruyan adımlar anlatılmıştır.

Önkoşullar

• Linux tabanlı bir sunucu veya yerel geliştirme ortamı (Docker tercih edilir).
• İzlemek istediğiniz en az bir uygulama veya servis.
• Temel HTTP, YAML ve komut satırı bilgisi.
• Metriklerin ne olduğuna dair kavramsal bir fikir (counter, gauge, histogram).

Prometheus ve Grafana'nın kurulum yöntemi ortama göre değişir (ikili dosyalar, paket yöneticisi, Docker, Kubernetes operatörü). Aşağıdaki adımlar kavramsal akışı takip eder; komutlar kurulum yönteminize göre uyarlanmalıdır.

1. Prometheus'un Çalışma Modeli

Prometheus, hedeflerini (target) belirli aralıklarla çeker (pull). Yani uygulamanız Prometheus'a veri göndermek yerine, Prometheus uygulamanızın bir HTTP endpoint'inden metrikleri okur. Bu model, servis keşfi ve yeniden yapılandırma açısından esneklik sağlar.

Temel kavramlar:

• Target: Prometheus'un metrik çektiği bir adres (örneğin host:port).
• Job: Aynı rolü paylaşan target grubu.
• Scrape: Tek bir metrik toplama işlemi.
• Time series: Bir metrik adı ve etiket (label) kombinasyonunun zaman içindeki değerleri.
• Exporter: Mevcut bir sistemin metriklerini Prometheus formatında sunan ara katman (örneğin Node Exporter, sunucu seviyesi metrikler için).

Prometheus'un kendi veri deposu zaman serisi verileri için optimize edilmiştir; uzun vadeli saklama veya yüksek kardinalite için genellikle uzak depolama (remote storage) çözümleriyle birlikte kullanılır.

2. Uygulamadan Metrik Yayınlama

Uygulamanızın /metrics gibi bir endpoint üzerinden Prometheus formatında metrik sunması gerekir. Çoğu dil için resmi veya topluluk istemci kütüphaneleri vardır; bu kütüphaneler metrik kaydını ve formatlamayı üstlenir.

Dikkat edilecek noktalar:

• Endpoint'i dış dünyaya açmayın. Metrikler iç topoloji, sürüm ve kullanım bilgisi sızdırabilir. Endpoint'i yalnızca iç ağa veya Prometheus'un erişebildiği bir adrese bağlayın.
• Kardinalite patlamasından kaçının. Kullanıcı ID, istek ID veya serbest metin gibi yüksek çeşitlilikte değerleri etiket olarak kullanmayın. Her benzersiz etiket kombinasyonu ayrı bir zaman serisi oluşturur ve bellek/bellek dışı depolama maliyetini hızla büyütür.
• Doğru metrik tipini seçin. Sayaç (counter) yalnızca artan değerler için, gösterge (gauge) anlık değerler için, histogram ise dağılım (örneğin gecikme) için uygundur.

3. Prometheus Yapılandırması

Prometheus'un yapılandırması YAML tabanlıdır. Ana dosya genellikle prometheus.yml olarak adlandırılır ve şu bölümleri içerir:

• global: Genel ayarlar (scrape aralığı, değerlendirme aralığı).
• scrape_configs: Hangi target'ların nasıl çekileceği.
• rule_files: Uyarı ve kayıt (recording) kuralları.
• alerting: Uyarıların gönderileceği Alertmanager adresleri.

Tipik bir scrape yapılandırması, bir job adı ve hedef listesi tanımlar. Statik hedefler küçük kurulumlar için yeterlidir; dinamik ortamlarda (Kubernetes, bulut) servis keşfi mekanizmaları tercih edilir.

Yapılandırmayı değiştirdikten sonra Prometheus'un yeniden yüklenmesi gerekir. Çalışan bir Prometheus sürecine yapılandırmayı yeniden okutmanın yolu, sürece SIGHUP sinyali göndermek veya yeniden başlatmaktır. Yeniden başlatma sırasında kısa bir veri toplama boşluğu oluşabileceğini unutmayın.

4. Sorgulama: PromQL Temelleri

PromQL, Prometheus'un sorgu dilidir. Grafana panellerinin çoğu aslında birer PromQL sorgusudur. Temel yapı taşları:

• Anlık vektör: Belirli bir anda değerlendirilen seriler (örneğin http_requests_total).
• Aralık vektörü: Belirli bir zaman aralığındaki seriler (http_requests_total[5m]).
• Fonksiyonlar: rate(), increase(), histogram_quantile() gibi işlemler.
• Toplama: sum(), avg(), max() gibi toplayıcılar; by ve without ile gruplama.

Sayaç metriklerinde oran hesaplamak için rate() kullanılır. Gecikme dağılımlarında yüzdelik dilim (percentile) hesaplamak için histogram metrikleri ve histogram_quantile() birlikte kullanılır. Bu fonksiyonların doğru sonuç vermesi, metrik tipinin doğru seçilmesine bağlıdır.

5. Grafana ile Görselleştirme

Grafana, Prometheus'u bir veri kaynağı (data source) olarak tanımlar ve panellerde PromQL sorgularını çalıştırır. Tipik akış:

1. Grafana'da Prometheus veri kaynağını ekleyin ve erişilebilirliğini test edin.
2. Bir dashboard oluşturun; her panel bir görselleştirme tipi (zaman serisi, tek sayı, tablo, ısı haritası) ve bir sorgu içerir.
3. Panelleri anlamlı gruplara ayırın: trafik, hata oranı, gecikme, kaynak kullanımı.

Dashboard'ları JSON olarak dışa aktarıp sürüm kontrolünde tutmak, ekip içinde tekrarlanabilirliği artırır. Panelleri elle oluşturmak yerine, tanımları kod olarak saklamak uzun vadede bakımı kolaylaştırır.

6. Uyarılar

Prometheus'ta uyarı kuralları, PromQL ifadelerinin belirli bir süre boyunca doğru kalması durumunda tetiklenir. Kuralın for alanı, kısa süreli dalgalanmaların gereksiz uyarı üretmesini engeller.

Uyarı üretimi genellikle Alertmanager'a devredilir; Alertmanager gruplama, susturma (silence) ve yönlendirme gibi işleri üstlenir. İyi bir uyarı kuralı:

• Eyleme dönüktür: Uyarıyı alan kişi ne yapacağını bilir.
• Belirti odaklıdır: "CPU %90" yerine "kullanıcı istekleri başarısız oluyor" gibi kullanıcıyı etkileyen durumları hedefler.
• Gürültü üretmez: Gereksiz sıklıkta tetiklenen uyarılar zamanla görmezden gelinir.

7. Yaygın Hatalar

• Etiketleri yanlış kullanmak: Yüksek kardinaliteye sahip değerleri etiket yapmak, Prometheus'un bellek kullanımını kontrolsüz büyütür.
• Scrape aralığını çok kısa tutmak: Gereğinden sık çekim, hedef sistemlere ve Prometheus'a gereksiz yük bindirir. İhtiyacınıza uygun bir aralık seçin.
• rate() aralığını scrape aralığından küçük seçmek: Bu, yetersiz örnek nedeniyle güvenilmez sonuçlar üretir. Aralık, en az birkaç scrape döngüsünü kapsamalıdır.
• Metrikleri uzun süre saklamayı beklemek: Prometheus'un yerel deposu sınırlıdır; uzun vadeli saklama için ayrı bir çözüm gerekir.
• Uyarı kurallarını test etmeden yayına almak: Yanlış yazılmış bir PromQL ifadesi ya hiç tetiklenmez ya da sürekli tetiklenir.

8. Güvenlik Etkileri

• Metrik endpoint'lerini koruyun. /metrics uçları kimlik doğrulamasız açıldığında iç mimari hakkında bilgi sızdırır. Mümkünse iç ağda tutun veya erişimi kısıtlayın.
• Prometheus ve Grafana arayüzlerini internete açmayın. Bu arayüzler varsayılan olarak kimlik doğrulama gerektirmez. Ters proxy arkasında, kimlik doğrulama ve TLS ile sunun.
• Grafana'da güçlü kimlik doğrulama kullanın. Varsayılan yönetici parolasını değiştirin ve mümkünse harici kimlik sağlayıcı ile entegre edin.
• Etiketlerde hassas veri taşımayın. Kullanıcı adı, e-posta veya token gibi bilgiler metrik etiketlerine sızmamalıdır; bunlar zaman serisi deposunda kalıcı hale gelir.
• Erişim yetkilerini sınırlayın. Grafana panelleri ve veri kaynakları, yalnızca ihtiyaç duyan kişilere açık olsun.

Sonuç

Prometheus ve Grafana ile sağlam bir izleme hattı kurmak, doğru metrikleri yayınlamakla başlar; görselleştirme ve uyarılar bunun üzerine inşa edilir. En kritik kararlar metrik tasarımı (tip ve etiket seçimi), scrape yapılandırması ve uyarı kurallarının eyleme dönük tutulmasıdır. Küçük bir kurulumla başlayıp, sistem büyüdükçe servis keşfi, uzak depolama ve Alertmanager gibi bileşenleri eklemek, izleme altyapısını sürdürülebilir kılar.