Amazon DVA-C02: İzleme, Günlükleme ve Hata Ayıklama (CloudWatch, X-Ray, Tracing, Alarmlar) — Çalışma kılavuzu

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Şunun bir parçası: AWS Developer Associate DVA-C02 — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Amazon sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

CloudWatch Logs, Metrikler ve Log Metrik Filtreleri

CloudWatch Logs, uygulama ve platform telemetrisi için birincil kanaldır; geliştiriciler, Metrics ve Insights’ın logları güvenilir bir şekilde ayrıştırabilmesi için logları yapılandırılmış (JSON) olarak tasarlamalıdır. Özel uygulama metrikleri için, anında boyutlar (dimensions) ve yüksek çözünürlük ihtiyaçları için CloudWatch Embedded Metric Format (EMF) veya PutMetricData’yı tercih edin; EMF, log satırlarına _aws JSON’u gömer ve CloudWatch’un tek bir PutLogEvents çağrısında birçok metriği çıkarmasına olanak tanıyarak maliyet ve iş hacmi verimliliği sağlar. Servis tarafında metinsel loglardan metrikler türetmeniz gerektiğinde, bir log grubuna karşı filtre desenlerini MetricTransformations’a eşleyen metrik filtreleri (PutMetricFilter) oluşturun; bunlar, grafiği çizilebilen ve alarm oluşturulabilen CloudWatch metrikleri üretir. Yaygın operasyonel API’ler CreateLogGroup, CreateLogStream ve PutLogEvents (sequenceToken ve PutLogEvents yığın boyutu limitlerine dikkat edin) ve bekleme durumunda şifreleme için bir log grubuna müşteri tarafından yönetilen bir KMS anahtarı eklemek için AssociateKmsKey’dir. IAM’e dikkat edin: PutLogEvents ve PutMetricData açık izinler gerektirir ve KMS izinleri, hizmet sorumlusunun (service principal) anahtarları şifreleme için kullanmasına izin vermelidir. Maliyetleri kontrol etmek için saklama politikaları kullanın ve yalnızca dakika altı görünürlüğe ihtiyacınız olduğunda yüksek çözünürlüklü metrikleri (StorageResolution=1 ile PutMetricData) tercih edin.

Dağıtık Sistemler için İzleme ve X-Ray

Dağıtık izleme (Distributed tracing), gecikme ve hataların nerede meydana geldiğini ortaya çıkarmak için servisler arasındaki istek akışlarını izler; AWS X-Ray bu konuda entegre seçenektir. Lambda fonksiyonlarında Aktif izlemeyi (Lambda TracingConfig Mode: Active) etkinleştirin ve X-Ray izleme başlığını (trace header) yaymak için API Gateway aşamaları için X-Ray’i etkinleştirin. Alt segmentler (subsegments) oluşturmak, ek açıklamalar (annotations - indekslenmiş, küçük değerli) ve meta veriler (metadata - indekslenmemiş, daha büyük nesneler) eklemek için çalışma zamanınızda (runtime) AWS X-Ray SDK’sını (Node için aws-xray-sdk-core, Python için aws_xray_sdk, Java için AWSXRayRecorder) kullanın. SDK’nın S3, DynamoDB ve HTTP çağrılarına yönelik istekleri otomatik olarak izlemesi (auto-instrument) için AWS SDK istemcilerini X-Ray kaydedici (recorder) ile sarmalayarak aşağı akış (downstream) SDK çağrılarını yakalayın. Konteynerleştirilmiş iş yükleri için X-Ray daemon’ını bir sidecar olarak çalıştırın veya daemon katmanını kullanın; bu, UDP paketlerini (varsayılan port 2000) kabul eder ve bunları X-Ray servisine toplu olarak gönderir. Gürültüyü önlemek için örnekleme kuralları (CreateSamplingRule) yapılandırın, ancak her zaman izlemek istediğiniz kritik akışlar için kuralları ayarlayın veya SDK geçersiz kılma (override) özelliğini kullanın. Segment doküman boyutu limitlerine dikkat edin ve indekslenip aranabildikleri için ek açıklamalara (annotations) asla kişisel olarak tanımlanabilir bilgileri (PII) koymayın.

Alarmlar, Bildirimler ve Uyarı Tasarımı

Alarmlar, eylem alınabilir olayları tespit etmeli, gürültüyü azaltmalı ve runbook’lar ile entegre olmalıdır. CloudWatch Alarmlarını yerel (native) metrikler, özel metrikler (PutMetricData veya metrik filtrelerinden gelen) veya metrik matematik ifadeleri (metric math expressions) üzerinde kullanın; kararsızlığı (flapping) önlemek için DatapointsToAlarm ve EvaluationPeriods ayarlarını yapın ve uyarı hacmini azaltmak için çoklu sinyal koşulları (örneğin, aşağı akışın bozulması + artan hata oranı) için bileşik alarmları (composite alarms) tercih edin. Alarm eylemleri, insan/otomasyon iş akışları için SNS konularına (topic) yayın yapabilir, Auto Scaling’i veya Systems Manager OpsCenter’ı (OpsItems oluşturarak) tetikleyebilir veya karmaşık playbook’lar için EventBridge kuralları (kaynak: aws.cloudwatch) üzerinden yönlendirebilir. Hızlı nöbet (on-call) ihtiyaçları için SNS -> HTTP uç noktası veya PagerDuty entegrasyonu kullanın; otomatik düzeltme için en az ayrıcalıklı IAM ile EventBridge -> Step Functions veya Lambda kullanın. Trafiğin temel davranışını belirlemek (baselining) için anomali tespit modellerini değerlendirin ve histerezis ile OK eşikleri belirleyin. Yaygın tuzaklar arasında çok fazla boyutlu alarm oluşturmak (izleme maliyetlerinde patlama), yalnızca tek veri noktası tetikleyicilerine güvenmek ve uyarıların istenmeyen tüketicilere sızmaması için bildirim konularını (SNS erişim politikaları) güvence altına almamak yer alır.

Sorun Giderme Desenleri ve SDK/API Uygulamaları

Sorun gidermeye, beklenen ve gözlemlenen zaman çizelgesini karşılaştırarak başlayın ve ardından logları, metrikleri ve izleri (trace) birbiriyle ilişkilendirin. Ani artışları bulmak için anlık sorgularla (fields @timestamp, @message | parse … | stats count() by bin(1m)) CloudWatch Logs Insights’ı kullanın ve ardından ayrıntılı gecikme süreleri için X‑Ray izlerine geçiş yapın. Lambda destekli API’ler için cold-start’ları, (VPC içindeki fonksiyonlar için) VPC ENI eklenme sürelerini ve başarısız asenkron çağrıları yakalamak için Lambda hedeflerinin (destination) veya DLQ’ların yapılandırılıp yapılandırılmadığını kontrol edin. Başarısız çağrıları yakalamak için, payload’ları korumak amacıyla Lambda Destinations (onFailure ile SNS, SQS veya EventBridge’e) veya bir asenkron DLQ kullanın. Kodu enstrümante ederken, jitter ile üstel geri çekilme (exponential backoff) uygulayarak ve metrik filtreleri veya EMF sayaçları aracılığıyla 429 hatalarını izleyerek API kısıtlamalarını (throttle) yönetin. Sık karşılaşılan tuzaklar: PutLogEvents doğru sequence token’ı gerektirir ve öncesinde CreateLogStream çağrılmalıdır; PutMetricData kısıtlanabilir—metrikleri toplu halde işleyin ve birleştirilmiş (aggregate) olarak yayınlayın; X‑Ray, xray:PutTraceSegments ve xray:PutTelemetryRecords izinlerini gerektirir (yönetilen ilke AWSXRayDaemonWriteAccess); ve örnekleme (sampling), düşük frekanslı ancak kritik akışlar için kuralları ayarlamazsanız sorunları gizleyebilir.

Pratik Problem: Kullanım Senaryosu

Senaryo: Acme Retail, AWS üzerinde API Gateway -> Lambda -> DynamoDB mimarisini kullanarak sunucusuz bir ödeme hizmeti işletmektedir. Ekip, merkezi CloudWatch Logs ve X-Ray kullanıyor ancak dakika başına cihaz işlem hacmi (throughput) metriklerinden yoksun ve gürültülü alarmlar oluşturmadan API gecikmesindeki ani artışlar için güvenilir uyarılara ihtiyaç duyuyor.

Zorluk: Dakika başına neredeyse gerçek zamanlı cihaz/mesaj sayılarını yakalamak, yavaş istekler için uçtan uca izlemeyi sağlamak ve otomatik bir düzeltme Lambda’sını tetikleyip nöbetçi ekibi bilgilendiren düşük gürültülü bir alarm oluşturmak.

Önerilen Yaklaşım:

Ödeme (checkout) Lambda’sını, Namespace=Acme/Checkout, MetricName=DeviceReportsPerMinute, Timestamp=now, Value=1 ve StorageResolution=1 parametreleriyle PutMetricData API’sini kullanarak özel bir yüksek çözünürlüklü metrik yayınlayacak şekilde enstrümante edin; API kısıtlamasından kaçınmak için bunları bellekte toplu olarak işleyin ve her 30 saniyede bir gönderin.
Ayrıca, daha zengin boyutlar (customerId, region) için Lambda loglarına EMF JSON gömün ve hata sayıları için PutLogEvents ve metrik filtreleri (PutMetricFilter) aracılığıyla ek metrikler çıkarmak için CloudWatch Logs’a güvenin.
X-Ray izlemeyi etkinleştirin: Lambda TracingConfig Modunu Active olarak ayarlayın, API Gateway stage’inde X-Ray’i etkinleştirin ve üçüncü taraf API’lere yapılan harici HTTP çağrılarının etrafına ek açıklamalar (annotation) (PII olmayan) ve alt segmentler (subsegment) eklemek için X-Ray SDK’sını kullanın.
Yüksek bir 95. yüzdelik dilim gecikme metriğini (metrik matematiği) DeviceReportsPerMinute metriğindeki bir artışla birleştiren bir bileşik (composite) CloudWatch Alarmı oluşturun; EvaluationPeriods=3, DatapointsToAlarm=2 olarak ayarlayın, Action olarak nöbetçi uç noktasını tetikleyen bir SNS konusunu ve bir düzeltme Lambda’sını (en az ayrıcalıklı rol ile) çağıran bir EventBridge kuralını belirtin.

Gerekçe: Yüksek çözünürlüklü metrikler ve EMF yayınlamak, hem anlık dakika başına sayımlar hem de daha zengin boyutsallık sağlar; X‑Ray, alt sistem (downstream) çağrılarına kadar inen gecikme kök neden analizini sunar; bileşik alarmlar, uyarı vermeden önce birbiriyle ilişkili koşullar gerektirerek gürültüyü azaltır ve EventBridge aracılığıyla otomasyona olanak tanır.

← Güvenlik · Tüm alanlar · Depolama →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →