- 01Azure Monitor metrics, logs, traces ve event telemetry üzerinden cloud ve hybrid ortamların health, performance ve reliability durumunu izlemeye yardımcı olur.
- 02Metrics hızlı health ve alerting için; logs ise ayrıntılı root-cause analysis için kullanılır ve iki veri tipi birlikte değerlendirilmelidir.
- 03Production alert; condition yanında severity, owner, action group, escalation ve runbook içermelidir.
- 04Her telemetry'yi toplamak doğru değildir; log ingestion, retention ve duplicate collection maliyet ve gürültü açısından yönetilmelidir.
- 05Monitoring'in amacı dashboard sayısını artırmak değil, kullanıcı etkisini erken görmek ve incident response süresini azaltmaktır.
Kısaca
Azure Monitor, Azure ve hibrit ortamlardan metrics, logs, traces ve event telemetry toplayıp analiz etmeye ve bu sinyaller üzerinden alarm/aksiyon üretmeye yarayan Microsoft gözlemlenebilirlik servisidir. Production ortamında amaç mümkün olan her şeyi toplamak değil; kullanıcı etkisini, kapasiteyi, güvenliği ve servis sağlığını ölçen doğru sinyalleri izlemek, doğru kişiye doğru alarmı göndermek ve alarmı bir runbook'a bağlamaktır. Dynamis Teknoloji, Azure Monitor'u dashboard aracı olarak değil, incident response ve günlük operasyon modelinin parçası olarak ele alır.
Azure Monitor nedir?
Microsoft Azure Monitor'u cloud ve hybrid ortamlardan telemetry toplayan, analiz eden ve bu telemetry üzerinden aksiyon üreten birleşik observability servisi olarak tanımlar.
Azure Monitor içinde farklı veri tipleri birlikte kullanılabilir:
- metrics
- logs
- traces
- events
- application telemetry
- platform activity
- resource health sinyalleri
Bu veriler yalnız dashboard çizmek için değil, şu sorulara cevap vermek için kullanılır:
- Uygulama çalışıyor mu?
- Kullanıcılar hata görüyor mu?
- Kaynak kapasitesi tükeniyor mu?
- Database latency arttı mı?
- VM veya container sağlıklı mı?
- Deployment sonrası error rate değişti mi?
- Network veya dependency problemi var mı?
- Müdahale gerektiren bir olay oluştu mu?
Production monitoring'in değeri veri toplamaktan değil, sinyal → alarm → owner → aksiyon zincirini doğru kurmaktan gelir.
Metrics ile Logs arasındaki fark nedir?
Azure Monitor data platform'unda metrics ve logs farklı amaçlara hizmet eder.
Microsoft'un güncel dokümantasyonuna göre:
Metrics, düzenli aralıklarla toplanan sayısal time-series veridir.
Örnekler:
- CPU utilization
- memory kullanımı
- request count
- latency
- queue depth
- disk IOPS
- network throughput
Metrics hızlı health/performance kontrolü ve alerting için uygundur.
Logs ise event veya kayıt tabanlı daha ayrıntılı veridir.
Örnekler:
- application log
- Windows Event Log
- resource log
- audit log
- authentication event
- query sonucu
- exception detail
Logs genellikle root-cause analysis için daha fazla bağlam sağlar.
Basit ayrım:
| Soru | İlk bakılacak sinyal |
|---|---|
| CPU yükseldi mi? | Metric |
| Response time arttı mı? | Metric |
| Hangi exception oluştu? | Log / trace |
| Hangi kullanıcı işlemi hata verdi? | Log |
| Kaç istek başarısız? | Metric + log |
| Problem hangi dependency'de? | Trace + log |
İyi monitoring tasarımı metrics ve logs arasında seçim yapmak değil, ikisini birbirini tamamlayacak şekilde kullanmaktır.
Log Analytics workspace ne işe yarar?
Azure Monitor Logs verileri Log Analytics workspace içinde toplanabilir ve Kusto Query Language (KQL) ile analiz edilebilir.
Log Analytics workspace şu amaçlarla kullanılabilir:
- Azure resource loglarını toplamak
- VM veya uygulama loglarını merkezi tutmak
- farklı kaynakların olaylarını tek sorguda ilişkilendirmek
- KQL sorguları çalıştırmak
- alert query'leri oluşturmak
- workbook ve dashboard'lara veri sağlamak
- incident investigation yapmak
Örneğin CPU metric'i VM'de problem olduğunu gösterebilir.
Log Analytics ise aynı zaman aralığında:
- application error
- authentication failure
- deployment event
- Windows service event
- dependency error
gibi detayları görmenizi sağlayabilir.
Bu nedenle metrics çoğu zaman problemi tespit eder, logs ise problemi açıklamaya yardımcı olur.
Her resource için her log'u toplamak doğru değildir
Monitoring sistemlerinde sık yapılan hata "ne kadar çok telemetry, o kadar iyi observability" yaklaşımıdır.
Her log'un:
- ingestion maliyeti
- storage/retention maliyeti
- query karmaşıklığı
- operasyonel gürültüsü
vardır.
Özellikle production'da yüksek hacimli debug logları maliyeti büyütebilir ancak incident response sırasında çok az değer sağlayabilir.
Data collection planında her kaynak için şu soruları sorun:
- Bu telemetry hangi riski veya failure mode'u ölçüyor?
- Bunun üzerinden alert oluşturacak mıyız?
- Incident sırasında gerçekten sorgulayacak mıyız?
- Kaç gün retention gerekli?
- Daha düşük hacimli başka bir sinyal aynı ihtiyacı karşılıyor mu?
Observability'nin amacı maksimum veri değil, aksiyona dönüşebilen yeterli veri olmalıdır.
Production ortamında hangi metric'ler izlenmeli?
Tek bir evrensel metric listesi yoktur.
Ancak production workload için dört katmanı ayrı düşünmek faydalıdır.
1. Kullanıcı ve uygulama sinyalleri
- request rate
- response time
- error rate
- availability
- failed transaction
- dependency latency
2. Compute sinyalleri
- CPU
- memory
- disk utilization
- IOPS
- disk latency
- network throughput
3. Platform ve dependency sinyalleri
- database connection
- queue depth
- storage error
- load balancer health
- certificate expiration
- DNS/network dependency
4. Business sinyalleri
- başarılı ödeme
- sipariş akışı
- aktif oturum
- kritik job completion
- veri işleme başarısı
Infrastructure tamamen sağlıklı görünebilir ancak business transaction başarısız olabilir.
Bu nedenle monitoring yalnız CPU/RAM dashboard'u olmamalıdır.
Alert tasarımında threshold tek başına yeterli değildir
Production alert şu bileşenleri birlikte tanımlamalıdır:
- signal
- condition
- severity
- owner
- action group
- notification channel
- escalation
- runbook
- recovery condition
Örneğin:
CPU > %80
tek başına operasyonel olarak zayıf bir alarmdır.
Daha iyi tanım:
Production API VM pool'unda CPU 10 dakika boyunca %85 üzerinde ve request latency aynı dönemde SLO sınırını aşıyorsa P2 incident oluştur; on-call ekibine bildir; scaling/runbook bağlantısını alarm payload'ına ekle.
Her workload bu kadar karmaşık condition gerektirmez.
Ama temel prensip şudur:
Alarm bir insanın ne yapması gerektiğini bilmiyorsa monitoring tamamlanmış değildir.
Azure Monitor Alerts nasıl çalışır?
Azure Monitor Alerts, belirlenen signal ve condition gerçekleştiğinde alert oluşturabilir.
Alert kaynakları arasında:
- metric
- log search
- activity log
- application telemetry
gibi farklı sinyaller bulunabilir.
Action Groups üzerinden:
- SMS
- push
- webhook
- Azure Function
- Logic App
gibi aksiyonlar tetiklenebilir.
Microsoft ayrıca alert processing rules kullanarak belirli durumlarda notification davranışının merkezi yönetilebilmesini sağlar.
Örneğin maintenance window sırasında bilinen alert'leri bastırmak için her alert rule'u tek tek değiştirmek yerine processing rule kullanılabilir.
Alert fatigue nasıl önlenir?
On-call ekibine yüzlerce alarm göndermek observability değildir.
Alert fatigue şu nedenlerle oluşabilir:
- düşük değerli threshold'lar
- aynı olay için birden fazla alarm
- kısa süreli transient spike'lar
- owner'ı olmayan alarm
- recovery notification eksikliği
- bakım pencerelerinde suppress uygulanmaması
- her warning'in incident sayılması
Alert'leri üç gruba ayırmak faydalıdır:
Page-worthy alert
İnsan müdahalesi kısa sürede gerekli.
Ticket-worthy alert
Acil değil ancak planlı aksiyon gerekiyor.
Dashboard-only signal
Trend ve analiz için yararlı ancak notification gerektirmiyor.
Bu ayrım yapılmazsa kritik alarm, gürültü içinde kaybolur.
Severity nasıl belirlenmeli?
Severity teknik metric'in büyüklüğüne değil, iş etkisine göre tanımlanmalıdır.
Örnek yaklaşım:
Sev 0 / Critical: Ana servis tamamen kullanılamıyor veya ciddi veri riski var.
Sev 1 / High: Önemli kullanıcı etkisi veya hızla büyüyen failure var.
Sev 2 / Medium: Servis çalışıyor ancak kapasite/performance problemi müdahale gerektiriyor.
Sev 3 / Low: Operasyonel iyileştirme veya düşük etkili problem.
Azure Monitor içindeki severity değerleriyle şirketinizin incident modelini eşleştirin.
Action Group tasarımı neden önemlidir?
Action Group yalnız email listesi değildir.
İyi tasarımda notification:
- doğru ekibe gider
- environment bilgisini içerir
- resource bilgisini içerir
- runbook linki verir
- dashboard/query linki verir
- escalation kanalını tanımlar
Örneğin database alert'inin:
- platform ekibi
- application ekibi
- finance ekibi
üçüne birden gitmesi çoğu durumda gereksizdir.
Her alert'in tek operasyon sahibi olmalıdır.
SLO ve kullanıcı etkisi monitoring'e nasıl bağlanır?
Infrastructure metric'leri sistemin teknik durumunu gösterir.
SLO ise kullanıcının beklediği servis seviyesini ölçmeye yardımcı olur.
Örnek service indicators:
- availability
- request success rate
- p95 latency
- transaction completion
- job completion time
CPU yükseldiği halde kullanıcı deneyimi etkilenmiyorsa incident priority düşük olabilir.
CPU normal olduğu halde p95 latency ve error rate bozuluyorsa kullanıcı etkisi vardır.
Bu nedenle production monitoring tasarımında:
resource health + application health + user/business health
birlikte ele alınmalıdır.
Azure VM monitoring nasıl tasarlanmalı?
Azure VM için başlangıçta şu alanları değerlendirin:
- CPU
- memory
- disk free space
- disk latency
- IOPS
- network
- OS event logs
- service/process health
- patch state
- backup result
Sadece CPU alarmı yeterli değildir.
Örneğin disk %95 dolduğunda uygulama birkaç saat sonra durabilir. Bu event kullanıcı etkisi oluşmadan önce yakalanabilir.
Azure VM Nedir? rehberinde production VM seçim kriterlerini ayrıca ele alıyoruz.
Application monitoring nasıl yapılmalı?
Uygulama katmanında:
- request
- exception
- trace
- dependency
- response time
- availability
sinyalleri önemlidir.
Distributed uygulamalarda yalnız infrastructure log'una bakmak yeterli olmayabilir.
Bir API isteği:
- web service
- queue
- worker
- database
- external API
zincirinden geçiyorsa trace ve correlation ID root-cause analysis süresini ciddi biçimde azaltabilir.
Amaç "hata var" demek değil, hatanın hangi dependency'de başladığını bulabilmektir.
Azure Monitor maliyeti nasıl kontrol edilir?
Monitoring verisi de cloud kaynağıdır ve maliyet üretir.
Özellikle log ingestion ve retention kontrol edilmelidir.
Maliyeti yönetmek için:
- gereksiz debug loglarını azaltın
- duplicate collection'ı kaldırın
- retention'ı veri ihtiyacına göre ayarlayın
- yüksek hacimli tabloları ayrı değerlendirin
- alert için gerekmeyen verbose telemetry'yi filtreleyin
- data collection rule tasarımını gözden geçirin
Ancak "maliyet düşürmek" için kritik telemetry'yi kapatmak doğru değildir.
Önce verinin operasyon değerini belirleyin, sonra hacmini optimize edin.
Azure maliyet yapısını genel olarak Azure Fiyatlandırma Nasıl Çalışır? rehberinde ele alıyoruz.
Monitoring dashboard'u nasıl tasarlanmalı?
Tek dashboard'a yüzlerce metric koymayın.
Dashboard'u karar seviyesine göre ayırın.
Yönetim / service overview
- availability
- SLO
- incident count
- capacity risk
- cost signal
On-call dashboard
- error rate
- latency
- dependency
- saturation
- recent deployment
- active alert
Resource deep-dive
- CPU
- memory
- disk
- network
- query detail
- logs
Dashboard'un amacı bilgi göstermek değil, soruyu daha hızlı cevaplamaktır.
Monitoring runbook'u ne içermeli?
Kritik alarm için minimum runbook:
- alarm neyi ölçüyor?
- normal değer ne?
- olası nedenler neler?
- ilk kontrol nerede?
- hangi query/dashboard açılmalı?
- hangi değişiklikler yakın zamanda yapıldı?
- safe remediation nedir?
- escalation kimde?
- rollback ne zaman gerekir?
Alarm tanımı ile runbook ayrı dünyalarda tutulursa incident sırasında zaman kaybedilir.
Azure Landing Zone ile monitoring ilişkisi
Landing Zone yalnız subscription ve network mimarisi değildir.
Production governance içinde:
- logging
- monitoring
- policy
- identity
- security
- cost
ortak standartlar olarak tanımlanmalıdır.
Yeni subscription açıldığında monitoring standardının otomatik uygulanması, her ekipten manuel kurulum istemekten daha güvenlidir.
Azure Landing Zone Nedir? rehberinde bu platform yaklaşımını ayrıca ele alıyoruz.
Dynamis'te Azure monitoring nasıl ele alınır?
Dynamis'te monitoring kurulumu dashboard açmakla tamamlanmaz.
Önce workload ve operasyon gereksinimi çıkarılır:
- kritik servisler
- dependency'ler
- SLO
- RPO/RTO
- support window
- escalation
- mevcut incident süreci
Ardından:
- metric seti
- log collection
- workspace yapısı
- alert rule
- action group
- severity
- dashboard
- runbook
tanımlanır.
Amaç daha fazla alarm üretmek değil, incident'i erken görmek ve doğru müdahaleyi hızlandırmaktır.
Azure altyapısının monitoring, operasyon ve günlük yönetimini birlikte değerlendirmek için Azure yönetim hizmetini inceleyebilirsiniz.
Sık yapılan hatalar
Her metric'e alert açmak: Gürültü kritik sinyalleri görünmez hale getirir.
Alarmı owner'sız bırakmak: Notification gelir ancak kimse sorumluluk almaz.
Sadece infrastructure metric izlemek: Uygulama ve kullanıcı etkisi gözden kaçar.
Logs'u sınırsız toplamak: Maliyet artar, signal-to-noise düşer.
Runbook olmadan pager açmak: On-call aynı araştırmayı her incident'ta tekrarlar.
Maintenance window'u hesaba katmamak: Planlı çalışma gereksiz incident üretir.
Dashboard'u monitoring sanmak: Dashboard görünürlük sağlar; operasyon modeli alarm, owner ve aksiyon gerektirir.
Sırada ne var
- Azure Landing Zone Nedir?: monitoring standardını subscription/platform seviyesine bağlayın.
- Azure Well-Architected Framework: reliability ve operational excellence kontrollerini değerlendirin.
- Azure Fiyatlandırma Nasıl Çalışır?: log, monitoring ve diğer Azure maliyetlerini toplam bütçeye dahil edin.
- Azure yönetim hizmeti: monitoring, incident response ve günlük Azure operasyonlarını birlikte değerlendirin.
Kaynaklar
Kaynaklar
- 1.Azure Monitor overviewMicrosoft Learn · 2026-10-12
- 2.Azure Monitor data platformMicrosoft Learn · 2026-10-12
- 3.Best practices for Azure Monitor alertsMicrosoft Learn · 2026-10-12
- 4.Log Analytics workspace overviewMicrosoft Learn · 2026-10-12
- 5.Azure Monitor LogsMicrosoft Learn · 2026-10-12
Sık sorulan sorular
Azure Monitor nedir?
Azure Monitor, Azure ve hibrit ortamlardan metrics, logs, traces ve event telemetry toplayıp analiz etmeye ve bu sinyaller üzerinden aksiyon üretmeye yarayan Microsoft gözlemlenebilirlik servisidir.
Azure Monitor Metrics ile Logs arasındaki fark nedir?
Metrics düzenli aralıklarla toplanan sayısal time-series veridir ve hızlı sağlık/performance takibi ile alerting için uygundur. Logs ise olay ve kayıt tabanlı daha ayrıntılı veridir; root-cause analizi ve KQL sorguları için kullanılır.
Log Analytics workspace ne işe yarar?
Log Analytics workspace, Azure Monitor Logs verisinin toplandığı ve Kusto Query Language ile analiz edildiği veri deposudur. Azure ve Azure dışı kaynaklardan gelen loglar burada merkezi olarak sorgulanabilir.
Azure Monitor alert nasıl tasarlanmalıdır?
Alert yalnız threshold tanımlamak değildir. Sinyal, severity, owner, notification action group, escalation ve runbook birlikte belirlenmelidir. Aynı semptom için gereksiz çok sayıda alarm üretmek alert fatigue yaratır.
Azure Monitor maliyeti nasıl kontrol edilir?
Monitoring maliyeti özellikle log ingestion, retention ve yüksek hacimli telemetry seçimlerinden etkilenebilir. Gereksiz debug logları, uzun retention ve duplicate data collection azaltılmalı; ancak incident response için gerekli telemetry kapatılmamalıdır.