Metrikten aksiyona, ölçülebilir gözlemleme
Grafana ve Prometheus İzleme Kurulumu
Prometheus ile altyapı ve uygulama metriklerini topluyor, Grafana ile anlaşılır dashboard, alarm ve kapasite görünürlüğüne dönüştürüyoruz. Antalya’da yerinde keşif; Türkiye genelinde uzaktan mimari, kurulum ve teknik devralma desteği sunuyoruz.
İzleme kapsamını metrik envanteriyle çıkaralım
Sunucu, uygulama, container, network ve kritik servis envanterinizi paylaşın. Exporter, target, scrape aralığı, saklama, dashboard ve alarm sorumluluğunu ilk görüşmede birlikte netleştirelim.
Temel yaklaşım
Dashboard, ölçüm tasarımının son halkasıdır
Grafana ve Prometheus kurulumu, hazır bir dashboard içe aktarmaktan ibaret değildir. Önce hangi hizmetin neden izleneceği, hangi metriğin aksiyon üreteceği ve olayın kim tarafından değerlendirileceği belirlenir.
CPU ve bellek grafikleri başlangıç sağlar; ancak gerçek operasyon görünürlüğü servis gecikmesi, hata oranı, kuyruk derinliği, kapasite eğilimi, bağımlılık ve iş metriği gibi bağlama özel ölçümlerle oluşur. Görsel paneller, bu ölçüm modelinin kullanıcıya dönük yüzüdür.
Mimari katmanlar
Sağlıklı gözlemleme mimarisi dört katmanda kurulur
Prometheus hedefleri statik yapılandırma veya service discovery ile bulabilir; metrikleri çoğunlukla HTTP üzerinden pull modeliyle toplar. Her katmanın kaynak, güvenlik ve işletme sorumluluğu ayrı kaydedilir.
Uygulama ve exporter
Uygulama metrik uçları, node ve servis exporterları, SNMP veya sentetik kontroller ölçümün kaynağını oluşturur.
Target ve keşif
Scrape job, service discovery, relabeling, interval ve timeout kuralları doğru hedefin doğru kimlikle toplanmasını sağlar.
Prometheus ve PromQL
Prometheus zaman serilerini saklar; PromQL, recording rule ve alert rule ile ham veriyi anlamlı sorgu ve koşullara dönüştürür.
Grafana ve operasyon
Data source, dashboard, Explore, kullanıcı erişimi ve bildirim politikaları veriyi ekiplerin karar vereceği görünüme taşır.
Mimari sınır: Grafana veri toplama katmanının, Prometheus ise uzun süreli ve sınırsız ölçeklenen merkezi depolamanın otomatik karşılığı değildir. Yerleşim; Prometheus mimarisi, saklama hedefi, kullanıcı sayısı, yüksek erişilebilirlik ve işletme modeli üzerinden tasarlanır.
Metrik ve label tasarımı
Metrik sayısından önce metriğin anlamı belirlenir
Her ek metriğin seri, disk, bellek ve sorgu maliyeti vardır. İhtiyaç duyulmayan metrikleri toplamak, daha fazla görünürlük yerine daha fazla gürültü ve cardinality riski üretir.
- Metrik envanteri
- Hizmet, bileşen, ölçüm amacı, birim, beklenen aralık ve aksiyon sahibi kaydedilir.
- Label sınırı
- Ortam, ekip, lokasyon ve servis gibi kontrollü boyutlar kullanılır; kullanıcı veya istek kimliği gibi sınırsız değerler metrik label’ına taşınmaz.
- Scrape davranışı
- Interval ve timeout, metrik değişim hızı, hedef yükü, ağ gecikmesi ve alarm hassasiyetine göre belirlenir.
- Recording rule
- Sık ve maliyetli sorgular önceden hesaplanır; kural adı, kaynak PromQL ve güncelleme sıklığı dokümante edilir.
Yapılandırma notu: Scrape job ve rule dosyaları sürüm kontrollü tutulur. Prometheus, geçerli yapılandırmayı çalışma sırasında yeniden yükleyebilir; hatalı dosyanın üretime geçmemesi için promtool, pilot ve kontrollü değişiklik akışı kullanılır.
İzleme kapsamı
Exporter seçimi sistem ve operasyon amacına göre yapılır
Sunucu ve işletim sistemi
İşlemci, bellek, disk, dosya sistemi, süreç ve işletim sistemi sağlık metrikleri hedeflenir.
Container ve Kubernetes
Node, pod, workload, kaynak kullanımı, restart, limit ve platform bileşeni metrikleri iş yükü bağlamında izlenir.
Network ve altyapı
Uygun exporter üzerinden switch, router, firewall, UPS ve çevresel bileşenlerin gerekli metrikleri toplanır.
Uygulama ve API
İstek, gecikme, hata, kuyruk, bağlantı havuzu ve iş sonucu gibi uygulamaya özgü metrikler tasarlanır.
Veritabanı ve servis
Bağlantı, sorgu süresi, kilit, replikasyon, kapasite ve servis erişilebilirliği uygun entegrasyonla ölçülür.
Sentetik kontrol
HTTP, TCP, DNS, ICMP ve sertifika kontrolleri kullanıcı yoluna yakın erişilebilirlik sinyali sağlar.
Kapasite ve saklama
Seri sayısı, örnek hızı ve sorgu yükü birlikte ölçülür
Prometheus kaynağı yalnız hedef sayısıyla belirlenmez. Aynı hedef, label ve metrik yapısına göre çok farklı miktarda aktif seri ve disk yükü oluşturabilir.
- Aktif time series ve saniyedeki örnek miktarı
- Scrape aralığı, timeout ve hedef yanıt süresi
- Retention süresi, TSDB diski ve büyüme payı
- PromQL, recording rule ve dashboard sorgu yükü
- Eşzamanlı kullanıcı ve panel yenileme sıklığı
- Yedekleme, yüksek erişilebilirlik ve remote write hedefi
Saklama kararı: Prometheus local storage tek düğüm ölçeği ve dayanıklılığıyla sınırlıdır. Uzun süreli, çok lokasyonlu veya merkezi saklama gerekiyorsa remote storage entegrasyonları, veri hacmi, ağ maliyeti ve geri dönüş planıyla birlikte değerlendirilir.
Devreye alma
Grafana ve Prometheus projesi altı kontrollü aşamada ilerler
- 01
Servis ve metrik envanteri
Lokasyon, sistem, uygulama, iş sahibi, kritik kullanıcı yolu ve mevcut gözlemleme araçları kaydedilir.
- 02
Exporter ve target matrisi
Her hedef için veri kaynağı, erişim yöntemi, scrape job, label, interval, timeout ve sorumlu ekip yazılır.
- 03
Kaynak ve saklama planı
Aktif seri, örnek hızı, retention, PromQL yükü, disk, yedekleme, HA ve remote write ihtiyacı boyutlandırılır.
- 04
Pilot veri toplama
Exporter, service discovery, relabeling, target health, scrape süresi ve cardinality gerçek sistemlerde gözlenir.
- 05
Dashboard ve alarm testi
PromQL, panel, değişken, kural, bekleme, gruplama, contact point, silence ve recovery senaryoları sınanır.
- 06
Kabul ve teknik devralma
Yapılandırma, dashboard JSON’ları, erişimler, envanter, runbook, yedek ve sorumluluk matrisi teslim edilir.
Güvenli gözlemleme
Metrik uçları ve dashboard erişimi ayrı korunur
İzleme platformu altyapı adları, performans davranışı ve servis topolojisi gibi hassas teknik bilgi taşır. Bu nedenle yalnız panel şifresi değil, veri toplama ve sorgulama yolları da güvenlik kapsamına alınır.
- Prometheus, exporter ve API uçlarını internete kapatma
- Firewall, yönetim VLAN’ı, VPN veya reverse proxy sınırı
- TLS, sertifika doğrulama ve güvenli secret yönetimi
- Grafana kullanıcı, ekip, klasör ve veri kaynağı yetkileri
- Anonim erişim ve paylaşım seçenekleri için risk kararı
- Yedek, güncelleme, denetim kaydı ve geri dönüş planı
Güvenlik notu: Prometheus projesi, metrik ve API uçlarının bilinçsizce internete açılmamasını özellikle belirtir. Uygulama sırasında Prometheus güvenlik modeli ve Grafana güvenlik seçenekleri mevcut ağ politikalarıyla birlikte değerlendirilir.
Alarm kalitesi
Alarm kuralı, yönlendirme ve sahiplik birlikte tasarlanır
Bir grafiğin eşik aşması tek başına operasyon alarmı değildir. Koşulun sürekliliği, önem seviyesi, etkilenen servis, sorumlu ekip ve geri dönüş davranışı açıkça tanımlanmalıdır.
Kural ve bağlam
- PromQL veya Grafana-managed kural
forsüresi ve recovery koşulu- Servis, ortam, ekip ve önem label’ları
- Runbook ve beklenen ilk kontrol
Bildirim ve eskalasyon
- Contact point ve notification policy
- Label eşleştirme ve gruplama
- Mute timing ve bakım penceresi
- Tekrar aralığı ve sorumlu ekip kabulü
Gürültü kontrolü: Grafana notification policy yapısı label eşleştirme, gruplama ve zamanlama üzerinden çalışır. Kritik kurallar, resmî bildirim politikası yaklaşımıyla ve kontrollü olay senaryolarıyla doğrulanır.
Sahadan operasyona
Target doğrulaması ve alarm testi aynı teslim planında ilerler
Target health doğrulanmadan dashboard; alarm sahipliği ve bildirim yolu sınanmadan gözlemleme projesi tamamlanmış sayılmaz. Kabul testinde veri, sorgu, görsel ve aksiyon zinciri birlikte ölçülür.
Proje teslimi
İşletilebilir bir gözlemleme yapısı teslim edilir
Kurulum sonunda yalnız çalışan paneller değil, teknik ekibin sürdürebileceği yapılandırma, sorgu, alarm, erişim ve sorumluluk kayıtları bulunmalıdır.
Target matrisiHedef, exporter, job, label, interval ve sahiplik
Metrik sözlüğüMetrik amacı, birim, eşik ve iş bağlamı
Dashboard setiPanel, PromQL, değişken, veri kaynağı ve klasör
Alarm matrisiKural, önem, bekleme, yönlendirme ve runbook
Kaynak planıSeri, örnek, retention, disk ve büyüme payı
Teknik devralmaYedek, güncelleme, erişim, geri dönüş ve sorumluluk
İşletme sorumluluğu
Platform yönetimi ile 7/24 müdahale aynı hizmet değildir
Prometheus’un veri toplaması ve Grafana’nın alarm üretmesi, olayın değerlendirildiği veya giderildiği anlamına gelmez. Takip saatleri, sorumlu ekip ve eskalasyon süresi sözleşmede ayrılır.
Kurum tarafından işletme
Biga Bilişim kurulum, dokümantasyon ve devralma sağlar; günlük alarm ve platform takibini kurum ekibi yürütür.
Ortak yönetim
Kurum ilk değerlendirmeyi yapar; belirlenen alarm, değişiklik veya kapasite konuları Biga Bilişim’e eskale edilir.
Yönetilen izleme
Kontrol saatleri, alarm sınıfları, iletişim kanalları, kayıt ve müdahale sınırları ayrı NOC hizmet kapsamında tanımlanır.
Kullanım profilleri
Kapsam işletmenin servis ve veri yapısına göre şekillenir
- Küçük ve orta işletme
- Temel sunucu, internet, uygulama ve servis görünürlüğü; sınırlı fakat aksiyon odaklı dashboard ve alarm seti.
- Yazılım ve SaaS ekipleri
- Uygulama gecikmesi, hata, istek, kuyruk, veritabanı ve deployment etkisini aynı servis bağlamında izleme.
- Üretim, otel ve lojistik
- Lokasyon, kritik servis, network, sunucu ve iş sürekliliği metriklerini operasyon sorumluluğuyla birleştirme.
- Çok şubeli ve kurumsal yapı
- Merkezi görünürlük, ekip ve ortam label’ları, standart dashboard, alarm politikası, HA ve uzun süreli saklama planı.
Sık sorulan sorular
Grafana ve Prometheus kurulumu hakkında merak edilenler
Grafana ile Prometheus arasındaki fark nedir?
Prometheus hedeflerden zaman serisi metriklerini toplar, saklar ve PromQL ile sorgular. Grafana ise Prometheus ve diğer veri kaynaklarındaki bilgileri dashboard, Explore ve alarm ekranlarında görünür hale getirir. İki araç aynı görevi yapmaz; ölçüm modeli, veri toplama, görselleştirme ve alarm akışı birlikte tasarlandığında tamamlayıcı çalışır.
Grafana ve Prometheus ile hangi sistemler izlenebilir?
Uygun exporter veya uygulama metriği bulunduğunda Linux ve Windows sunucular, sanal makineler, container ve Kubernetes bileşenleri, veritabanları, web servisleri, uygulamalar, ağ cihazları ve özel iş metrikleri izlenebilir. Gerçek kapsam; desteklenen entegrasyon, erişim yöntemi, metrik kalitesi, label yapısı ve kurumun operasyon hedefleri üzerinden doğrulanır.
Prometheus exporter ve scrape target nasıl belirlenir?
Önce hizmet, cihaz ve uygulama envanteri çıkarılır; ardından her hedef için yerel metrik uç noktası, uygun exporter veya sentetik kontrol yöntemi seçilir. Target adresi, service discovery, scrape aralığı, timeout, label ve metric relabeling kuralları pilotta sınanır. Gereksiz metrikler ve kontrolsüz label çeşitliliği üretime alınmaz.
Prometheus kapasitesi ve saklama süresi nasıl hesaplanır?
Kapasite hesabında aktif seri sayısı, saniyedeki örnek miktarı, scrape aralığı, retention süresi, sorgu ve recording rule yükü, dashboard yenileme sıklığı, disk performansı ve büyüme payı birlikte değerlendirilir. Uzun süreli veya merkezi saklama gerekiyorsa local TSDB sınırlarıyla birlikte remote write ve uyumlu uzak depolama seçenekleri ayrıca planlanır.
Grafana ve Prometheus güvenli şekilde nasıl yayınlanır?
Prometheus metrik ve API uçları doğrudan internete açılmaz. Yönetim ve veri yolları ağ segmenti, firewall, VPN veya reverse proxy ile sınırlandırılır; TLS, kimlik doğrulama, en az yetkili hesaplar ve güvenli secret yönetimi uygulanır. Grafana erişimi kullanıcı, ekip, rol ve veri kaynağı kapsamına göre ayrılır; anonim erişim yalnız bilinçli bir kararla değerlendirilir.
Grafana alarmlarında bildirim gürültüsü nasıl azaltılır?
Alarm kuralına servis, ortam, önem, ekip ve sahiplik label’ları eklenir. Kısa süreli dalgalanmalar için bekleme süresi tanımlanır; notification policy ile benzer olaylar gruplanır, doğru contact point’e yönlendirilir ve bakım zamanlarında susturulur. Her kritik alarmın gerçek veriyle, recovery koşuluyla ve sorumlu ekibin kabulüyle test edilmesi gerekir.
Kurulum hizmeti 7/24 izleme ve müdahaleyi kapsar mı?
Grafana ve Prometheus kurulumu tek başına 7/24 operasyon anlamına gelmez. Platformlar veri toplar, sorgular ve alarm üretir; olayın kim tarafından, hangi saatlerde ve hangi sürede değerlendirileceği ayrı bir işletme kapsamıdır. Kurum içi yönetim, ortak yönetim ve 7/24 NOC hizmeti farklı sorumluluk, kayıt ve eskalasyon seviyeleriyle tanımlanır.
Grafana–Prometheus, Zabbix veya PRTG yerine mi kullanılır?
Grafana ve Prometheus bazı projelerde ana izleme platformu, bazı projelerde ise Zabbix, PRTG, Loki veya bulut servislerini tamamlayan gözlemleme katmanı olabilir. Seçim; uygulama metrikleri, altyapı kapsamı, ekip yetkinliği, lisans yaklaşımı, entegrasyon, saklama, yüksek erişilebilirlik ve işletme sorumluluğu üzerinden pilotla doğrulanmalıdır.
Grafana ve Prometheus teklifi için hangi bilgiler gerekir?
Lokasyon, sunucu, sanallaştırma, container, uygulama ve kritik servis envanteri; mevcut metrik uçları, beklenen dashboardlar, scrape aralığı, retention, alarm kanalları, kullanıcı rolleri, yedekleme ve yüksek erişilebilirlik beklentisi ilk kapsam için yeterlidir. Eksik exporter, target ve label bilgileri keşif ile pilot aşamasında birlikte tamamlanabilir.
Teknik kaynaklar: Prometheus mimarisi·Prometheus yapılandırması·Prometheus storage·Prometheus güvenlik modeli·Grafana Prometheus data source·Grafana provisioning·Bildirim politikaları
Teknik içerik 20 Temmuz 2026 tarihinde resmî Prometheus ve Grafana dokümantasyonu temel alınarak gözden geçirilmiştir. Biga Bilişim, Grafana ve Prometheus mimari, kurulum ve işletme danışmanlığı sunar; bu sayfa proje veya marka sahibi adına resmî temsilcilik ve ürün garantisi iddiası taşımaz. Yazılım sürümü, lisans koşulları ve destek modeli teklif tarihinde doğrulanır.
Ön değerlendirme
Grafana ve Prometheus yapınızı gerçek metrik yüküyle kuralım
Envanterinizi, kritik servislerinizi ve görünürlük hedeflerinizi paylaşın. Exporter, target, Prometheus kaynağı, Grafana dashboardları, saklama, alarm ve işletme sorumluluğunu pilot sonuçlarıyla planlayalım.