- 01CloudWatch production monitoring'de metric, log, alarm ve dashboard katmanlarını birlikte sağlar.
- 02EC2 memory ve guest filesystem kullanımı varsayılan metrik değildir; CloudWatch Agent gibi bir agent gerekir.
- 03Alarm'lar yalnız threshold değil, owner, severity ve runbook ile birlikte tasarlanmalıdır.
- 04Log retention ve ingestion CloudWatch maliyetini doğrudan etkiler.
- 05CloudWatch monitoring, incident response ve kapasite kararlarının parçası olarak değerlendirilmelidir.
Kısaca
AWS CloudWatch, AWS kaynakları ve uygulamalar için metrik, log, alarm, dashboard ve observability özellikleri sunan temel monitoring servisidir. Production ortamında yalnız CPU grafiği görmek için değil; servis sağlığını, hata oranını, latency'yi, kapasiteyi ve operasyonel olayları erken yakalamak için kullanılır.
Dynamis Teknoloji'de CloudWatch'u metric + log + alarm + dashboard + incident response zincirinin parçası olarak kurguluyoruz.
AWS CloudWatch nedir?
Amazon CloudWatch, AWS kaynaklarından ve uygulamalardan telemetry toplayıp izlemeye yarayan bir monitoring ve observability servisidir.
CloudWatch ile:
- metric izleyebilirsiniz
- log toplayabilirsiniz
- alarm oluşturabilirsiniz
- dashboard hazırlayabilirsiniz
- metric math kullanabilirsiniz
- Logs Insights ile log sorgulayabilirsiniz
- bazı event ve alarm aksiyonlarını otomatikleştirebilirsiniz
EC2, RDS, ELB, Lambda ve birçok AWS servisi CloudWatch ile entegre çalışır.
Monitoring ile observability aynı şey mi?
Monitoring, belirli metrik ve koşulları izlemeye odaklanır.
Observability ise sistem davranışını anlamak için:
- metric
- log
- trace
- event
gibi sinyalleri birlikte kullanır.
CloudWatch monitoring'in yanında log ve application telemetry özellikleriyle observability katmanına da katkı sağlar.
EC2 için CloudWatch hangi metrikleri sağlar?
EC2'nin varsayılan metrikleri arasında tipik olarak:
- CPUUtilization
- NetworkIn / NetworkOut
- disk read/write operasyonları bazı storage bağlamlarında
- status check metrikleri
bulunur.
Ancak işletim sistemi içindeki memory kullanımı veya filesystem doluluk oranı gibi guest-level metrikler varsayılan EC2 metric setinde yer almaz.
Bunlar için CloudWatch Agent veya başka bir telemetry agent kullanılabilir.
CloudWatch Agent ne zaman gerekir?
CloudWatch Agent özellikle şu veriler için kullanılır:
- memory utilization
- filesystem usage
- swap
- process veya custom metric
- application log
- operating system log
Agent deployment'ı merkezi ve kontrollü yönetilmelidir.
CloudWatch Alarms nasıl çalışır?
CloudWatch alarm, bir metric'i belirli threshold ve evaluation period üzerinden değerlendirir.
Alarm durumları tipik olarak:
- OK
- ALARM
- INSUFFICIENT_DATA
olabilir.
Örnek:
- CPU > %85
- 5 dakika boyunca
- art arda 3 evaluation period
koşulu ile alarm tanımlanabilir.
Ancak production'da yalnız CPU alarmı yeterli değildir.
Hangi alarmlar gerçekten anlamlı?
İyi alarm kullanıcı etkisine veya actionable bir operasyona bağlanmalıdır.
Örnekler:
- application error rate yükseldi
- latency SLO'yu aştı
- target health düştü
- database connection saturation oluştu
- disk doluluğu kritik seviyeye geldi
- backup başarısız oldu
- instance status check failed
Her alarmın bir owner'ı ve runbook'u olmalıdır.
Alarm fatigue nasıl önlenir?
Çok fazla gürültülü alarm operasyon kalitesini düşürür.
Alarm tasarımında:
- gereksiz low-severity threshold'ları azaltın
- duplicate alarm'ları birleştirin
- transient spike ile kalıcı sorunu ayırın
- evaluation period kullanın
- severity tanımlayın
- notification routing yapın
SNS ile bildirim
CloudWatch alarm'ları Amazon SNS üzerinden email veya diğer subscriber modellerine bildirim gönderebilir.
Daha ileri yapılarda alarm akışı:
- ticketing
- incident platform
- chatops
- automation
ile entegre edilebilir.
CloudWatch Logs nedir?
CloudWatch Logs application ve system loglarını merkezi toplamak ve saklamak için kullanılır.
Örnek kaynaklar:
- application log
- nginx / IIS log
- system log
- CloudTrail entegrasyonlu kayıtlar
- Lambda logs
- container logs
Log Group ve Log Stream farkı
Genel yaklaşımda:
- Log Group: aynı retention ve erişim politikasını paylaşan log koleksiyonu
- Log Stream: belirli kaynak veya instance'tan gelen sıralı log akışı
olarak düşünülebilir.
Log retention neden önemli?
Log'ları süresiz tutmak her zaman gerekli değildir.
Retention belirlenirken:
- troubleshooting ihtiyacı
- security gereksinimi
- compliance
- maliyet
birlikte değerlendirilmelidir.
Gereksiz uzun retention CloudWatch Logs maliyetini büyütebilir.
CloudWatch Logs Insights nedir?
Logs Insights, CloudWatch Logs içindeki logları sorgulamak ve analiz etmek için kullanılır.
Örnek kullanım:
- belirli error code'ları bulmak
- en yavaş request'leri görmek
- belli user veya request ID'yi takip etmek
- incident zaman aralığını analiz etmek
Query hacmi ve taranan veri miktarı maliyeti etkileyebilir.
Dashboard ne işe yarar?
CloudWatch Dashboard kritik metric'leri tek görünümde toplar.
Production dashboard için örnek bloklar:
- request rate
- error rate
- latency
- EC2 CPU / memory
- RDS connections
- load balancer target health
- disk / filesystem
- alarms
Dashboard operasyonel karar vermeyi hızlandırmalıdır; sadece görsel kalabalık üretmemelidir.
CloudWatch ile application monitoring
Application-level telemetry eklenmeden yalnız infrastructure metric'leri gerçek kullanıcı problemini kaçırabilir.
Örneğin EC2 CPU normal iken:
- HTTP 500 artabilir
- database timeout oluşabilir
- latency yükselebilir
- queue backlog büyüyebilir
Bu nedenle custom metric veya application log ile business/application sinyalleri eklenmelidir.
CloudWatch ve Auto Scaling ilişkisi
CloudWatch alarm veya metric'leri Auto Scaling policy'lerinde kullanılabilir.
Örneğin:
- CPU
- request count
- custom metric
üzerinden scale-out / scale-in yapılabilir.
Ancak yanlış metric seçimi maliyeti artırabilir veya yetersiz kapasiteye yol açabilir.
CloudWatch maliyeti neden yükselir?
Yaygın maliyet sürücüleri:
- yüksek custom metric sayısı
- detailed monitoring
- yoğun log ingestion
- uzun log retention
- çok sayıda alarm
- yüksek query hacmi
- dashboard kullanımı
- high-cardinality telemetry
Monitoring maliyetini düşürürken visibility kaybı yaratmamak gerekir.
CloudWatch maliyeti nasıl optimize edilir?
Kontrol edin:
- kullanılmayan custom metric'ler
- gereksiz detailed monitoring
- debug log'lar
- retention
- duplicate log ingestion
- alarm sayısı ve kalitesi
- query pattern
AWS Fiyatlandırma Nasıl Çalışır? CloudWatch'u AWS toplam maliyetinin bir parçası olarak ele alır.
Production monitoring checklist
- critical service metrics
- application error rate
- latency
- instance health
- memory / filesystem gerekiyorsa agent
- database health
- load balancer health
- backup status
- actionable alarms
- severity
- owner
- runbook
- retention
- dashboard
CloudWatch tek başına yeterli mi?
Her zaman değil.
CloudWatch AWS-native monitoring için güçlü bir temel sağlar. Ancak şirketin:
- multi-cloud
- on-prem
- farklı observability platformu
- distributed tracing
- özel SLO tooling
ihtiyaçları varsa ek araçlar kullanılabilir.
Önemli olan tek bir tool kullanmak değil, operasyonel görünürlüğü eksiksiz sağlamaktır.
AWS incident response içinde CloudWatch'un rolü
Incident sırasında CloudWatch:
- alarm time line
- metric spike
- log error
- instance health
- application davranışı
üzerinden root cause analizine yardımcı olabilir.
İyi yapılandırılmış monitoring, problemi kullanıcı ticket'ı gelmeden fark etmeyi hedefler.
Dynamis AWS monitoring hizmetinde ne yapar?
Dynamis mevcut AWS hesabınız üzerinde ihtiyaca göre:
- CloudWatch metric tasarımı
- alarm stratejisi
- log collection
- dashboard
- retention
- incident routing
- monitoring maliyeti
- runbook
alanlarını birlikte yönetebilir.
Başka platforma migration zorunlu değildir.
AWS yönetim hizmeti, monitoring'i backup, security, patching, cost ve incident operasyonuyla birlikte ele alır.
Sık yapılan hatalar
Yalnız CPU izlemek: Application error, latency ve dependency metric'lerini ekleyin.
Memory metric'ini EC2'de varsayılan sanmak: Guest-level memory için agent gerekir.
Her spike için alarm kurmak: Evaluation period ve actionable threshold kullanın.
Log retention'ı sınırsız bırakmak: Operasyon ve compliance ihtiyacına göre belirleyin.
Alarm owner'ı tanımlamamak: Bildirim geldiğinde kimin aksiyon alacağı belli olmalı.
Sonuç
AWS CloudWatch production monitoring'in temel taşlarından biridir; ancak gerçek değer yalnız metric toplamaktan değil, doğru alarm, log, dashboard ve incident operasyonunu birlikte tasarlamaktan gelir.
CloudWatch doğru yapılandırıldığında sorunları erken fark etmeyi, root cause analizini hızlandırmayı ve kapasite/maliyet kararlarını daha veriye dayalı hale getirmeyi sağlar.
Sırada ne var
Kaynaklar
Kaynaklar
- 1.What is Amazon CloudWatch?Amazon Web Services · 2026-10-03
- 2.CloudWatch metrics for EC2Amazon Web Services · 2026-10-03
- 3.Installing the CloudWatch agentAmazon Web Services · 2026-10-03
- 4.Using CloudWatch alarmsAmazon Web Services · 2026-10-03
- 5.CloudWatch Logs InsightsAmazon Web Services · 2026-10-03
Sık sorulan sorular
AWS CloudWatch nedir?
Amazon CloudWatch, AWS kaynakları ve uygulamalar için metrik, log, alarm, dashboard ve observability özellikleri sunan monitoring servisidir. EC2, RDS, load balancer ve birçok AWS servisi metriklerini CloudWatch'a gönderir; custom metric ve loglar da eklenebilir.
CloudWatch EC2 memory kullanımını varsayılan olarak gösterir mi?
EC2'nin varsayılan CloudWatch metrikleri CPU, network ve status check gibi host seviyesindeki verileri içerir. Memory ve disk kullanımının işletim sistemi içinden ölçülmesi için CloudWatch Agent veya başka bir telemetry yaklaşımı gerekir.
CloudWatch alarm nasıl çalışır?
CloudWatch alarm, seçilen metric veya metric math/query sonucunu belirli eşik ve değerlendirme periyotları boyunca izler. Durum ALARM olduğunda SNS bildirimi, Auto Scaling aksiyonu veya desteklenen otomasyon aksiyonları tetiklenebilir.
CloudWatch Logs ne için kullanılır?
CloudWatch Logs, uygulama ve sistem loglarını merkezi olarak toplamak, saklamak, aramak ve analiz etmek için kullanılır. Logs Insights ile interaktif sorgular çalıştırılabilir; retention politikaları maliyet ve operasyon ihtiyacına göre ayarlanmalıdır.
CloudWatch maliyeti nasıl kontrol edilir?
Custom metric sayısı, detailed monitoring, log ingestion, log retention, dashboards, alarms ve query hacmi gözden geçirilmelidir. Gereksiz debug logları, sınırsız retention ve yüksek cardinality telemetry maliyeti artırabilir.