Prometheus'u Herkes Kurdu: Peki Neden Hâlâ Geç Haber Alıyoruz?

Kısa cevap: Hangi aracı kuracağınız sorusu kapandı. CNCF'in 2025 yıllık araştırmasında Prometheus katılımcıların %77'sinde kullanılıyor ve Kubernetes'ten sonra en çok benimsenen CNCF projesi. Buna rağmen ekipler olaylardan hâlâ geç haberdar oluyor, çünkü darboğaz araçta değil: Grafana Labs'ın dördüncü yıllık observability araştırmasına göre olaya daha hızlı müdahalenin önündeki en büyük tek engel uyarı yorgunluğu ve bunu söyleyenlerin oranı %30, yani ikinci sıradaki cevabın neredeyse iki katı.

Bu yazı, stack'i kurduktan sonra başlayan asıl işi ele alıyor: neyin uyarı olacağına, o uyarının kime gideceğine ve bunun ne kadara mal olacağına karar vermek.

Araç tartışması neden bitti?

Rakamlar tek yöne bakıyor. CNCF'in araştırmasında Kubernetes'in üretimde kullanımı %82'ye çıktı; Prometheus da onunla birlikte fiilî standart hâline geldi. Grafana'nın üçüncü yıllık araştırması aynı tabloyu farklı bir açıdan gösteriyor: kurumların üçte ikisinden fazlası Prometheus'u üretimde kullanıyor, %19'u ise değerlendirme ya da kavram kanıtı aşamasında. Katılımcıların %70'i Prometheus ile OpenTelemetry'yi birlikte kullanıyor.

Yani "hangi metrik motoru" sorusu artık bir seçim değil, bir varsayım. Bir kurum bugün observability kurarken Prometheus'u tartışmıyor; onun üzerine ne koyacağını tartışıyor.

Sorun nereye taşındı?

Aynı araştırma, 76 ülkeden 1.363 mühendis, güvenilirlik mühendisi ve teknoloji yöneticisinin cevabına dayanıyor. 2026 için sıraladıkları kaygılar araç seçimiyle ilgili değil:

Karmaşıklık ve işletme yükü: %38, listenin başıSinyal-gürültü oranı: %34Maliyet: %31

Bu üçü aynı kökten geliyor. Metrik toplamak ucuz ve kolay olduğunda ekipler her şeyi topluyor; toplanan her seri saklama maliyeti, sorgu maliyeti ve dikkat maliyeti üretiyor. Sonuçta panolar doluyor ama kimse bakmıyor, uyarılar geliyor ama kimse okumuyor.

Araştırmanın en pratik bulgusu şu: kurumların kullandığı observability teknolojisi sayısı dokuzdan sekize düştü. Yani olgun ekipler araç eklemiyor, çıkarıyor.

Uyarı yorgunluğu bir kültür sorunu değil, bir tasarım sorunu

"Ekip uyarıları önemsemiyor" cümlesi hemen hemen her zaman yanlış teşhistir. Bir mühendis gece 03.00'te gelen uyarıyı üçüncü kez gereksiz bulduysa, dördüncüsünü de gereksiz varsayması rasyonel bir davranıştır. Düzeltilecek olan davranış değil, uyarının kendisi.

İşe yarayan üç kural var ve üçü de ölçülebilir:

Her uyarının bir sahibi olmalı. Sahibi olmayan uyarı, herkesin gördüğü ve kimsenin açmadığı uyarıdır. Sahipliğin nasıl yazıya döküleceğini olay yükseltme matrisi yazımızda adım adım ele almıştık.

Her uyarı bir eyleme bağlanmalı. "CPU %80'i geçti" bir eylem üretmiyor. "Kuyruk beş dakikadır boşalmıyor ve müşteri talebi birikiyor" üretiyor. İkincisi bir belirti değil bir sonuç ölçüyor.

Eşik, kurumun kendi hedefinden türetilmeli. Sağlayıcının varsayılan eşiği sizin iş yükünüzü tanımıyor. Kurtarma hedeflerinde olduğu gibi burada da doğru yön aşağıdan yukarı: RPO ve RTO'yu iş maliyetinden hesaplamak hangi gecikmenin gerçekten uyarılmayı hak ettiğini de söyler.

Maliyet neden üçüncü sırada değil, birinci sırada

Aynı araştırmada maliyet, üst üste üçüncü yıl araç seçiminde en önemli kriter (%65). Bu, gözlemlenebilirliğin bir mühendislik konusundan bir bütçe konusuna dönüştüğü anlamına geliyor.

Maliyeti belirleyen şey genelde veri hacmi değil, kardinalite: bir metriğe eklenen her etiket, saklanacak zaman serisi sayısını çarparak büyütür. Kullanıcı kimliği ya da istek kimliği gibi sınırsız değer alabilen bir etiket, tek başına bir metriği milyonlarca seriye bölebilir. Bu, faturayı da sorgu süresini de aynı anda büyütür.

Pratikte işe yarayan yaklaşım, saklama süresini tek bir sayı olarak değil kademeli düşünmek: yüksek çözünürlüklü veri kısa süre, özetlenmiş veri uzun süre. Neyin ne kadar tutulacağı bir maliyet kararıdır ve mevzuata tabi kayıtlarda ayrıca yasal saklama sürelerine bakmak gerekir.

Nereden başlanmalı

Yeni bir araç kurmadan önce üç soruyu cevaplayın:

Son otuz günde gelen uyarıların kaçı bir eyleme yol açtı? Oran %20'nin altındaysa sorun görünürlükte değil, eşiklerde.En pahalı beş metriğiniz hangileri ve kaç seriye bölünüyorlar? Cevap genelde birkaç etiketi kaldırmakla biten kısa bir listedir.Bir uyarı geldiğinde onu kimin açacağı yazılı mı? Yazılı değilse, uyarı bir bildirimdir; bir süreç değil.

Bu üçünün cevabı, hangi panoyu kuracağınızdan daha çok şey değiştirir. Eclit'in bu katmanı nasıl kurduğunu gözlemlenebilirlik ve APM sayfasında görebilirsiniz.

Gözlemlenebilirliğin amacı daha çok veri toplamak değil; bir sorunun müşteri fark etmeden önce doğru kişiye ulaşmasını sağlamak. Prometheus bunu mümkün kılıyor, garanti etmiyor.