Azure Monitor ile İzleme ve Uyarı Yönetimi
Bir üretim ortamında gecenin ikisinde telefon çalmaya başladığında, “acaba ne oldu?” sorusunu sormak yerine zaten ekranın başında hazır olmak istersiniz. İşte Azure Monitor tam da bu noktada devreye giriyor. Uygulamalarınızın, sanal makinelerinizin ve tüm Azure altyapınızın nabzını tutmanızı sağlayan bu servis, reaktif sistem yönetiminden proaktif izlemeye geçişin en önemli araçlarından biri. Bu yazıda Azure Monitor’ü gerçek dünya senaryolarıyla, CLI komutlarıyla ve pratik uyarı konfigürasyonlarıyla ele alacağız.
Azure Monitor Nedir ve Neyi İzler?
Azure Monitor, Azure ekosistemindeki kaynakların metriklerini, loglarını ve izlerini toplayan merkezi bir izleme platformudur. Sadece Azure kaynaklarıyla sınırlı değil; on-premises sunuculardan, diğer bulut sağlayıcılarından ve hatta özel uygulamalardan da veri toplayabilirsiniz.
Temel olarak şu veri tiplerini işler:
- Metrikler: CPU kullanımı, disk I/O, ağ trafiği gibi sayısal zaman serisi verileri
- Loglar: Uygulama logları, sistem olayları, güvenlik kayıtları
- İzler (Traces): Dağıtık sistemlerde uygulama performans takibi
- Değişiklikler: Kaynak konfigürasyonlarındaki değişiklikler
Günlük olarak binlerce sanal makine veya container yöneten bir ekipte çalışıyorsanız, her şeyi tek bir dashboarddan takip etmenin ne kadar değerli olduğunu hemen anlarsınız.
Azure CLI ile Temel Kurulum
Azure Monitor’ü kullanmaya başlamak için öncelikle Azure CLI’ı kurup kimlik doğrulaması yapmanız gerekiyor.
# Azure CLI kurulumu (Ubuntu/Debian)
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
# Giriş yap
az login
# Aboneliğini seç
az account set --subscription "your-subscription-id"
# Azure Monitor uzantısını yükle
az extension add --name monitor-control-service
Kurulum tamamlandıktan sonra mevcut izleme verilerinizi sorgulamaya başlayabilirsiniz.
Metrik Sorgulama ve Anlık Durum Kontrolü
Sysadmin olarak ilk yapmanız gereken şey kaynaklarınızın mevcut metriklerini incelemek. CLI üzerinden bu işlemi oldukça hızlı yapabilirsiniz.
# Bir sanal makinenin CPU metriklerini çek
az monitor metrics list
--resource "/subscriptions/{subscription-id}/resourceGroups/{rg-name}/providers/Microsoft.Compute/virtualMachines/{vm-name}"
--metric "Percentage CPU"
--start-time 2024-01-15T00:00:00Z
--end-time 2024-01-15T23:59:59Z
--interval PT1H
--output table
# Birden fazla metriği aynı anda sorgula
az monitor metrics list
--resource "/subscriptions/{sub-id}/resourceGroups/prod-rg/providers/Microsoft.Compute/virtualMachines/web-server-01"
--metric "Percentage CPU,Available Memory Bytes,Disk Read Bytes,Disk Write Bytes"
--interval PT5M
--output json
Bu komutların çıktısını bir script içinde işleyerek günlük rapor üretebilirsiniz. Biz bunu production ortamlarında her sabah 08:00’de çalışacak şekilde cron job’a bağlıyoruz ve sonuçları Teams kanalına gönderiyoruz.
Log Analytics Workspace Oluşturma
Azure Monitor’ün gerçek gücü Log Analytics Workspace’ten geliyor. Burası tüm loglarınızın toplandığı, sorgulandığı ve analiz edildiği merkez.
# Resource group oluştur
az group create
--name monitoring-rg
--location eastus
# Log Analytics Workspace oluştur
az monitor log-analytics workspace create
--resource-group monitoring-rg
--workspace-name prod-log-workspace
--location eastus
--sku PerGB2018
--retention-time 90
# Workspace ID ve key'i al (agent kurulumu için gerekli)
az monitor log-analytics workspace show
--resource-group monitoring-rg
--workspace-name prod-log-workspace
--query "{id:customerId, key:sharedKeys.primarySharedKey}"
--output json
–retention-time parametresi önemli: 30 ile 730 gün arasında ayarlayabilirsiniz. Maliyet optimizasyonu açısından log tutma süresini dikkatli belirleyin. Compliance gereksinimleriniz yoksa 90 gün genellikle iyi bir başlangıç noktasıdır.
Uyarı Kuralları Oluşturma
İzlemenin can damarı uyarılar. Azure Monitor’de uyarılar üç ana bileşenden oluşur: Kural (Rule), Aksiyon Grubu (Action Group) ve Uyarı Koşulu (Alert Condition).
Önce aksiyon grubu oluşturalım. Bu grup, uyarı tetiklendiğinde kime ne yapılacağını tanımlar.
# E-posta ve SMS bildirim için aksiyon grubu oluştur
az monitor action-group create
--resource-group monitoring-rg
--name critical-alerts-ag
--short-name criticalag
--action email admin-email [email protected]
--action sms oncall-sms +905551234567
# Webhook ekle (Slack, Teams veya özel endpoint için)
az monitor action-group update
--resource-group monitoring-rg
--name critical-alerts-ag
--add-action webhook teams-webhook "https://outlook.office.com/webhook/your-teams-webhook-url"
Şimdi gerçek bir uyarı kuralı ekleyelim. CPU kullanımı %85’i geçtiğinde uyarı versin:
# CPU yüksek kullanım uyarısı
az monitor metrics alert create
--resource-group monitoring-rg
--name "High-CPU-Alert"
--scopes "/subscriptions/{sub-id}/resourceGroups/prod-rg/providers/Microsoft.Compute/virtualMachines/web-server-01"
--condition "avg Percentage CPU > 85"
--window-size 5m
--evaluation-frequency 1m
--severity 2
--description "CPU kullanımı son 5 dakikada %85'in üzerinde"
--action "/subscriptions/{sub-id}/resourceGroups/monitoring-rg/providers/microsoft.insights/actionGroups/critical-alerts-ag"
–severity değerleri şöyle çalışır:
- 0: Kritik
- 1: Hata
- 2: Uyarı
- 3: Bilgi
- 4: Ayrıntılı
Gerçek Dünya Senaryosu: E-ticaret Platformu İzleme
Diyelim ki 50 sanal makineden oluşan bir e-ticaret altyapısı yönetiyorsunuz. Kara Cuma öncesinde izleme kurallarınızı güçlendirmeniz gerekiyor. İşte bu senaryo için hazırladığım bir toplu uyarı konfigürasyon scripti:
#!/bin/bash
# ecommerce-monitoring-setup.sh
SUBSCRIPTION_ID="your-sub-id"
RG="ecommerce-prod-rg"
MONITOR_RG="monitoring-rg"
ACTION_GROUP="/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${MONITOR_RG}/providers/microsoft.insights/actionGroups/critical-alerts-ag"
# Web sunucuları için VM listesi
declare -a SERVERS=("web-01" "web-02" "web-03" "db-primary" "db-replica")
for SERVER in "${SERVERS[@]}"; do
RESOURCE_ID="/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${RG}/providers/Microsoft.Compute/virtualMachines/${SERVER}"
echo "İzleme kuralları oluşturuluyor: ${SERVER}"
# CPU uyarısı
az monitor metrics alert create
--resource-group ${MONITOR_RG}
--name "CPU-High-${SERVER}"
--scopes "${RESOURCE_ID}"
--condition "avg Percentage CPU > 80"
--window-size 5m
--evaluation-frequency 1m
--severity 2
--action "${ACTION_GROUP}"
--output none
# Bellek uyarısı (Available Memory Bytes 500MB altına düşerse)
az monitor metrics alert create
--resource-group ${MONITOR_RG}
--name "Memory-Low-${SERVER}"
--scopes "${RESOURCE_ID}"
--condition "avg Available Memory Bytes < 524288000"
--window-size 5m
--evaluation-frequency 1m
--severity 1
--action "${ACTION_GROUP}"
--output none
echo "${SERVER} için izleme kuralları oluşturuldu."
done
echo "Tüm sunucular için izleme konfigürasyonu tamamlandı."
Bu scripti çalıştırdıktan sonra her sunucu için otomatik olarak CPU ve bellek uyarıları devreye giriyor. Kara Cuma’da gereksiz gece mesaisi yapmamak için bu tür otomasyonlar hayat kurtarıcı.
KQL ile Log Sorguları
Azure Monitor’ün en güçlü özelliklerinden biri Kusto Query Language (KQL) ile log sorgulama. Log Analytics Workspace üzerinde çalışan bu dil, SQL’e benzer ama zaman serisi verileri için çok daha yetenekli.
# KQL sorgusu CLI üzerinden çalıştır
az monitor log-analytics query
--workspace "/subscriptions/{sub-id}/resourceGroups/monitoring-rg/workspaces/prod-log-workspace"
--analytics-query "
Heartbeat
| where TimeGenerated > ago(1h)
| summarize LastHeartbeat = max(TimeGenerated) by Computer
| where LastHeartbeat < ago(5m)
| project Computer, LastHeartbeat
"
--output table
Son 5 dakikadır heartbeat göndermeyen sunucuları bu sorguyla tespit edebilirsiniz. Son derece kullanışlı bir canlılık kontrolü.
Hata loglarını analiz etmek için şu sorguyu kullanabilirsiniz:
# Son 24 saatin kritik hataları
az monitor log-analytics query
--workspace "/subscriptions/{sub-id}/resourceGroups/monitoring-rg/workspaces/prod-log-workspace"
--analytics-query "
Event
| where TimeGenerated > ago(24h)
| where EventLevelName == 'Error' or EventLevelName == 'Critical'
| summarize ErrorCount = count() by Computer, EventLog, Source
| order by ErrorCount desc
| take 20
"
--output table
Bu sorguyu her sabah çalıştırarak günlük hata özetini çıkarıyoruz. 20 satırla sınırlı tutuyoruz ama gerçek ortamda “take” değerini ihtiyacınıza göre ayarlayın.
Diagnostic Settings ile Log Toplama Genişletme
Azure kaynaklarının platform loglarını ve metriklerini Log Analytics’e yönlendirmek için Diagnostic Settings kullanıyoruz. Bir Azure SQL veritabanı için örnek:
# Azure SQL için tanılama ayarları
az monitor diagnostic-settings create
--resource "/subscriptions/{sub-id}/resourceGroups/prod-rg/providers/Microsoft.Sql/servers/prod-sql-server/databases/main-db"
--workspace "/subscriptions/{sub-id}/resourceGroups/monitoring-rg/workspaces/prod-log-workspace"
--name "sql-diagnostics"
--logs '[
{
"category": "SQLInsights",
"enabled": true,
"retentionPolicy": {"days": 30, "enabled": true}
},
{
"category": "QueryStoreRuntimeStatistics",
"enabled": true,
"retentionPolicy": {"days": 30, "enabled": true}
},
{
"category": "Errors",
"enabled": true,
"retentionPolicy": {"days": 90, "enabled": true}
}
]'
--metrics '[
{
"category": "Basic",
"enabled": true,
"retentionPolicy": {"days": 30, "enabled": true}
}
]'
Production veritabanlarında bu konfigürasyon olmadan yavaş sorgu tespiti yapmak neredeyse imkansız. QueryStoreRuntimeStatistics kategorisi özellikle performans sorunlarını gün yüzüne çıkarmak için kritik.
Application Insights Entegrasyonu
Uygulama katmanını izlemek için Azure Monitor’ün bir parçası olan Application Insights’ı kullanıyoruz. .NET, Java, Node.js ve Python uygulamaları için native desteği var.
# Application Insights bileşeni oluştur
az monitor app-insights component create
--app prod-api-insights
--location eastus
--resource-group monitoring-rg
--workspace "/subscriptions/{sub-id}/resourceGroups/monitoring-rg/workspaces/prod-log-workspace"
--application-type web
# Instrumentation key'i al
az monitor app-insights component show
--app prod-api-insights
--resource-group monitoring-rg
--query "instrumentationKey"
--output tsv
# Availability test ekle (her 5 dakikada URL kontrolü)
az monitor app-insights web-test create
--resource-group monitoring-rg
--app-insights-name prod-api-insights
--name "homepage-availability"
--location eastus
--url "https://api.sirketiniz.com/health"
--frequency 300
--timeout 30
Availability test, dünyanın farklı noktalarından uygulamanıza ping atarak erişilebilirliği kontrol eder. Hizmet 3 farklı lokasyondan erişilemez olduğunda otomatik uyarı tetikler. Müşterilerinizden önce siz haberdar olursunuz.
Uyarı Bastırma ve Bakım Pencereleri
Production ortamında planlı bakım yapıyorsanız, bu sürede uyarıların gelmesini istemezsiniz. Azure Monitor’de bu için “Action Rule” kullanılıyor:
# Bakım penceresi için uyarı bastırma kuralı oluştur
az monitor alert-processing-rule create
--resource-group monitoring-rg
--name "weekend-maintenance-suppression"
--filter-target-resource-groups "/subscriptions/{sub-id}/resourceGroups/prod-rg"
--rule-type Suppression
--schedule-recurrence-type Weekly
--schedule-recurrence-days Saturday Sunday
--schedule-start-datetime "2024-01-20 02:00:00"
--schedule-end-datetime "2024-01-20 06:00:00"
--description "Hafta sonu gece bakım penceresi - 02:00-06:00"
Bu kural hafta sonları gece 02:00-06:00 arasında prod-rg kapsamındaki tüm uyarıları bastırır. Bakım görevleri sırasında gereksiz bildirim almayı önler.
Maliyet Yönetimi ve İzleme Optimizasyonu
Azure Monitor kullandıkça maliyet oluşur. Log ingestion ve retention en büyük maliyet kalemleri. Şu komutla mevcut workspace maliyetinizi analiz edebilirsiniz:
# Günlük log ingestion miktarını kontrol et
az monitor log-analytics query
--workspace "/subscriptions/{sub-id}/resourceGroups/monitoring-rg/workspaces/prod-log-workspace"
--analytics-query "
Usage
| where TimeGenerated > ago(7d)
| summarize TotalGB = sum(Quantity) / 1024 by DataType
| order by TotalGB desc
| take 15
"
--output table
Bu sorgu hangi log tipinin ne kadar alan kapladığını gösterir. Gereksiz yüksek veri üreten kaynakları tespit edip diagnostic settings’ten çıkarabilirsiniz. Bizim ortamımızda bir dönem IIS logları her gün 50 GB veri üretiyordu, gereksiz alanları filtreyince günlük 40 GB’a düşürdük.
Dashboard ve Workbook Otomasyonu
Azure Monitor’de görselleştirme için Workbook’lar kullanılıyor. Bunları ARM template ile otomatik deploy edebilirsiniz:
# Mevcut workbook'ları listele
az monitor app-insights workbook list
--resource-group monitoring-rg
--query "[].{Name:displayName, Category:category, LastModified:timeModified}"
--output table
# Shared query oluştur
az monitor log-analytics query-pack query create
--resource-group monitoring-rg
--query-pack-name prod-query-pack
--name "critical-errors-last-hour"
--display-name "Son 1 Saatin Kritik Hataları"
--description "Tüm sunuculardaki kritik hataları listeler"
--body "
Event
| where TimeGenerated > ago(1h)
| where EventLevelName == 'Error'
| project TimeGenerated, Computer, Source, RenderedDescription
| order by TimeGenerated desc
"
--categories '["monitoring"]'
Shared query’leri ekip içinde paylaşarak herkesin aynı standardize sorguları kullanmasını sağlayabilirsiniz. Yeni ekip üyeleri geldiğinde “şu log nasıl bakılır” sorusuna query pack’ten göndererek cevap veriyoruz.
Sonuç
Azure Monitor, tek başına bir araç değil; geniş bir izleme ekosistemi. Metriklerden loglara, uygulama izlemeden uyarılara kadar tüm operasyonel görünürlük ihtiyaçlarınızı karşılayabilecek kapasitede.
Başlangıç için şu adımları takip etmenizi öneririm:
- Önce temeli kur: Log Analytics Workspace ve Action Group olmadan hiçbir şey çalışmaz, bu ikisini önce oluşturun.
- En kritik uyarılarla başla: CPU, bellek ve disk doluluk uyarıları temel ihtiyaçlarınızı karşılar, bunları ilk hafta kurun.
- KQL öğren: İlk başta karmaşık gözükse de KQL sorgu yazmayı öğrenmek Azure ortamında hayatınızı kolaylaştırır.
- Maliyeti takip et: Log retention ve ingestion maliyetlerini haftalık kontrol edin, küçük bir optimizasyon büyük tasarruf sağlayabilir.
- Uyarı yorgunluğundan kaçın: Çok fazla uyarı ayarlamak ekibi körleştirir. Gerçekten aksiyon gerektiren durumlara odaklanın.
Production ortamını izlemenin en büyük getirisi reaktiflikten proaktifliğe geçiştir. Müşteriniz şikayet etmeden önce siz sorunu tespit edip çözdüğünüzde, hem sistem güvenilirliğiniz artar hem de gece yarısı telefon çalmalarından kurtulursunuz. Azure Monitor bu hedefe ulaşmak için ihtiyacınız olan altyapıyı sağlıyor; gerisi sizin konfigürasyonunuza kalmış.
