Prometheus İncelemesi: Kendi Sunucunuzda Çalıştırmaya Hâlâ Değer mi?

Kendi yaptığınız bir şey üretimde çalışıyor. İzlemeniz ya hiç yok ya da basit bir erişilebilirlik kontrolünden ibaret ve geçen hafta bir kesintiyi bir kullanıcıdan öğrendiniz. Aradığınız her cevap aynı isme çıkıyor.

Bu Prometheus incelemesi, ikisi de doğru olan iki şeyin arasındaki boşlukla ilgili. Ücretsiz ve açık kaynak; hangi ölçekte olursa olsun ne lisans ne de metrik başına fatura var. Bir yandan da size bir akşamınıza ve henüz bilmediğiniz bir sorgu diline mal oluyor. Uyarı mekanizması da bulunan, çekme tabanlı bir metrik toplayıcı ve son derece iyi bir yazılım. Şu anda çalıştırdığınız kurulum için doğru yazılım olup olmadığı ise ayrı bir soru ve cevaplanmayı hak eden soru da bu.

Kısa Versiyon

• Karar: tek kişilik ve küçük ekip kurulumları için 3,5 / 5. Sunucu ve servis kümeniz makul ölçüde sabitse, PromQL öğrenmeye zaman ayıracaksanız ve aboneliksiz, saklama faturası olmayan, tümüyle size ait metrikler istiyorsanız Prometheus çalıştırmaya değer.
• Cevabını aradığınız soru «çalışıyor mu» ise vazgeçin. Bir erişilebilirlik kontrol aracı sizi o cevaba çok daha hızlı ulaştırır; bu iş için Prometheus'a uzanmak, on dakikada cevaplayabileceğiniz bir şey için bir sorgu dilinin bedelini ödemek demektir.
• Sürekli geri gelen maliyet PromQL'dir. Kurulum tek seferlik bir maliyet. Sorularınız hazır panoları ve Grafana'nın görsel sorgu oluşturucusunu aştığı anda yeniden PromQL'e dönersiniz.
• Bakım maliyeti, kurulumun ne kadarını elle yönettiğinize bağlıdır. Biçimini koruyan bir sunucu filosunu izlemek ucuzdur. Sunucu kazanan, kaybeden ve yeniden adlandıran bir filo ise maliyetin sessizce biriktiği yerdir.
• Bu karar yalnızca küçük ölçekli kendi sunucunda barındırma için geçerlidir. Kubernetes ve üretim SRE ölçeğinde Prometheus bambaşka bir tekliftir ve bu inceleme o soruyu cevaplamaya çalışmıyor.

Bu inceleme nasıl hazırlandı: Prometheus ücretsiz ve açık kaynak, dolayısıyla burada hiçbir satıcı ilişkisi yok ve kimse bana bir şey göndermedi. Sürüm bilgileri ve depolama davranışı Prometheus'un kendi dokümantasyonundan geliyor. Kaynak kullanımı rakamları ve kurulum süreleri ise bağımsız olarak yayımlanmış iki uygulamalı testten geliyor ve her biri kullanıldığı yerde kaynak gösteriliyor. Bu iki test birbirinden ayrıldığında ortalama almak yerine iki rakamı da göreceksiniz.

Bu İnceleme Neyi Kapsıyor

Yukarıdaki kararın sınırları var ve bu sınırlar burada her zamankinden daha çok önemli, çünkü Prometheus farklı ölçeklerde farklı bir araç gibi davranıyor.

• Prometheus, tek bir VPS üzerinde ve küçük projelerde kendi sunucunda barındırma için değerlendiriliyor: bir avuç sunucu ve servis, onlarla ilgilenen tek bir kişi.
• Kubernetes değil. Prometheus Operator, ServiceMonitors ve kube-prometheus-stack ayrı bir işletim dünyasıdır ve buradaki karar onun hakkında hiçbir şey söylemez.
• Alertmanager yönlendirme rehberi değil. Uyarı mekanizması var ve çalışıyor; yolları, susturmaları ve alıcıları yapılandırmak başlı başına bir konu.
• Kurulum anlatımı değil. Buradaki soru, onu çalıştırıp çalıştırmamanız gerektiği. Bunu zaten yanıtladıysanız, Grafana ve Prometheus için Docker Compose rehberimiz adımları anlatıyor.
• Exporter taraması değil. Exporter'lar yalnızca cevabı değiştirdikleri yerde geçiyor.

Prometheus Neyi Doğru Yapıyor

Prometheus hiçbir şeye mal olmuyor. «Ücretli yükseltmeleri olan ücretsiz katman» değil, «bir metrik sınırını aşana kadar ücretsiz» de değil. Depo baştan sona Apache 2.0 lisanslı ve çekirdek projenin ücretli bir sürümü yok; hiçbir yerde sunucu başına, metrik başına ya da etiket başına faturalandırma yok. Prometheus'un ürettiği tek fatura, üzerinde çalıştığı sunucudur.

Bağımlı olmayı planladığınız bir şey için «üç yıl sonra da burada olacak mı» adil bir soru ve burada ihtimaller açık kaynakta olabileceği kadar iyi. Prometheus Ağustos 2018'de CNCF'te mezuniyet statüsüne ulaştı; bunu başaran ikinci proje oldu, Kubernetes'ten sonra. Sürümler düzenli çıkıyor; v3.13.2 Temmuz 2026 sonunda yayımlandı; bu sürüm hattı uzun vadeli destek hattı olduğundan bir yıl boyunca hata, güvenlik ve dokümantasyon düzeltmeleri almaya devam eder, dolayısıyla güncel kalmak her ara sürümün peşinden koşmak anlamına gelmez.

Etrafındaki ekosistemin bu kadar derin olmasının sebebi veri modeli. Prometheus metrikleri HTTP üzerinden toplar ve her seriyi bir metrik adı ile anahtar/değer etiketleriyle tanımlar; bu da exporter yazmayı küçük bir işe dönüştürür. Bu yüzden çalıştırabileceğiniz hemen her şey için exporter var: sistem metrikleri, Postgres, Nginx, Redis, yalnızca dışarıdan yoklayabileceğiniz şeyler için blackbox probları.

Ve topladığı şey size ait; bu da genelde ilk günden çok sonradan önem kazanan taraf. Küçük bir kurulumun geçmişi kayda değmeyecek kadar az disk tutar (rakamlar aşağıda), kimse gelecek çeyrekte size onu yeniden fiyatlayamaz ve biri bir uygulamaya ölçüm eklediğinde büyüyen bir fatura kalemi yoktur. Bir geliştirici tek bir etiket ekledi diye yönetilen bir izleme faturasının tırmandığını gördüyseniz, bütün argüman tek cümlede orada.

Prometheus Size Göründüğünden Nerede Daha Pahalıya Mal Oluyor

Küçük bir VPS üzerinde yedi izleme aracını deneyen bir dev.to testi tek başına Prometheus için 15 dakikalık bir kurulum süresi ölçtü. O testi yapan kişinin yaptığı gibi onu Grafana ile eşleştirin, çünkü yerleşik ifade tarayıcısı yalnızca sorgu çalıştırdığınız bir yer. Aynı test Grafana + Prometheus için ilk grafiğe kadar 35 dakika veriyor, arada YAML toplama yapılandırmasıyla birlikte.

Dakikalar ucuz olan taraf. Pahalı olan PromQL. Prometheus her şeyi ad ve etiketlerle tanımlanan zaman serileri olarak saklar ve ona sorduğunuz soruların altındaki dil hâlâ PromQL'dir. Grafana'nın artık görsel bir oluşturucusu var, yani her sorguyu elle yazmak zorunda değilsiniz. Testi yapan kişinin kendi kararı netti: PromQL, içinde yaşayanlar için harikadır, kendisi ise yaşamıyordu. Daha önce hiç sorgu dili kullanmadıysanız buna bir akşamdan fazlasını ayırın ve görsel oluşturucu yetmemeye başladığı her seferinde ona geri dönmeyi bekleyin. Başkasından kopyaladığınız bir pano onun sorularını cevaplar. Sizinkiler ise henüz yazmadığınız bir sorgudur.

Üçüncü maliyet, ancak sonradan ortaya çıkan maliyet. Bir operatörün üç haftalık değerlendirmesi yedi düğümlü bir kuruluma tek bir sunucu eklemenin tam olarak neyi gerektirdiğini anlatıyor: yeniden etiketleme, toplama yapılandırmalarını yeniden kontrol etme, pano değişkenlerini düzenleme ve yeni sunucunun açılır listelerde görünmesi için şablon sorgularını elden geçirme. O operatör, altyapısını izlemektense panoları ayarlamaya daha çok zaman harcadığı sonucuna vararak üç hafta sonra bu yığından vazgeçti.

Bu tür bir kurulumda o maliyetin neye bağlı olduğuna dikkat edin: elle yönetilen hedeflere ve panolara. Prometheus'u iki sakin yıl boyunca çalıştırmak size neredeyse hiçbir ek yük getirmez.

Prometheus Gerçekte Ne Kadar RAM ve Disk İstiyor?

Sabit bir gereksinim yok. Etkin seriler, toplama sıklığı, sorgu yükü ve saklama süresi, onu yönelttiğiniz sunucuların ham sayısından daha çok önem taşır. Küçük kurulumlar üzerinde yayımlanmış iki uygulamalı test bunu kabaca 180 MB ile 800 MB arasına yerleştiriyor; yüksek rakam, birkaç haftalık geçmişe sahip yedi düğümü kapsıyor.

İki test birbiriyle uyuşmuyor ve işe yarayan kısım tam da bu uyuşmazlık. Yedi araçlı aynı VPS karşılaştırması her aracı aynı donanımda çalıştırdı (1 vCPU, 2 GB RAM, 25 GB disk, Ubuntu 24.04), dört harici siteyi ve sunucunun kendisini izledi ve Prometheus'u boştayken yaklaşık 180 MB olarak ölçtü. Aynı operatör ise tek başına Prometheus'un merkezi sunucuda boştayken 300 MB civarında durduğunu, birkaç haftalık geçmiş biriktikten sonra 600 ila 800 MB'a tırmandığını bildirdi.

Bunlar aynı ölçüm değil ve bu yüzden ikisinin ortalamasını almak bilgiyi çöpe atmak olur. Biri, saklayacak çok az şeyi olan bir makinede neredeyse boşta alınmış bir okuma. Diğeri ise arkasında bir filo ve diskte geçmiş olan, çalışan bir dağıtım. Benim okumam: 180 MB sonucunu bir taban olarak görün, boyutlandırma hedefi olarak değil. Birden fazla sunucudan toplamaya ve geçmiş tutmaya başladığınız anda, o boştaki rakama göre plan yapmak yerine pay bırakın.

Disk kolay olan yarısı. Prometheus'un depolama dokümantasyonu bunu örnek başına ortalama 1 ila 2 bayt olarak veriyor, yani küçük bir kurulum için uzun bir geçmiş tutmak ucuz. Asıl mesele varsayılan değerde: saklama süresi varsayılan olarak 15 gün olarak ayarlıdır, siz bir saklama süresi ya da saklama boyutu belirlemediğiniz sürece. Bunu bir yıla çıkarmakla aranızda tek bir başlangıç parametresi var ve bu, geçen ayın rakamlarını aradığınızda üç hafta önce süresinin dolduğunu gördüğünüz ilk anda değil, şimdi öğrenmeyi tercih edeceğiniz türden bir varsayılan.

Bellek rakamını yukarı çeken şey kardinalitedir: farklı zaman serilerinin sayısı, yani bir metrik üzerindeki her benzersiz etiket kombinasyonunun kendi serisine dönüşmesi. Yoğun trafikli bir metrik üzerinde kötü seçilmiş tek bir etiket, beş ek sunucunun yaratacağından daha fazla seri yaratabilir ve bunu sessizce, trafiğinizin hızı neyse o hızla yapar. (Bir kullanıcı kimliği ya da bir istek yolu, kaç tane olduğunu saymaya başlayana kadar mükemmel bir etiket gibi görünür.)

Prometheus için alıntılanan herhangi bir RAM rakamı, ancak arkasında kaç seri olduğunu da biliyorsanız işinize yarar.

Prometheus Sunucunuz Çöktüğünde Ne Olur?

Prometheus'un kendi depolama dokümantasyonu bu konuda net: yerel depolama kümelenmiş veya çoğaltılmış değildir, bu yüzden bir disk ya da düğüm arızasına karşı dayanıklı değildir. Her sunucu tasarım gereği tek başınadır ve ne ağ depolamasına ne de uzak servislere bağımlıdır; onu çalıştırmayı kolaylaştıran da, savunmasız bırakan da tam olarak budur.

At solo scale that turns into two problems. If the box holding Prometheus dies, new alert evaluations stop, and your history goes with it unless you were taking TSDB snapshots and managing it like the single-node database it is, taking TSDB snapshots and copying them somewhere else. And if that box is also one of the machines being monitored, which on a one-server setup it inevitably is, then the thing that tells you something broke is the same thing that broke. (Yes, that's about as useful as it sounds.)

Projenin kendisi hakkında belirttiği ikinci bir sınır daha var ve bunu belirttiği için takdiri hak ediyor: %100 doğruluğa ihtiyacınız varsa, örneğin istek başına faturalandırma için, dokümantasyon Prometheus'un yanlış seçim olduğunu söylüyor, çünkü topladığı veriler büyük olasılıkla yeterince ayrıntılı ve eksiksiz olmayacak. Fatura kestiğiniz rakamlar için başka bir şey kullanın, Prometheus'u izleme için saklayın. Satıcılar kendileri hakkında bu tür şeyleri genelde kendiliğinden söylemez.

Daha büyük ölçekte bunun yerleşmiş cevapları var ve bunlar Kubernetes araçlarıyla aynı sebepten burada kapsam dışı: bu incelemenin kapsadığından farklı bir işletme taahhüdü gerektiriyorlar. Tek bir VPS için benim okumam şu: TSDB anlık görüntülerini başka bir yerde tutuyorsanız ya da geçmişi kaybedeceğinizi baştan kabul ediyorsanız bu risk kabul edilebilir; ama Prometheus sizinle sessiz bir kesinti arasındaki tek şeyse gerçek bir sorundur.

Prometheus'u Kimler Kendi Sunucusunda Çalıştırmalı?

Prometheus'un maliyetini geri ödeyeceğinin en net işareti, kaç sunucunuz olduğuyla ilgili değil. Altı ay sonra da aynı sunucular olup olmayacağıyla ilgili. Elle yapılandırılmış, sabit bir sunucu kümesi, yapılandırmayı bir kez yazıp geçmişi bedavaya toplamanız demektir; sürekli değişen bir küme ise o yapılandırmaya sürekli dokunmanız demektir.

Durağan bir kurulumda Prometheus ve Grafana yapılandırmanız, altyapınızın açık bir tarifidir: toplama hedefleri, onlara iliştirilen etiketler ve o etiketlerin üzerine kurulan panolar. Bütün kazancın geçmişte olmasının sebebi budur. Sabit bir sunucu kümesi üzerinde bir yıllık veri size normalin neye benzediğini söyler; bu da anormali bir kesintiye dönüşmeden fark etmenin en güvenilir yoludur.

Yani ilk profil, küçük ve yavaş değişen bir sunucu kümesi işleten ve çalışıyor mu çalışmıyor mu sorusundan fazlasını isteyen kişidir: zaman içinde istek gecikmesi, bellek eğilimleri, haftalar öncesinden geldiğini görebileceğiniz kadar yavaş dolan bir disk. Altyapınızı bugün tarif edebiliyor ve bu tarifin bir yıl sonra da aşağı yukarı geçerli olmasını bekliyorsanız, kuruluma harcadığınız o akşam son büyük faturadır.

İkincisi, bu yığını bilinçli olarak öğrenen herkes. Birkaç yıl sonra kendinizin ya da bir başkasının altyapısını işleteceğinizi düşünüyorsanız, o PromQL akşamı zaten geldiğiniz şeydir ve izleme yan üründür. Bu profil ilkini kısmen tersine çevirir: kararlılık testi burada daha az önemlidir, çünkü yeniden etiketlemeye harcanan zaman aynı zamanda yeniden etiketlemenin ne olduğunu öğrenmeye harcanan zamandır. Bu okur için puanı yukarı çekerdim.

Üçüncü profil sahiplikle ilgili ve insanların ters tarafında kalana kadar hafife aldığı profil bu. Prometheus ne sunucu başına, ne metrik başına, ne de etiket başına ücretlendirir ve hiçbir fiyat sayfası gelecek çeyrekte ayağınızın altından değişemez. Datadog gibi yönetilen bir hizmete karşı takas şu: cilayı, destek sözleşmesini ve bir başkasının nöbetini bırakırsınız; karşılığında size ait olan ve bir geliştirici ölçüm eklediğinde kıpırdamayan bir faturaya sahip metrikler elde edersiniz. Bunun iyi bir takas olup olmadığı kendi saatlerinizin ne ettiğine bağlı; bu rakamı yalnızca siz koyabilirsiniz (ve öyle hissettirse bile nadiren sıfırdır).

Karar vermeden önce bilmeniz gereken bir şey: Prometheus'un yerel depolamasını aşmak bir çıkmaz sokak değil. VictoriaMetrics Prometheus remote write isteklerini kabul ediyor, ayrıca MetricsQL, PromQL ile geriye dönük uyumlu, dolayısıyla şimdi kurduğunuz sorguların ve Grafana panolarının çoğu taşınmadan sonra da ayakta kalmalı. Bu bir göç, yeniden yazım değil.

Bir kez karar vermek yerine yılda bir yeniden değerlendirmeye değer: bugün izlemesi ucuz olan kurulum, onu yeniden inşa etmeye başladığınız çeyrekte pahalılaşır.

Root erişimi, NVMe ve AMD EPYC gücüne sahip bir Linux VPS üzerinde geliştir.

Linux Planlarını Gör

Prometheus'tan Kimler Vazgeçmeli?

İhtiyacınızı anlatmak için kuracağınız cümle «site çöktüğünde bana haber ver» ise, bir erişilebilirlik kontrol aracını tarif ediyorsunuz demektir ve Prometheus o cevaba ulaşmak için epey fazla makine. Uptime Kuma tam olarak bu işi bir web arayüzüyle yapar ve sizden bir izleme sorgu dili öğrenmenizi istemez. İki araç arasındaki yetenek farkı devasadır ve tuttuğunuz iş açısından tamamen konu dışıdır.

İkinci okur, önce bir sorgu dili öğrenmeden kullanılabilir grafikler isteyen kişidir. Netdata tam olarak bunun üzerine kuruludur: hemen bakabileceğiniz, sunucu başına metrikler, çok daha az yapılandırmayla ve sizinle grafikler arasında hiçbir şey olmadan. Tekrar tekrar sorduğunuz soru «bu makine şu anda neden yavaş» ise, bu bir cevaba çok daha kısa bir yoldur.

Üçüncüsü, altyapısı sık sık biçim değiştiren ve hedefleri ile pano değişkenlerini elle yöneten herkes. Bir haftalığına açılıp yok edilen sunucular, yeniden adlandırılan hedefler, yarı yolda yeniden adlandırılan projeler. Yapılandırma maliyetini defalarca ödeyip karşılığında ödediğiniz şeyden, yani tanınabilir kalan bir sistemin kesintisiz geçmişinden en az faydayı gördüğünüz durum tam olarak budur.

Bunların hiçbiri araca yönelik bir eleştiri değil. Buradaki «vazgeç», bu iş için ve bu ölçekte vazgeç demek. Servis keşfinin, aksi hâlde elle bağlayacağınız işlerin çoğunu üstlendiği Kubernetes ölçeğinde, yukarıdaki maliyetlerin birkaçı küçülür ya da tamamen ortadan kalkar ve o ölçek hakkındaki okumam, Prometheus'u orada yenmenin çok zor olduğu yönünde. Ama o başka bir inceleme.

OKU

VPS'inizde Grafana + Prometheus izleme yığını kurulumu (Docker Compose rehberi)

Sıkça Sorulan Sorular