Önemli Olan Prometheus Grafana Hosting Metrikleri

12 Mayıs 2026 tarihinde yayımlandı

Sunucunuz, ödeme adımı yavaşlayana, PHP worker'ları birikene veya bir düğüm sabah 3:12'de disk alanını bitirene kadar "iyi" hissettiriyorsa, önce bir hosting sorununuz yoktur - bir görünürlük sorununuz vardır. Prometheus Grafana hosting metrikleri, operasyon ekiplerinin gerçekten ihtiyaç duyduğu görünümü sağlar: ne yoğun, ne başarısız oluyor, ne başarısız olmaya yakın ve kullanıcılar fark etmeden önce ne değişti.

Hosting ortamları için bu, gösterişli grafiklerden daha önemlidir. Bir VPS, managed VPS veya dedicated server, CPU steal sıçramaları yaşanırken, I/O wait artarken, bellek baskısı oluşurken veya veritabanı gecikmesi sapmaya başlarken dışarıdan sağlıklı görünebilir. Uptime kontrolleri şikâyet etmeye başladığında, zarar zaten başlamış olur. Metrikler, sorunların şeklini daha erken, hâlâ küçük ve düzeltilebilirken yakalamanızı sağlar.

prometheus grafana hosting metrikleri ne göstermeli

Yararlı bir kurulum, sıkıcı gerçeklerle başlar. Host'un erişilebilir olup olmadığını, kaynakların baskı altında olup olmadığını ve iş yükünün normal davranıp davranmadığını bilmeniz gerekir. Bir pano bu üç şeyi bir dakikadan kısa sürede yanıtlayamıyorsa, süsten ibarettir.

Prometheus, exporter'lardan ve servislerden zaman serisi verilerini toplar. Grafana, bu verileri kahvesi olan ama belki de yeterince kahvesi olmayan insanlar için yeterince okunabilir hâle getirir. Birlikte, hosting için pratik bir uyum sağlarlar çünkü altyapıyı ve uygulamaları aynı yerde izleyebilirler.

Altyapı katmanında temel metrikler CPU kullanımı, load, bellek tüketimi, swap etkinliği, disk alanı, disk I/O, dosya sistemi inode'ları, ağ throughput'u, paket hataları ve uptime'dır. Bunlar gösterişli değildir, ancak gerçek olayların çok büyük bir bölümünü açıklar. Düşük load ile yüksek CPU, boşta CPU ile yüksek load'dan farklı bir anlama gelir. Serbest bellek sakin görünebilir, ta ki page fault'lar ve swap diğer hikâyeyi anlatmaya başlayana kadar. Log'lar şimdi aynı hikâyeyi anlatıyor, ancak metrikler bunu daha erken anlatır.

Servis katmanında, para kazandıran veya işin devam etmesini sağlayan yazılımdan metrikler istersiniz. Web stack'leri için bu genellikle Nginx veya Apache istek oranları, durum kodu dağılımı, aktif bağlantılar, upstream yanıt süresi ve TLS sonlandırma davranışı anlamına gelir. Veritabanları için sorgu gecikmesi, bağlantı kullanımı, cache hit oranı, replication lag ve depolama büyümesi, genel bir yeşil onay işaretinden daha önemlidir. Container'lar için bu genellikle container yeniden başlatmaları, bellek limitleri, CPU throttling ve servis başına saturation'dır.

Hosting ekipleri neden Prometheus ve Grafana'yı birlikte kullanır

Prometheus, metrikleri verimli şekilde toplama ve depolama konusunda çok iyidir. Ayrıca ciddi operasyon çalışmaları için yeterince güçlü alerting mantığına da sahiptir. Grafana, bu metriklerin, her sorguyu ezbere hatırlayan tek mühendisten daha fazla kişi için operasyonel olarak faydalı hâle geldiği yerdir.

Bu eşleşme özellikle hosting'de iyi çalışır çünkü ortamlar karmadır. Bir müşterinin managed VPS üzerinde tek bir WordPress örneği olabilir. Bir diğeri özel ağ üzerinden birkaç API, Redis ve bir veritabanı kümesi çalıştırır. Basitten yoğuna ölçeklenebilen, daha sonra sizi tam bir yeniden tasarıma zorlamayan tek bir monitoring düzeni istersiniz.

Bir de güven faktörü vardır. Müşteriler yalnızca bir host'un çevrimiçi olduğunu bilmek istemez. Sunucularının soruna yakın olup olmadığını, kullanımın bir yükseltmeye doğru eğilim gösterip göstermediğini ve bir destek mühendisinin hızlı hareket etmek için yeterli veriye sahip olup olmadığını bilmek isterler. Metrikler tahmini azaltır. Ayrıca herkesin ağdan şüphelendiği, ama gerçek sorunun dolu bir disk ve 900.000 cache dosyası olduğu o hafif can sıkıcı destek görüşmesini de azaltır.

Gerçek hosting'de en önemli metrikler

Bazı sayılar diğerlerinden daha değerlidir çünkü doğrudan eyleme işaret ederler. CPU utilization faydalıdır, ama CPU saturation genellikle daha faydalıdır. Çekirdekleriniz meşgulse ve run queue uzunluğu artıyorsa, kullanıcılar bunu hisseder. CPU, yedekleme veya indeksleme işi planlandığı gibi çalıştığı için yüksekse ve gecikme sabitse, bu daha az dramatiktir.

Bellek metrikleri de aynı bağlama ihtiyaç duyar. Toplam kullanılan bellek, sistem sağlıklı olsa bile Linux'ta endişe verici görünebilir. Daha önemli olan kullanılabilir bellek, swap etkinliği, major page fault'lar ve uygulamanızın OOM killer tarafından öldürülmeye başlayıp başlamadığıdır. Bu bir kez görünürse, bu bir uyarıdır. İki kez görünürse, sunucu çok doğrudan bir şekilde yardım istiyor demektir.

Disk metrikleri, genellikle gördüklerinden daha fazla saygıyı hak eder. Kapasite kullanımı bunun yalnızca bir parçasıdır. Disk latency, queue depth, okuma/yazma IOPS ve inode tüketimi, disk teknik olarak dolmadan önce bile bir servisi bozabilir. Hiçbir şey paylaşılmıyor, tam panik - amaç bu değil. Sağlıklı bir hosting panosu, hem ne kadar depolama kaldığını hem de depolama alt sisteminin şu anda zorlanıp zorlanmadığını göstermelidir.

Ağ metrikleri, sunucu sorunları ile trafik sorunlarını ayırmaya yardımcı olur. Throughput, düşen paketler, yeniden iletimler ve arayüz hataları, hattın baskı altında mı yoksa kirli mi olduğunu söyler. Yanıt süresi sistem kaynakları normalken sıçrıyorsa, ağ davranışı daha ilginç hâle gelir. Yanıt süresi I/O wait ve veritabanı kilit çekişmesiyle birlikte sıçrıyorsa, bu kez ağ muhtemelen masumdur.

Sonra uygulama metrikleri gelir; hosting'in iş farkındalığı kazandığı yer burasıdır. Bir site sahibi yalnızca CPU'yu değil, sipariş tamamlama süresini önemser. Bir SaaS operatörü queue depth, iş başarısızlıkları ve API gecikme yüzdeliklerini önemser. Birkaç müşteri sitesini yöneten bir dijital ajans en çok yavaş cron işleri, başarısız yedeklemeler, SSL sona erme aralıkları ve kampanya lansmanından sonra ani trafik değişiklikleriyle ilgilenebilir. İyi prometheus grafana hosting metrikleri, sistem sağlığını müşteri etkisine bağlar.

Gürültü oluşturmadan alerting

Bir pano pasiftir. Alert'ler, monitoring'in operasyona dönüştüğü yerdir. Ama çok fazla alert verirseniz, sistem herkesi bunu görmezden gelmeye alıştırır. Bu, sessiz ve sinsi bir şekilde pahalıdır.

Daha iyi yaklaşım katmanlı alerting'dir. Müşterilerin hissedebileceği belirtiler için, sonra altyapı nedenleri için, sonra da önleyici çalışma yapmayı sağlayan eğilim uyarıları için alert verirsiniz. Örneğin, kalıcı yüksek gecikme veya yükselmiş 5xx oranları, "iki dakika boyunca CPU %80'in üzerinde" ifadesinden daha hızlı çağrıya düşmelidir. Yedi gün içinde öngörülen tükenme için bir disk tahmin alert'i faydalıdır. Geçici kullanım keyfi bir eşiği her geçtiğinde bildirim göndermek ise sadece kabalıktır.

Burası, managed hosting teams gerçek değer kattığı yerdir. Exporter'ları kurmak zor değildir. Özellikle çok sayıda farklı iş yükü arasında, alert'leri gerçek operasyonel riski temsil edecek şekilde ayarlamak daha zordur. Bir e-ticaret veritabanı, bir staging kutusu ve bir CI runner için eşikler aynı olmamalıdır. Bu; davranışa, takvime ve gecikmeye toleransa bağlıdır.

İnsanların gerçekten kullanacağı panolar oluşturmak

En temiz Grafana panosu, en fazla panele sahip olan değildir. Çok hızlı bir şekilde, endişelenmeleri gerekip gerekmediğini ve sırada neyi kontrol etmeleri gerektiğini yanıtlamaya yardımcı olan panodur.

Güçlü bir hosting panosu genellikle mevcut durumun üst satırıyla başlar: erişilebilirlik, CPU saturation, bellek baskısı, disk kullanımı, ağ throughput'u ve aktif alert'ler. Bunun altında, ikinci katman son birkaç saat ve gündeki eğilimleri gösterir. Ardından servis özelindeki paneller; web yanıt süreleri, veritabanı load'u, kuyruk birikimi veya container yeniden başlatmaları gibi olası nedeni açıklar.

Birkaç sunucuyu yöneten ekipler için tutarlılık çok önemlidir. Her düğümün pano düzeni farklıysa, sorun giderme gereksiz yere yavaşlar. VPS düğümleri, veritabanı sunucuları, web sunucuları ve uygulama worker'ları için standart görünümler zaman kazandırır çünkü mühendisler aramayı bırakıp karşılaştırmaya başlar. Sakin operasyonlar çoğu zaman sadece daha az sürpriz içeren tekrarlanabilir operasyonlardır.

prometheus grafana hosting metriklerinde yaygın hatalar

En yaygın hata, her şeyi toplayıp neredeyse hiçbir şeyi anlamamaktır. Prometheus çok büyük miktarda veri toplayabilir; bu ancak retention, cardinality ve sorgu performansı kontrol altında kalırsa faydalıdır. Binlerce kombinasyona patlayan label'lar, makul bir metrik yığınını aç bir yığına dönüştürebilir.

Bir başka hata da yalnızca host metriklerine güvenmektir. Bir sunucunun bolca boş kaynağı olabilir ve yine de uygulama bir bağımlılıkta, veritabanı kilitlerinde veya kötü kod yollarında takıldığı için kötü bir kullanıcı deneyimi sunabilir. Host metrikleri size nereye bakmanız gerektiğini söyler. Uygulama metrikleri ise kullanıcıların neden rahatsız olduğunu söyler.

Ekipler ayrıca metriklerin sahipliğe ihtiyaç duyduğunu da unutur. Birinin exporter'ları bakımını yapması, panoları gözden geçirmesi, alert eşiklerini ayarlaması ve kimsenin kullanmadığı panelleri kaldırması gerekir. Bir yıl boyunca dokunulmadan bırakılan monitoring, önceki niyetlerin müzesine dönüşür.

Bunun hosting müşterileri için anlamı

Production iş yükleri çalıştırıyorsanız, metrikler daha büyük şirketler için isteğe bağlı bir ekstra değildir. Temel operasyonel güvenliğin bir parçasıdırlar. Soru, onlar olmadan hayatta kalıp kalamayacağınız değildir. Çoğu zaman kalabilirsiniz, ta ki bir yavaş arıza gürültülü bir öğleden sonraya ve daha uzun bir faturaya dönüşene kadar.

Daha küçük işletmeler için Prometheus ve Grafana gerekenden daha ağır gelebilir. Ama değer basittir: daha net kapasite planlaması, daha hızlı olay müdahalesi, daha az kör nokta ve performans düşmeden önce sunucunuzun ne yaptığını tahmin etmeye daha az zaman harcanması. Ajanslar ve SaaS ekipleri için bu, müşterilerle daha iyi görüşmeler ve daha az belirsiz açıklama anlamına da gelir.

kodu.cloud'da bu tür görünürlük, yalnızca gözlemi değil eylemi desteklediğinde en iyi uyumu sağlar. Metrikler, bir müşterinin veya mühendisin ölçeklendirme, optimize etme, inceleme yapma ya da sağlıklı bir sistemi rahat bırakıp güne devam etme kararı vermesine yardımcı olmalıdır.

Ciddi bir iş yükü için hosting seçiyorsanız, basit bir soru sorun: performans saparsa veya bir düğüm garip davranmaya başlarsa, sakin kafayla hareket etmek için bunu yeterince erken görebilecek misiniz? Yanıt evetse, müşteriler bir sorun olduğunu hiç öğrenmeden önce hizmet yeniden sakinleşir.

Andres Saar Müşteri Hizmetleri Mühendisi