Günümüzün karmaşık yazılım mimarilerinde, mikro servislerin ve dağıtık sistemlerin sağlığını anlık olarak takip etmek artık bir lüks değil, zorunlu bir ihtiyaç haline gelmiştir. Bir uygulamanın performansını ölçmek, hataları anında tespit etmek ve sistem kaynaklarının ne durumda olduğunu görmek, işletmelerin kesintisiz hizmet verebilmesi için kritik öneme sahiptir. Tam da bu noktada, açık kaynak dünyasının iki dev aracı olan Prometheus ve Grafana devreye girer. Prometheus, sistemlerinizden ve uygulamalarınızdan metrik adı verilen sayısal verileri toplayan, bu verileri kendi içinde zaman damgalı olarak saklayan ve güçlü bir sorgulama dili sunan bir izleme ve alarm sistemidir. Grafana ise, bu toplanan metrikleri ve diğer birçok veri kaynağından gelen bilgileri görselleştirmenize, anlamlı ve etkileyici panolar oluşturmanıza olanak tanıyan bir gözlemlenebilirlik platformudur. Bu iki araç, birbirlerini mükemmel bir şekilde tamamlayarak ham verileri anlamlandırılabilir, aksiyon alınabilir içgörülere dönüştürür. Prometheus ham petrolü çıkaran ve işleyen bir rafineri gibi düşünülürse, Grafana da bu petrolden elde edilen benzini kullanıcıya anlaşılır bir gösterge panelinde sunan bir otomobil kadranıdır. Bu rehber yazıda, sıfırdan başlayarak Prometheus ve Grafana’nın ne olduğunu, nasıl çalıştığını, aralarındaki ilişkiyi ve sistemlerinizi nasıl izleyebileceğinizi adım adım ve anlaşılır bir dille öğreneceksiniz. Özellikle sistem yöneticileri, DevOps mühendisleri ve yazılım geliştiriciler için vazgeçilmez olan bu ikilinin kurulum mantığından temel konfigürasyona, metrik türlerinden gösterge paneli oluşturmaya kadar tüm detayları keşfedeceğiz. Konuyu daha iyi kavramanız için önemli noktaları madde işaretleriyle destekleyecek, sıkça sorulan soruları yanıtlayacak ve uygulanabilir talimatlar sunacağız. Eğer siz de "Acaba sunucumun CPU kullanımı neden aniden %100’e fırladı?", "Uygulamam saniyede kaç istek alıyor ve cevap süreleri ne durumda?" veya "Veritabanı bağlantı havuzum dolmak üzere mi?" gibi sorulara hızlı ve görsel cevaplar arıyorsanız, doğru yerdesiniz. Prometheus’un çekme tabanlı mimarisi, servis keşfi yetenekleri ve Grafana’nın zengin görselleştirme seçenekleri sayesinde altyapınız üzerinde tam bir hakimiyet kuracaksınız. Hadi başlayalım ve modern izleme dünyasının bu iki süper kahramanını tüm yönleriyle tanıyalım.
- Prometheus’un pull modeli, güvenlik duvarı yapılandırmasını basitleştirir.
- Metrikler, HTTP üzerinden `/metrics` endpoint’inde düz metin formatında sunulur.
- Veri modeli `metric_name{label1="value1", label2="value2"} value [timestamp]` şeklindedir.
- PromQL ile anlık ve aralıklı vektör sorguları yaparak karmaşık hesaplamalar gerçekleştirilebilir.
- Alarm kuralları, bir ifade belirli bir eşiği aştığında tetiklenen özel PromQL sorgularıdır.
- AlertManager’ın gruplandırma özelliği, büyük bir kesintide yüzlerce benzer alarm yerine tek bir özet bildirim almanızı sağlar.
Prometheus’un topladığı veriler ham ve saf altın değerindedir, ancak bu verileri insan zihninin anında kavrayabileceği görsel şaheserlere dönüştüren usta bir kuyumcuya ihtiyaç vardır: işte Grafana tam olarak bu role bürünür. Grafana, Prometheus’u da içeren onlarca veri kaynağına bağlanabilen, tamamen özelleştirilebilir panolar oluşturmanızı sağlayan açık kaynaklı bir görselleştirme aracıdır. Grafana’yı Prometheus ile entegre etmek, teknik olarak son derece basit olmasına rağmen, sistemlerinizin gözlemlenebilirliğini bir üst boyuta taşıyan en kritik adımdır. Bu entegrasyonu sağlamak için öncelikle Grafana’nın kurulu olduğu sunucuda, sol menüden “Configuration” altındaki “Data Sources” bölümüne giderek yeni bir veri kaynağı eklemeniz gerekir. Karşınıza çıkan listeden “Prometheus”u seçtiğinizde, yapmanız gereken en temel ayar, Prometheus sunucunuzun URL adresini (örneğin `http://localhost:9090`) doğru bir şekilde belirtmekten ibarettir. Bu adresi girdikten sonra “Save & Test” butonuna tıkladığınızda, Grafana Prometheus’a bağlanacak ve bağlantının başarılı olduğuna dair yeşil bir onay mesajı göreceksiniz. Artık veri kaynağınız hazırdır ve panolarınızı oluşturmaya başlayabilirsiniz. Bu noktada, pek çok kişi sıfırdan bir pano inşa etmeye çalışmak yerine, Grafana’nın resmi ve topluluk tarafından oluşturulmuş hazır pano kütüphanesini kullanmanın büyük bir zaman kazandırdığını hemen keşfeder. Örneğin, bir Linux sunucusunu izlemek için popüler olan Node Exporter Full (ID: 1860) panosunu veya bir Kubernetes kümesini izlemek için Kubernetes cluster monitoring (via Prometheus) (ID: 315) panosunu, sadece ID numarasını girerek birkaç saniye içinde içe aktarabilirsiniz.
Bu entegrasyonun gerçek önemi, Prometheus’un sunduğu PromQL dilinin Grafana’nın sorgu editöründe hayat bulmasıyla ortaya çıkar. Grafana, sizi ham bir terminal ekranına mahkum etmez; bunun yerine, yazdığınız bir PromQL sorgusunun sonucunu anında bir grafik, bir gösterge (gauge), bir ısı haritası veya bir tablo olarak görmenizi sağlar. Örneğin, bir web uygulamasının saniyedeki ortalama istek sayısını gösteren `rate(http_requests_total[5m])` sorgusunu yazdığınızda, Grafana bunu zaman ekseninde değişen bir çizgi grafiğe dönüştürür. Sadece bununla kalmaz, bu grafiğin üzerine, istek sayısı belirli bir eşiğin üzerine çıktığında rengini kırmızıya çeviren görsel eşikler ekleyebilir veya beş dakika önceki değere göre yüzdesel değişimi gösteren bir istatistik paneli yerleştirebilirsiniz. Değişkenler (variables) özelliği, Grafana panolarını interaktif hale getirmenin en güçlü yoludur. Bir pano üzerinde, izlemek istediğiniz sunucuyu, servis adını veya Kubernetes namespace’ini seçebileceğiniz açılır menüler oluşturabilirsiniz. Bu sayede aynı panoyu, tek bir tıklama ile tüm üretim ortamından geliştirme ortamına, oradan da tek bir uygulama örneğine kadar dinamik olarak filtreleyebilirsiniz. Bu entegrasyon sırasında dikkat edilmesi gereken en önemli husus, zaman uyumudur; Grafana ve Prometheus sunucularının saatlerinin senkronize olması, özellikle dar zaman aralıklarındaki sorgularda tutarsız verilere yol açmaması için elzemdir. Sonuç olarak Grafana, Prometheus’un beyni ise onun gözü, kulağı ve en önemlisi sesidir; sisteminizin size anlatmak istediği hikayeyi görselleştirir ve anlaşılır kılar.
- Grafana, Prometheus’un yanı sıra InfluxDB, Elasticsearch, MySQL ve daha onlarca veri kaynağını destekler.
- “Explore” sekmesi, panoya eklemeden önce PromQL sorgularınızı hızlıca test edip keşfetmeniz için idealdir.
- Bir panodaki her bir grafik, metin veya tablo öğesine “panel” adı verilir ve her panel bağımsız olarak yapılandırılır.
- Zaman aralığı seçici, son 5 dakikadan son 5 yıla kadar verileri anında görüntülemenizi sağlar.
- Grafana, panoların JSON modelini dışa ve içe aktarmaya izin verdiği için, altyapıyı kod olarak (IaC) yönetme pratiklerine mükemmel uyum sağlar.
Üçüncü ve en karmaşık ama bir o kadar da güçlü olan tür **Histogram**’dır. Histogram, bir olayın (örneğin bir HTTP isteğinin) büyüklüğünü veya süresini önceden tanımlanmış aralıklara (bucket) bölerek gözlemler. Bir Histogram metriği oluşturduğunuzda, aslında arka planda üç ayrı veri serisi yaratır: her bucket’a düşen toplam gözlem sayısı (`_bucket`), tüm gözlemlerin toplam değeri (`_sum`) ve toplam gözlem sayısı (`_count`). Bu yapı sayesinde, örneğin bir API’nin yanıt süresinin 0.3 saniyeden uzun süren isteklerin yüzdesini değil, doğrudan 95. yüzdelik (percentile) değerini `histogram_quantile()` fonksiyonu ile hesaplayabilirsiniz. Bu, ortalama değerin yanıltıcı olabileceği uç değerlerin yoğun olduğu sistemlerde performansı anlamak için hayati önem taşır. Dördüncü ve son tür olan **Summary** ise Histogram’a çok benzer, ancak temel bir farkla: yüzdelik hesaplaması sunucu tarafında değil, istemci (uygulama) tarafında yapılır. Yani uygulamanız, belirli yüzdelik değerleri (örneğin 0.5, 0.9, 0.99) anlık olarak hesaplar ve doğrudan bir metrik olarak sunar. Bu, sunucu tarafında herhangi bir hesaplamaya gerek kalmadan o değerleri doğrudan okuyabileceğiniz anlamına gelir. Ancak, Summary’nin en büyük dezavantajı, birden fazla uygulama örneğinden gelen verileri toplayıp genel bir yüzdelik hesaplayamamanızdır; çünkü istemciler kendi yerel yüzdelerini hesaplar ve bu değerler matematiksel olarak birleştirilemez. Bu yüzden, çoğu durumda, özellikle yatay ölçeklenen mikro servis mimarilerinde, verileri sunucu tarafında birleştirip esnek sorgulamalar yapmaya izin veren Histogram kullanımı genellikle daha tavsiye edilir.
- **Counter:** `_total` eki ile isimlendirilir. `rate()` ve `increase()` fonksiyonları ile kullanılır.
- **Gauge:** `set()`, `inc()`, `dec()` metodlarına sahiptir. Anlık durum görüntülemede kullanılır.
- **Histogram:** Varsayılan bucket’lar yerine, sisteminizin beklenen değer aralıklarına uygun özel bucket’lar tanımlamak, doğru yüzdelik hesapları için kritiktir.
- **Summary:** Kullanımı daha kolaydır ancak çapraz örnek birleştirme yapılamaz.
- Metrik isimlendirmesinde anlamlı ve tutarlı bir standart izlemek, büyük ölçekli sistemlerde karışıklığı önler.
Prometheus’un Temel Mimarisi ve Çalışma Prensibi Nasıldır?
Prometheus’u anlamanın en iyi yolu, onun diğer geleneksel izleme araçlarından farklı olan çekme (pull) tabanlı mimarisini kavramaktan geçer. Geleneksel sistemlerde, izlenen sunucular veya uygulamalar, merkezi bir izleme sunucusuna veri gönderirken, Prometheus tam tersi bir yaklaşımla çalışır ve belirli aralıklarla hedeflerine bağlanarak metrikleri kendisi toplar. Bu hedefler, üzerinde metrikleri belirli bir formatta (genellikle HTTP üzerinden) sunan bir sunucu uygulaması çalıştıran herhangi bir servis olabilir. Bu işleyiş, ağ yapılandırması açısından büyük avantaj sağlar çünkü izlenen birimlerin Prometheus sunucusunun adresini bilmesine gerek yoktur; sadece metriklerini belirli bir endpoint’te yayınlamaları yeterlidir. Prometheus’un ana omurgasını oluşturan Prometheus Server, **retrieval** bileşeni sayesinde bu endpoint’leri (genellikle `/metrics`) düzenli olarak kazır ve topladığı verileri yerel bir zaman serisi veritabanına (TSDB) yazar. Toplanan her metrik, bir isim, bir değer, bir zaman damgası ve isteğe bağlı etiketlerden (labels) oluşan çok boyutlu bir veri modeliyle saklanır. İşte bu etiketler, Prometheus’u bu kadar güçlü kılan anahtar-kilit (key-value) çiftleridir. Örneğin, `http_requests_total{method="GET", status="200", endpoint="/api/users"}` gibi bir metrik, sadece sayısal bir değer değil, aynı zamanda hangi HTTP metodu, hangi durum kodu ve hangi uç nokta için olduğunu söyleyen bağlamsal bilgiler içerir. Bu sayede PromQL (Prometheus Query Language) adı verilen güçlü sorgulama dilini kullanarak çok spesifik analizler yapabilirsiniz; tüm başarısız istekleri filtreleyebilir, belirli bir uç noktanın 99. yüzdelik gecikme süresini hesaplayabilir veya istek sayılarındaki artış oranını görebilirsiniz. Prometheus’un bir diğer kritik bileşeni de AlertManager’dır. Sunucu, belirlediğiniz kurallara göre alarm durumlarını tespit eder, ancak bu alarmları doğrudan iletmek yerine AlertManager’a gönderir. AlertManager, gelen bu ham alarmları alır; tekrarlayan alarmları bastırma (deduplication), benzer alarmları gruplandırma (grouping) ve belirli zamanlarda sessize alma (silencing) gibi akıllı işlemlerden geçirdikten sonra e-posta, Slack, PagerDuty gibi kanallar üzerinden doğru kişilere ulaştırır. Bu mimari, alarm yorgunluğunu önlemek için hayati öneme sahiptir. Ayrıca, kısa ömürlü işler (batch jobs) için tasarlanmış bir Pushgateway bileşeni de mevcuttur; bu işler, tamamlanmadan önce metriklerini Pushgateway’e iterek Prometheus’un bu verileri çekmesini sağlar. Prometheus’un tek başına bir sistem olarak, tek bir sunucu üzerinde milyonlarca zaman serisini işleyebilecek kadar verimli ve bağımsız çalışacak şekilde tasarlandığını unutmamak gerekir; bu da onu özellikle mikro servis mimarileri ve Kubernetes gibi dinamik ortamlar için ideal bir seçim haline getirir.- Prometheus’un pull modeli, güvenlik duvarı yapılandırmasını basitleştirir.
- Metrikler, HTTP üzerinden `/metrics` endpoint’inde düz metin formatında sunulur.
- Veri modeli `metric_name{label1="value1", label2="value2"} value [timestamp]` şeklindedir.
- PromQL ile anlık ve aralıklı vektör sorguları yaparak karmaşık hesaplamalar gerçekleştirilebilir.
- Alarm kuralları, bir ifade belirli bir eşiği aştığında tetiklenen özel PromQL sorgularıdır.
- AlertManager’ın gruplandırma özelliği, büyük bir kesintide yüzlerce benzer alarm yerine tek bir özet bildirim almanızı sağlar.
Grafana’yı Prometheus ile Entegre Etmenin Adımları ve Önemi Nedir?
Prometheus’un topladığı veriler ham ve saf altın değerindedir, ancak bu verileri insan zihninin anında kavrayabileceği görsel şaheserlere dönüştüren usta bir kuyumcuya ihtiyaç vardır: işte Grafana tam olarak bu role bürünür. Grafana, Prometheus’u da içeren onlarca veri kaynağına bağlanabilen, tamamen özelleştirilebilir panolar oluşturmanızı sağlayan açık kaynaklı bir görselleştirme aracıdır. Grafana’yı Prometheus ile entegre etmek, teknik olarak son derece basit olmasına rağmen, sistemlerinizin gözlemlenebilirliğini bir üst boyuta taşıyan en kritik adımdır. Bu entegrasyonu sağlamak için öncelikle Grafana’nın kurulu olduğu sunucuda, sol menüden “Configuration” altındaki “Data Sources” bölümüne giderek yeni bir veri kaynağı eklemeniz gerekir. Karşınıza çıkan listeden “Prometheus”u seçtiğinizde, yapmanız gereken en temel ayar, Prometheus sunucunuzun URL adresini (örneğin `http://localhost:9090`) doğru bir şekilde belirtmekten ibarettir. Bu adresi girdikten sonra “Save & Test” butonuna tıkladığınızda, Grafana Prometheus’a bağlanacak ve bağlantının başarılı olduğuna dair yeşil bir onay mesajı göreceksiniz. Artık veri kaynağınız hazırdır ve panolarınızı oluşturmaya başlayabilirsiniz. Bu noktada, pek çok kişi sıfırdan bir pano inşa etmeye çalışmak yerine, Grafana’nın resmi ve topluluk tarafından oluşturulmuş hazır pano kütüphanesini kullanmanın büyük bir zaman kazandırdığını hemen keşfeder. Örneğin, bir Linux sunucusunu izlemek için popüler olan Node Exporter Full (ID: 1860) panosunu veya bir Kubernetes kümesini izlemek için Kubernetes cluster monitoring (via Prometheus) (ID: 315) panosunu, sadece ID numarasını girerek birkaç saniye içinde içe aktarabilirsiniz.
Bu entegrasyonun gerçek önemi, Prometheus’un sunduğu PromQL dilinin Grafana’nın sorgu editöründe hayat bulmasıyla ortaya çıkar. Grafana, sizi ham bir terminal ekranına mahkum etmez; bunun yerine, yazdığınız bir PromQL sorgusunun sonucunu anında bir grafik, bir gösterge (gauge), bir ısı haritası veya bir tablo olarak görmenizi sağlar. Örneğin, bir web uygulamasının saniyedeki ortalama istek sayısını gösteren `rate(http_requests_total[5m])` sorgusunu yazdığınızda, Grafana bunu zaman ekseninde değişen bir çizgi grafiğe dönüştürür. Sadece bununla kalmaz, bu grafiğin üzerine, istek sayısı belirli bir eşiğin üzerine çıktığında rengini kırmızıya çeviren görsel eşikler ekleyebilir veya beş dakika önceki değere göre yüzdesel değişimi gösteren bir istatistik paneli yerleştirebilirsiniz. Değişkenler (variables) özelliği, Grafana panolarını interaktif hale getirmenin en güçlü yoludur. Bir pano üzerinde, izlemek istediğiniz sunucuyu, servis adını veya Kubernetes namespace’ini seçebileceğiniz açılır menüler oluşturabilirsiniz. Bu sayede aynı panoyu, tek bir tıklama ile tüm üretim ortamından geliştirme ortamına, oradan da tek bir uygulama örneğine kadar dinamik olarak filtreleyebilirsiniz. Bu entegrasyon sırasında dikkat edilmesi gereken en önemli husus, zaman uyumudur; Grafana ve Prometheus sunucularının saatlerinin senkronize olması, özellikle dar zaman aralıklarındaki sorgularda tutarsız verilere yol açmaması için elzemdir. Sonuç olarak Grafana, Prometheus’un beyni ise onun gözü, kulağı ve en önemlisi sesidir; sisteminizin size anlatmak istediği hikayeyi görselleştirir ve anlaşılır kılar.
- Grafana, Prometheus’un yanı sıra InfluxDB, Elasticsearch, MySQL ve daha onlarca veri kaynağını destekler.
- “Explore” sekmesi, panoya eklemeden önce PromQL sorgularınızı hızlıca test edip keşfetmeniz için idealdir.
- Bir panodaki her bir grafik, metin veya tablo öğesine “panel” adı verilir ve her panel bağımsız olarak yapılandırılır.
- Zaman aralığı seçici, son 5 dakikadan son 5 yıla kadar verileri anında görüntülemenizi sağlar.
- Grafana, panoların JSON modelini dışa ve içe aktarmaya izin verdiği için, altyapıyı kod olarak (IaC) yönetme pratiklerine mükemmel uyum sağlar.
Hangi Metrik Türleri Vardır ve Bunları Prometheus’ta Nasıl Kullanırız?
Prometheus’ta veriyi doğru şekilde modellemek ve anlamlı sorgular yazabilmek için, istemci kütüphanelerinin sunduğu dört temel metrik türünü derinlemesine kavramak zorunludur. Bu türler, bir uygulamanın iç durumunu farklı yönleriyle temsil eder ve her birinin kendine özgü kullanım alanı ve PromQL fonksiyonu bulunur. İlk ve en basit metrik türü **Counter**’dır. Adından da anlaşılacağı gibi, yalnızca artan ve asla azalmayan (süreç yeniden başlatılmadığı sürece) bir sayaçtır. Toplam işlenen istek sayısı, tamamlanan görevler, oluşan hata sayısı veya gönderilen bayt miktarı gibi kümülatif olarak biriken değerler için idealdir. Bir Counter’ın ham değeri çoğu zaman tek başına anlamlı değildir; asıl gücü, `rate()` fonksiyonu ile bir zaman dilimindeki saniyelik artış hızını hesapladığınızda ortaya çıkar. Örneğin, `rate(api_errors_total[5m])` sorgusu, son 5 dakikadaki saniye başına düşen hata oranını size verir. İkinci tür olan **Gauge**, anlık olarak artıp azalabilen bir değeri temsil eder; tıpkı bir arabanın yakıt göstergesi gibidir. Mevcut bellek kullanımı, CPU sıcaklığı, eşzamanlı aktif kullanıcı sayısı veya bir kuyruktaki bekleyen iş sayısı gibi metrikler için kullanılır. Bir Gauge’ın değerini doğrudan sorgulayarak sisteminizin o anki durumunu anlık olarak görebilirsiniz.Üçüncü ve en karmaşık ama bir o kadar da güçlü olan tür **Histogram**’dır. Histogram, bir olayın (örneğin bir HTTP isteğinin) büyüklüğünü veya süresini önceden tanımlanmış aralıklara (bucket) bölerek gözlemler. Bir Histogram metriği oluşturduğunuzda, aslında arka planda üç ayrı veri serisi yaratır: her bucket’a düşen toplam gözlem sayısı (`_bucket`), tüm gözlemlerin toplam değeri (`_sum`) ve toplam gözlem sayısı (`_count`). Bu yapı sayesinde, örneğin bir API’nin yanıt süresinin 0.3 saniyeden uzun süren isteklerin yüzdesini değil, doğrudan 95. yüzdelik (percentile) değerini `histogram_quantile()` fonksiyonu ile hesaplayabilirsiniz. Bu, ortalama değerin yanıltıcı olabileceği uç değerlerin yoğun olduğu sistemlerde performansı anlamak için hayati önem taşır. Dördüncü ve son tür olan **Summary** ise Histogram’a çok benzer, ancak temel bir farkla: yüzdelik hesaplaması sunucu tarafında değil, istemci (uygulama) tarafında yapılır. Yani uygulamanız, belirli yüzdelik değerleri (örneğin 0.5, 0.9, 0.99) anlık olarak hesaplar ve doğrudan bir metrik olarak sunar. Bu, sunucu tarafında herhangi bir hesaplamaya gerek kalmadan o değerleri doğrudan okuyabileceğiniz anlamına gelir. Ancak, Summary’nin en büyük dezavantajı, birden fazla uygulama örneğinden gelen verileri toplayıp genel bir yüzdelik hesaplayamamanızdır; çünkü istemciler kendi yerel yüzdelerini hesaplar ve bu değerler matematiksel olarak birleştirilemez. Bu yüzden, çoğu durumda, özellikle yatay ölçeklenen mikro servis mimarilerinde, verileri sunucu tarafında birleştirip esnek sorgulamalar yapmaya izin veren Histogram kullanımı genellikle daha tavsiye edilir.
- **Counter:** `_total` eki ile isimlendirilir. `rate()` ve `increase()` fonksiyonları ile kullanılır.
- **Gauge:** `set()`, `inc()`, `dec()` metodlarına sahiptir. Anlık durum görüntülemede kullanılır.
- **Histogram:** Varsayılan bucket’lar yerine, sisteminizin beklenen değer aralıklarına uygun özel bucket’lar tanımlamak, doğru yüzdelik hesapları için kritiktir.
- **Summary:** Kullanımı daha kolaydır ancak çapraz örnek birleştirme yapılamaz.
- Metrik isimlendirmesinde anlamlı ve tutarlı bir standart izlemek, büyük ölçekli sistemlerde karışıklığı önler.
Yorumlar
Yorum Gönder
1.Görüşleriniz bizim için önemlidir.
2. Konu dışı sorularınız için İletişim sayfasından ulaşabilirsiniz.