Merkezi Sunucu İzleme ve Alarm Mimarisi

Neden Merkezi Sunucu İzleme ve Alarm Mimarisi Kurmalısınız?

Bir noktadan sonra tek tek sunuculara SSH ile bağlanıp htop, df, journalctl bakarak sistem yönetmek mümkün olmuyor. Ajans tarafında onlarca müşterinin sitesini, SaaS tarafında yüzlerce kiracıyı, e-ticaret tarafında da trafik dalgalanmalarını yönetirken ihtiyacınız olan şey; metriklerin, logların ve alarmların tek bir merkezde toplandığı, iyi tasarlanmış bir merkezi izleme ve alarm mimarisi oluyor.

Bu yazıda, DCHost altyapısında sıkça kurduğumuz mimariler üzerinden giderek Prometheus + Alertmanager + Grafana, Zabbix ve hosted (SaaS) izleme çözümlerini aynı çerçevede ele alacağız. Hangi bileşen ne iş yapar, kim hangi durumda daha mantıklıdır, çok kiracılı yapılarda güvenliği ve erişimi nasıl tasarlarsınız, gürültü yapan alarmları nasıl susturup gerçekten kritik olanı öne çıkarırsınız; hepsini adım adım konuşacağız.

Daha önce paylaştığımız VPS izleme ve alarm kurulumu için başlangıç rehberinde tek VPS ölçeğinde odaklanmıştık. Bu yazı ise, çok sayıda VPS, dedicated sunucu ve hatta colocation sunucularınızı kapsayan, kurumsal ölçekte bir merkezi izleme platformu kurmak isteyenler için daha mimari seviyede bir yol haritası olacak.

Mimari Temeller: İzleme, Loglama ve İzlenebilirlik Üçgeni

Merkezi izleme mimarisi kurarken önce neyi nereye koyacağınızı netleştirmeniz gerekiyor. Genel kabul görmüş pratik, altyapıyı üç katmana ayırmak:

• Metrikler: CPU, RAM, disk, network, HTTP istek sayısı, hata oranı gibi sayısal, zaman serisi veriler.
• Loglar: Uygulama ve sistem logları, Nginx/Apache access.log, error.log, uygulama hataları.
• İzler (traces): Özellikle mikroservis ve API tabanlı yapılarda, bir isteğin uçtan uca yolculuğunun izlenmesi.

Bu yazının odağı metrik ve alarm katmanı; ancak gerçek hayatta log ve iz katmanını da düzgün kurmadan sadece metriklerle sürprizleri yakalamak zor olur. Örneğin Grafana Loki + Promtail ile merkezi loglama rehberimizde anlattığımız log mimarisi ile bu yazıdaki metrik mimarisini birleştirdiğinizde, gerçekten iş gören bir observability katmanına yaklaşmış olursunuz.

Prometheus Tabanlı İzleme Mimarisi

Prometheus, özellikle modern Linux altyapılarında fiili standart haline gelmiş, zaman serisi veritabanı ve çekme (pull) tabanlı metrik toplayıcısıdır. En büyük gücü, basit veri modeli, esnek etiketleme (labels) sistemi ve Alertmanager ile alarm tarafında sunduğu esnekliktir.

Prometheus’un Temel Bileşenleri

• Prometheus server: Metrikleri toplayan, saklayan ve sorgulayan ana bileşen.
• Exporters: Sunucu ve servislerden metrikleri HTTP endpoint olarak sunan küçük ajanlar (Node Exporter, MySQL exporter, Nginx exporter vb.).
• Alertmanager: Prometheus kurallarına göre üretilen alarmları toplayan, gruplayan, bastıran ve e-posta, webhook, chat kanallarına ileten bileşen.
• Grafana: Prometheus’u veri kaynağı olarak kullanıp görsel dashboard ve ek alarm tabakası sunan arayüz.

Prometheus, default yaklaşım olarak pull (çekme) modeli kullanır; yani her sunucuda çalışan exporter’lardan belirli aralıklarla metrik çeker. Bu, firewall ve güvenlik mimarisi açısından hem avantaj hem dezavantaj olabilir; birazdan buna da değineceğiz.

DCHost Üzerinde Tipik Prometheus Yerleşimi

DCHost’ta sık kullandığımız basit ama ölçeklenebilir yerleşim şöyle:

• İzleme sunucusu: Ayrı bir VPS veya dedicated sunucu; Prometheus + Alertmanager + Grafana burada çalışır.
• İzlenen sunucular: Diğer VPS/dedicated/colocation sunucularınız; her birinde Node Exporter ve ihtiyaç varsa uygulama/DB exporter’ları (MySQL, PostgreSQL, Redis vb.).
• İletişim: İzleme sunucusu → İzlenen sunuculardaki exporter’lara 9100, 9104 vb. portlardan HTTP istek atar.

Burada kritik nokta, güvenlik duvarı (firewall) kurallarını sadece izleme sunucusunun exporter portlarına erişebilecek şekilde ayarlamak. Örneğin DCHost VPS’inizde ufw veya firewalld ile sadece izleme sunucusunun IP’sine 9100 portunu açmak iyi bir başlangıçtır. Firewall sertleştirme konusunda desteğe ihtiyaç duyarsanız, daha önce paylaştığımız VPS güvenlik sertleştirme kontrol listesi de işinize yarayacaktır.

Metrik Tasarımı: Sadece CPU ve RAM Yeterli Değil

Prometheus ile neredeyse her şeyi ölçebilirsiniz; ama ölçmek ayrı, anlamlı alarm üretmek ayrı konu. DCHost’ta pratikte işe yarayan temel metrik setini şöyle özetleyebiliriz:

• Altyapı metrikleri: CPU kullanımı, load average, RAM kullanımı, disk doluluk, disk IO bekleme süresi, network trafik ve hata oranları.
• Servis metrikleri: HTTP 5xx oranı, response time (p95/p99), active connections, queue length, database connection count, replication lag.
• İş metrikleri: Sipariş sayısı, ödeme hata oranı, sepete eklemeden satın almaya dönüşüm gibi KPI’lar.

Özellikle e-ticaret ve SaaS tarafında, sadece “CPU %90 oldu” diye değil, “ödeme başarısızlık oranı 5 dakikadır normalin 3 katına çıktı” diye alarm almanız gerekir. İş metriklerini Prometheus’a push eden basit bir endpoint ekleyerek bunu sağlayabilirsiniz.

Alertmanager ile Alarm Gürültüsünü Kontrol Altına Almak

Merkezi izleme mimarilerinin sık yapılan hatası, her metrik için ayrı ayrı alarm kurmak ve ekibi sürekli bildirim bombardımanına tutmak. Alertmanager tarafında şu prensipleri uyguladığınızda hayat çok kolaylaşıyor:

• Grup bazlı alarmlar: Örneğin aynı uygulama kümesindeki 3 sunucuda da CPU yüksekse tek alarm üretmek.
• Silencing (susturma): Planlı bakım, deploy, migration esnasında ilgili alarmları etiket bazlı susturmak.
• Routing: Veritabanı alarmlarını DB ekibine, uygulama alarmlarını web ekibine, altyapı alarmlarını SRE ekibine yönlendirmek.
• Inhibit (bastırma): Örneğin bütün cluster down olduğunda tek tek node down alarmlarını bastırmak.

Bu seviyede tasarım yapmak için PromQL ve Alertmanager konfigürasyonuna hâkim olmak önemli. Daha operasyonel bir başlangıç yapmak isterseniz, Prometheus ve Node Exporter ile sessiz alarmları konuşturduğumuz rehbere göz atmanız iyi bir hazırlık olur.

Prometheus’un Ölçeklenmesi: Onlarca Sunucudan Yüzlerce Sunucuya

Başlangıçta tek bir Prometheus sunucusu işinizi görür. Ancak DCHost üzerinde çok sayıda VPS, dedicated ve colocation sunucusunu aynı merkezde izlemeye başlayınca iki konu gündeme gelir:

• Performans: Scrape süresi artar, Prometheus’un kendi CPU ve disk kullanımı yükselir.
• Saklama süresi: 30–90 günlük metrik tutulmak istendiğinde disk kapasitesi hızla dolar.

Burada üç temel strateji vardır:

1. Federasyon: Bölgesel veya proje bazlı Prometheus instanceları kurup, üst seviye bir Prometheus ile özet metrikleri toplamak.
2. Sharding: Hedef listelerini bölerek birden fazla Prometheus sunucusuna paylaştırmak.
3. Uzun süreli saklama: Metrikleri uzun vadede saklamak için ek bir zaman serisi deposu (örneğin Thanos / Cortex benzeri çözümler) eklemek.

Küçük ve orta ölçekli yapılarda federasyon + disk planlaması genellikle yeterli olur. Çok büyük yapılarda ise mimariyi baştan çok bölgeli şekilde tasarlamak gerekir; bu da çok bölgeli mimari rehberimizde değindiğimiz konularla güzel örtüşür.

Zabbix ile Agent Tabanlı İzleme Mimarisi

Zabbix, daha klasik anlamda “hepsi bir arada” izleme ve alarm çözümü olarak öne çıkar. Agent tabanlı yapısı, SNMP desteği, otomatik keşif (low-level discovery) ve hazır şablonlarıyla özellikle karmaşık network cihazları ve Windows/Linux karması ortamlarda hâlâ çok güçlü bir oyuncu.

Zabbix Mimarisi Nasıl Çalışır?

• Zabbix Server: Tüm konfigürasyonun, alarmların ve metriklerin tutulduğu ana bileşen.
• Zabbix Agent: İzlenecek sunucuya kurulan ajan; CPU, RAM, disk, process, log vb. bilgileri aktif/pasif modda server’a iletir.
• Zabbix Proxy: Uzak networkler veya çok sayıda host için aracı katman; veriyi toplayıp Zabbix server’a iletir.
• Database + Web UI: MySQL/PostgreSQL üzerinde çalışan konfigürasyon veritabanı ve PHP tabanlı arayüz.

Prometheus’tan farklı olarak Zabbix, hem agent push/pull hem de SNMP ile çalışabilir. Bu da özellikle switch, router, firewall gibi network cihazlarının izlenmesinde büyük avantaj sağlar.

Prometheus mu, Zabbix mi?

DCHost’ta gördüğümüz gerçek senaryolarda, seçim genelde şu kriterlere göre şekilleniyor:

• Modern Linux + container ağırlıklı ortamlar: Prometheus + Grafana çoğu zaman daha esnek, ölçeklenebilir ve geliştirici dostu.
• Ağ cihazları yoğun, Windows sunucuların ağırlıkta olduğu karma ortamlarda: Zabbix’in agent + SNMP yetenekleri daha hızlı devreye alınabiliyor.
• Mevcut ekip yetkinliği: Linux ve PromQL bilen bir SRE ekibi varsa Prometheus; daha klasik izleme dünyasına alışkın bir ekip varsa Zabbix ile başlamak daha konforlu.

Gerçekte pek çok kurumda hibrit yaklaşım da görüyoruz: Altyapı metrikleri Prometheus ile, network ve bazı legacy sunucular Zabbix ile izleniyor; üstte ise Grafana hepsini tek ekranda birleştiriyor.

Zabbix’te Pratik Alarm Örnekleri

Zabbix’in hazır şablonlarıyla gelen ama çoğu zaman ince ayar gerektiren bazı tipik alarmlar:

• Disk doluluk: %80’de uyarı, %90’da kritik; ama data diski ile log diski için ayrı eşikler belirlemek.
• Ping / agent down: Özellikle DCHost dışı ofis/şube cihazları için bağlantı problemlerini erken yakalamak.
• Log trigger’ları: Belirli hata mesajlarını log içinde arayıp alarm üretmek (örneğin ödeme altyapısı hataları).
• Servis kontrolü: Nginx, PHP-FPM, MySQL gibi servislerin çalışıp çalışmadığını periyodik olarak test etmek.

Zabbix’in en büyük avantajlarından biri, bu tür kontroller için hazır template ekosisteminin zengin olması. Ancak yine de kendi ortamınıza uyarlarken eşik değerlerini, süreleri ve bağımlılıkları iyi düşünmek gerekiyor.

Grafana ile Tek Merkezden Görünürlük ve Alarm Katmanı

İster Prometheus, ister Zabbix, ister hosted izleme kullanıyor olun; iş sonunda ekiplerin baktığı yer çoğu zaman Grafana dashboard’ları oluyor. Çünkü Grafana:

• Pek çok veri kaynağını (Prometheus, Zabbix, Loki, MySQL, Elastic vb.) tek ekranda birleştirebilir.
• Uygulama, veritabanı, altyapı ve iş metriklerini tek panelde gösterebilir.
• Kendi alarm mekanizmasına sahip olduğu için bazı durumlarda Alertmanager/Zabbix trigger’larını tamamlayabilir.

Örneğin bir WooCommerce sitesi için şunları aynı ekranda görmek isteyebilirsiniz:

• CPU, RAM, disk IO (Node Exporter/Prometheus)
• MySQL query per second ve slow query sayısı (MySQL exporter)
• HTTP 5xx oranı ve responce time percentiles (Nginx/Load balancer metrikleri)
• Sepete ekleme → ödeme akışında dönüşüm oranı (iş metrikleri)

Bu yapıyı kurarken, daha önce detaylı incelediğimiz e-ticaret siteleri için log analizi rehberindeki ödeme hatası yakalama taktikleri ile metrik ve alarm tarafını birleştirmek, hem teknik hem iş ekipleri için çok değerli oluyor.

Hosted İzleme Çözümleri: Avantajlar, Dezavantajlar ve Hibrit Model

Kendi Prometheus veya Zabbix altyapınızı kurmak yerine, hosted (SaaS) izleme servisleri kullanmak da bir seçenek. Bu tür çözümler genellikle aşağıdaki avantajları sunar:

• Altyapı yönetimi, ölçeklendirme ve yedeklemenin servis sağlayıcı tarafından yapılması.
• Hazır dashboard şablonları, entegrasyonlar ve gelişmiş uyarı kanalları.
• Takım yönetimi, yetkilendirme ve audit log gibi kurumsal özellikler.

Ancak bazı dezavantajları da vardır:

• Verinin ülke dışına çıkması durumunda KVKK/GDPR açısından değerlendirme gerekebilir.
• Çok yoğun metrik hacminde aylık maliyet hızla artabilir.
• İnternet bağlantısına bağımlılık; iç network’teki bazı sistemleri izlemek zorlaşabilir.

Bu nedenle DCHost tarafında sıkça gördüğümüz model, hibrit yaklaşımdır:

• Kritik altyapı metrikleri (CPU, RAM, disk, network, veritabanı) için self-hosted Prometheus/Zabbix.
• Uptime, SSL süresi, domain sona erme tarihi gibi dışarıdan izlenmesi gereken bileşenler için hosted uptime/website monitoring servisleri.

Web sitenizin dışarıdan erişilebilirliğini, SSL ve domain alarm sistemlerini kurmak için hazırladığımız uptime izleme rehberimiz ve ajanslar için müşteri sitelerini izleme mimarisi yazımız, bu hibrit yaklaşımı pratiğe dökmek için iyi bir tamamlayıcıdır.

Çok Kiracılı (Multi-Tenant) İzleme Mimarisi: Ajanslar ve SaaS İçin

Ajanslar, SaaS sağlayıcıları ve çok markalı gruplar için izleme sisteminin en zor kısmı, izin ve ayrıştırma mimarisi oluyor. İşte burada etiketler (labels), klasör yapıları ve proje bazlı izolasyon kritik hale geliyor.

Prometheus/Grafana Tarafında Çok Kiracılı Yapı

• Her müşteri veya ürün için label stratejisi belirleyin: customer="musteriA", env="prod", service="web" gibi.
• Grafana’da folder ve team yapısını kullanarak dashboard’ları müşteri veya ürün bazlı ayırın.
• Data source’ları ortak tutup dashboard seviyesinde değişkenler (variables) ile filtreleme yapın.
• Alertmanager tarafında routing rules ile müşteriye özel alarm e-posta/kanal tanımlayın.

Böylece hem tek bir merkezi izleme altyapısı yönetir, hem de farklı müşterilerin verilerini mantıksal olarak ayrıştırmış olursunuz. Gerektiğinde fiziksel veya sanal olarak da ayırmak (ayrı Prometheus instanceları) mümkün.

Zabbix Tarafında Çok Kiracılı Yapı

• Her müşteri için ayrı host group ve mümkünse ayrı proxy kullanmak, network ve yetki izolasyonu sağlar.
• Kullanıcı gruplarını host group bazlı yetkilendirerek, her müşterinin sadece kendi sunucularını görmesini sağlayabilirsiniz.
• Trigger ve alarm kurallarını host template’ler üzerinden yöneterek, müşteri bazlı ince ayarları kopyalamadan uygulayabilirsiniz.

Hem Prometheus hem Zabbix tarafında, çok kiracılı mimariyi kurarken log tarafını da unutmamak önemli. Örneğin Loki + Promtail + Grafana ile merkezi loglama rehberimizde anlattığımız label stratejisini, Prometheus’taki label yapınızla uyumlu kurarsanız, hem metrik hem log tarafında aynı filtrelerle çalışabilirsiniz.

DCHost Üzerinde Örnek Mimariler

1) Orta Ölçekli E-Ticaret Kümesi

Senaryo: DCHost üzerinde 3 web VPS’i, 2 veritabanı VPS’i, 1 Redis sunucusu ve bir de arka plan işleri için ayrı bir VPS çalışıyor.

• Merkezi izleme için ayrı bir DCHost VPS üzerinde Prometheus + Alertmanager + Grafana.
• Tüm uygulama ve veritabanı sunucularında Node Exporter, DB/Redis exporter’ları.
• Nginx/Apache access logları, ayrı bir DCHost VPS’inde çalışan Loki’ye Promtail ile akıyor.
• Uptime, SSL süresi ve domain bitiş tarihleri, harici uptime izleme + DNS/WHOIS monitoring ile takip ediliyor.

Bu mimaride, sepet veya ödeme adımında hata artışı olduğunda hem Prometheus metriklerinden (HTTP 5xx, response time) hem de Loki loglarından (belirli ödeme hatası kodları) tetiklenen alarmlar ile birkaç dakika içinde sorunu fark etmek mümkün.

2) Ajanslar İçin Onlarca Müşteri Sitesini İzleme

Senaryo: Ajans olarak DCHost üzerinde reseller, shared hosting ve birkaç VPS/dedicated ile 50+ WordPress/WooCommerce sitesi yönetiyorsunuz.

• Merkezi izleme için tek bir DCHost VPS’inde Prometheus + Grafana.
• Yüksek trafikli veya kritik sitelerin bulunduğu VPS/dedicated sunucularda Node Exporter.
• Tüm siteler için harici uptime + SSL + domain izleme (hibrit model).
• Grafana’da müşteri bazlı klasörler, ajans içi ekipler için farklı dashboard ve alarm kanalları.

Böyle bir yapıda, uptime ve SSL tarafı için ajanslara özel hazırladığımız müşteri sitelerini izleme mimarisi rehberi ile bu yazıdaki metrik tabanlı izlemeyi birleştirmek, ajansın operasyon yükünü ciddi biçimde hafifletiyor.

3) Colocation Sunucular İçin Veri Merkezi İçi İzleme

Senaryo: Kendi fiziksel sunucularınızı DCHost veri merkezinde colocation ile barındırıyor, üzerinde hem web uygulamaları hem de kurumsal servisler (ERP, CRM vb.) çalıştırıyorsunuz.

• Veri merkezi içinde izole bir izleme VLAN’ı oluşturarak Prometheus/Zabbix sunucusunu bu VLAN’a koymak.
• Tüm colocation sunucularında Node Exporter/Zabbix Agent çalıştırmak.
• Gerekirse Zabbix Proxy veya ek Prometheus instanceları ile segmentasyon yapmak.
• Uygulama loglarını yine veri merkezi içindeki merkezi bir Loki/ELK kümesine toplamak.

Böylece hem internet bağımlılığınız azalır, hem de veri merkezinin sağladığı düşük gecikme ve yüksek bant genişliği ile izleme trafiğini dışarı çıkarmadan yönetmiş olursunuz.

Sonuç ve Yol Haritası: Küçük Başlayın, Merkezileştirerek Büyütün

Merkezi sunucu izleme ve alarm mimarisi, bir günde kurup bitecek bir proje değil; daha çok adım adım inşa edilen, büyüdükçe olgunlaşan bir altyapı. Burada en sağlıklı yaklaşım, önce kritik birkaç sistemden başlayıp, mimariyi oturttukça kapsamı genişletmek:

1. DCHost üzerindeki 1–2 kritik VPS/dedicated sunucunuz için Node Exporter + Prometheus + Grafana üçlüsünü ayağa kaldırın.
2. CPU, RAM, disk, HTTP 5xx ve SSL bitiş süresi gibi birkaç net alarm kuralı tanımlayın.
3. Daha sonra veritabanı, queue, cache ve iş metriklerini ekleyin.
4. İhtiyaç oldukça Zabbix veya hosted izleme çözümlerini hibrit bir modelde devreye alın.

DCHost olarak hem VPS, dedicated sunucu hem de colocation altyapılarında bu tür merkezi izleme mimarilerini gerçek projeler üzerinde kurup yönetiyoruz. Kendi altyapınız için uygun yaklaşımı netleştirmek, kapasite planı çıkarmak veya Prometheus/Zabbix kurulumunu DCHost üzerinde konumlandırmak isterseniz, ekibimizle birlikte somut bir yol haritası çıkarmaktan memnuniyet duyarız.

İzleme mimarinizi kurduğunuzda, sadece kesintileri daha hızlı fark etmeyecek; aynı zamanda kapasite planlama, maliyet optimizasyonu ve güvenlik denetimleri için de çok güçlü bir veri kaynağı elde etmiş olacaksınız. Bir sonraki adımda log ve iz katmanını da bu yapıya ekleyerek, gerçekten bütünlüklü bir observability platformuna geçmek için rehberlerimizi takip etmeye devam edebilirsiniz.