Sorunları Yakalayan Prometheus Grafana Entegrasyonu
6 Ekim 2026 tarihinde yayımlandı
Prometheus Grafana entegrasyonu, sunucu metriklerinize yararlı bir görev kazandırır: nelerin değiştiğini gösterir, bir sınır kesintiye yol açmadan önce sizi uyarır ve bir hizmet yavaşladığında kanıt sunar. Prometheus sayıları toplar ve depolar. Grafana ise bunları, ekibinizin bir bakışta anlayabileceği panolara ve uyarılara dönüştürür. Birlikte, tahmin yürütmenin yerini daha sakin bir operasyonel bakış açısına bırakırlar.
Bir VPS, özel sunucu, SaaS platformu veya yoğun bir çevrimiçi mağaza için bu kurulum en çok bir şeyler bozulmadan önce işe yarar. Diskin dolması, belleğin tükenmesi, yanıt sürelerinin uzaması veya veritabanı bağlantı havuzunun sınıra yaklaşması genellikle önce metriklerde belirti verir. Hizmet şu anda çalışıyor olabilir, ancak grafik hikâyenin devamını şimdiden anlatıyordur.
Prometheus ve Grafana'nın Üstlendiği Görevler
Prometheus, zaman serisi izleme sistemidir. Hedeflerden düzenli aralıklarla metrikleri çeker, ölçümleri etiketler ve sorgulanabilir durumda tutar. CPU kullanımı, bellek baskısı, istek hızları, gecikme ve dosya sistemi kapasitesi gibi metrikler modeline doğal olarak uyduğundan sunucu ve uygulama izleme için özellikle elverişlidir.
Grafana, görselleştirme ve uyarı katmanıdır. Veri kaynağı olarak Prometheus'a bağlanır, PromQL sorgularından paneller oluşturmanıza ve bu panelleri panolar hâlinde düzenlemenize olanak tanır. İyi bir Grafana panosunun süslü olması gerekmez. Amacı pratik soruları hızla yanıtlamaktır: Sunucu sağlıklı mı? Hangi hizmet kaynakları kullanıyor? Performans kötüleşiyor mu? Saat 14.00'teki dağıtım bir şeyi değiştirdi mi?
Prometheus uyarı kurallarını kendisi değerlendirebilir; Alertmanager ise bildirimleri gruplar, yönlendirir ve susturur. Grafana, pano sorgularından da uyarılar oluşturabilir. Her iki yaklaşım da işe yarayabilir. Altyapı genelinde geçerli ve kodla yönetilen uyarılar için Prometheus kuralları ile Alertmanager'ı kullanmak genellikle standartlaştırmayı kolaylaştırır. Belirli bir hizmete odaklanan pano için Grafana tarafından yönetilen uyarılar kullanışlı olabilir. Aynı koşul için her ikisini de çalıştırmaktan kaçının; aksi takdirde sabah 3'te yinelenen bildirimler alabilirsiniz. planınızın bir parçası olabilir.
Prometheus Grafana Entegrasyonu: Uygulamaya Yönelik Bir Mimari
Makul bir başlangıç mimarisi basittir. Mümkün olduğunda Prometheus ve Grafana'yı izlenen sunucudan veya uygulamadan ayrı bir izleme VPS'sinde çalıştırın. İzlenen sistemlere dışa aktarıcılar kurun. Dışa aktarıcılar, metrikleri bir HTTP uç noktasında sunar ve Prometheus bunları belirli aralıklarla tarar.
Linux sunucularında ilk tercih genellikle Node Exporter'dır. CPU, bellek, yük ortalaması, disk kullanımı, ağ trafiği ve dosya sistemi istatistikleri dahil olmak üzere ana makine düzeyinde ölçümleri sunar. Veritabanı dışa aktarıcıları MySQL, PostgreSQL, Redis ve diğer hizmetler için görünürlük sağlayabilir. Uygulama metrikleri yerel bir Prometheus uç noktasından, bir çerçeve kitaplığından veya dikkatle seçilmiş bir dışa aktarıcıdan gelebilir.
Temel veri akışı basittir:
- Bir dışa aktarıcı, sunucu, veritabanı veya uygulamadaki metrikleri sunar.
- Prometheus uç noktayı tarar ve zaman serisi verilerini depolar.
- Grafana, Prometheus'u sorgular ve sonuçları görüntüler.
- Uyarı kuralları eşikleri veya anormal davranışları değerlendirir ve seçilen kanal üzerinden bildirim gönderir.
Bu basit görünüm önemlidir; sorun gidermeyi de kolaylaştırır. Grafana paneli boşsa Grafana'nın Prometheus'u sorgulayabildiğini kontrol edin. Prometheus'ta veri yoksa hedefler sayfasını ve dışa aktarıcı uç noktasını kontrol edin. Hedef çalışmıyorsa ağ erişimini, güvenlik duvarı kurallarını, hizmet durumunu ve dışa aktarıcı yapılandırmasını kontrol edin. Günlükler genellikle artık aynı hikâyeyi anlatıyordur.
Eyleme dönüştürülebilir metriklerle başlayın
Mevcut tüm metrikleri toplamak gürültüye, depolama kullanımına ve kimsenin açmadığı panolara yol açar. Açık bir operasyonel kararı destekleyen metriklerle başlayın. Çoğu sunucu için bu; CPU kullanımı ve yükü, kullanılabilir bellek, takas etkinliği, disk alanı ve inode kullanımı, disk G/Ç gecikmesi, ağ hataları, süreç kullanılabilirliği ve sistem çalışma süresi anlamına gelir.
Web uygulamalarında uygun olduğu durumlarda HTTP istek hızını, hata oranını, istek süresini, etkin bağlantıları ve kuyruk uzunluğunu ekleyin. Veritabanlarında bağlantı sayısını, yavaş sorguları, çoğaltma durumunu, önbellek verimliliğini, kilitleri ve depolama artışını izleyin. Bir e-ticaret sitesi ödeme hatalarını ve veritabanı gecikmesini yakından izlemek isteyebilir; bir geliştirme ajansı ise istemci ortamlarının çalışma süresine ve yedekleme başarısına öncelik verebilir. Önemli olan, hangi panonun daha etkileyici göründüğü değil, iş yüküdür.
Etiketleri dikkatli kullanın. Etiketler ortam, sunucu rolü, müşteri, bölge veya uygulamaya göre filtreleme yapmayı mümkün kılar. Kullanıcı kimlikleri, sipariş kimlikleri, oturum belirteçleri veya dinamik parametreler içeren istek yolları gibi sürekli değişen değerler içerdiklerinde çok sayıda farklı zaman serisi de oluşturabilirler. Yüksek kardinaliteli etiketler, Prometheus'u gerekenden çok daha fazla çalıştırmanın sinsi bir yoludur.
Yeni Risk Yaratmadan Veri Toplamayı Kurun
Prometheus'un yapılandırmasında bir hedef listesine ihtiyacı vardır. Temel bir Node Exporter hedefi şöyle görünebilir:
``\`yaml scrape_configs:
- job_name: node
static_configs:
- targets: ['10.0.0.15:9100']
labels: environment: production role: web ``\`
Küçük bir ortamda statik hedefler açık ve güvenilirdir. Altyapı büyüdükçe hedefler otomatik olarak eklenip kaldırıldığından hizmet keşfi genellikle daha uygun bir seçenektir. Hangi yöntemi seçerseniz seçin, mümkün olduğunda izleme uç noktalarını gizli tutun. Bir panonun veriye ihtiyacı var diye dışa aktarıcı bağlantı noktalarını genel internete açık bırakmayın.
Uygun olduğunda özel ağ, güvenlik duvarı izin listeleri, VPN veya kimlik doğrulamalı ters vekil sunucu kullanın. Metrikler güvenilmeyen ağlardan geçerken trafiği şifreleyin. Prometheus metrikleri ana makine adlarını, dahili hizmet adlarını, iş yükü kalıplarını ve sürüm ayrıntılarını açığa çıkarabilir. Bunlar operasyonel verilerdir, herkese açık süsler değil.
Saklama süresini olay yönetimi ve kapasite planlama ihtiyaçlarınıza göre belirleyin. Küçük kurulumların çoğunda yakın zamandaki değişiklikleri ve kısa vadeli eğilimleri belirlemek için on beş ila otuz gün yeterlidir. Daha uzun saklama süresi mevsimsel talebi ve kademeli kapasite artışını değerlendirmeye yardımcı olur, ancak disk gereksinimlerini artırır. Uzun vadeli geçmiş raporları için, Grafana'yı çalıştıran aynı VPS'de sınırsız saklama süresi belirlemek yerine uzak depolamayı değerlendirin.
Hızlı Tanılama için Panolar Oluşturun
Önce genel bakış panosu oluşturun. Katalogdaki her metriği değil, en önemli sistemlerin durumunu göstermelidir. Yararlı bir genel bakışta genellikle sunucu kullanılabilirliği, CPU, bellek, disk kullanımı, ağ trafiği, HTTP hata oranı ve istek gecikmesi yer alır. Bir panonun kopyala-yapıştır müzesine dönüşmeden birden fazla sisteme hizmet verebilmesi için ana makine, ortam ve hizmet değişkenlerini kullanın.
Ardından hizmete özel panolar oluşturun. Bir veritabanı panosunun, web sunucusu panosundan farklı panellere ihtiyacı vardır. Arka plan çalışanı panosunda kuyruk uzunluğu, işlem süresi, yeniden denemeler ve başarısızlıklar gösterilmelidir. Panel başlıklarını açık tutun: “/var içinde boş disk alanı”, “HTTP 5xx oranı” ve “PostgreSQL etkin bağlantıları”, en kötü anda ne anlama geldiğini çözmeniz gereken yaratıcı adlardan daha iyidir.
Dağıtımları, bakım aralıklarını ve yapılandırma değişikliklerini işaretlemek için açıklama eklemeye değer. Bir sürüm yayınlandıktan kısa süre sonra gecikme artarsa açıklama, şüpheli bir grafiği yararlı bir değerlendirmeye dönüştürür. Nedenselliği kanıtlamaz, ancak inceleme için makul bir başlangıç noktası sunar.
Her Sayıya Değil, Belirtilere Göre Uyarı Verin
Bir sunucuda %80 CPU uyarısı yararlı olabilirken, başka bir sunucuda anlamsız olabilir. Toplu işleme düğümü tasarlandığı gibi saatlerce yoğun çalışabilir; API gecikmesindeki ani artış ise CPU kullanımı orta düzeyde olsa bile müşterileri hemen etkileyebilir. Uyarı kuralları etkiyi ve beklenen davranışı yansıtmalıdır.
Yanıt gerektiren durumlar için uyarılarla başlayın: dışa aktarıcıya veya hizmete ulaşılamaması, disk alanının yakında tükenmesi, yedekleme işlerinin başarısız olması, bellek baskısının takas kullanımına yol açması, hata oranlarının artması, sertifikaların son kullanma tarihinin yaklaşması veya veritabanı çoğaltmasının sağlıksız olması. Kısa süreli artışların birini gereksiz yere uyandırmasını önlemek için bir süre eşiği belirleyin. Örneğin, disk alanının on beş dakika boyunca düşük kalması genellikle beş saniyelik bir düşüşten daha fazla eylem gerektirir.
Her uyarı üç soruyu yanıtlamalıdır: Sorun nedir, nerede yaşanıyor ve müdahale edecek kişi önce neyi kontrol etmeli? Uyarı açıklamasına sunucu adını, ortamı, hizmeti ve kısa bir müdahale kılavuzu talimatını ekleyin. Yirmi sunucu varken ve biri mesajı telefonundan okuyorken “Disk alanı az” demek yeterli değildir.
Uyarıları susturma ve bakım aralıkları, sorunları gizlemenin değil, sağlıklı uyarı yönetiminin bir parçasıdır. Planlı çalışmalar için kullanın ve çalışma bittiğinde kaldırın. Unutulmuş bir susturma kuralının zamanlaması hiç iyi değildir.
İzleme Yığınını Bakımı Kolay Tutun
Panoları, uyarı kurallarını ve Prometheus yapılandırmasını operasyonel varlıklar olarak ele alın. Yedeklerini alın, olaylardan sonra gözden geçirin ve ekibinizin güvenli biçimde kullanabildiği yerlerde yapılandırmayı sürüm denetiminde saklayın. Uyarıları ara sıra test edin. Hiç test edilmemiş bir bildirim kanalı, yalnızca iyimser bir varsayımdan ibarettir.
İzleme sistemini de izleyin. Prometheus'un yeterli belleğe ve depolama alanına, Grafana'nın yapılandırma ve veritabanı yedeklerine, dışa aktarıcıların ise güvenlik duvarı veya ağ değişikliklerinden sonra da erişilebilir durumda kalmaya ihtiyacı vardır. Tarama süresini, başarısız taramaları, depolama kapasitesini ve uyarı iletimindeki başarısızlıkları izleyin. İzleme sunucusu aşırı yüklenirse grafikleri sakin görünebilir; oysa sunucu ihtiyacınız olan kanıtları sessizce kaçırıyor olabilir.
Altyapılarının yanı sıra operasyonel destek isteyen ekipler için kodu.cloud, işiniz açısından önemli metriklerle görünürlüğü korurken izlenen VPS ve sunucu ortamlarının yönetilmesine destek olabilir. Amaç, izlemeyi gizemli hâle getirmek değildir. Amaç, bir sonraki sorunu daha küçük, daha erken ve daha kolay yönetilebilir hâle getirmektir.
İyi ayarlanmış bir Prometheus ve Grafana kurulumu olayları ortadan kaldırmaz. Bir olay yaşandığında ekibinize daha erken uyarı, daha açık bağlam ve daha az körlemesine karar verme olanağı sunar. Tek bir sunucu, tek bir pano ve insanların gerçekten harekete geçeceği az sayıda uyarıyla başlayın. Böylece hizmet yeniden sorunsuz çalışır.
Andres Saar Müşteri Desteği Mühendisi