Amazon SOA-C02: İzleme, Loglama ve Düzeltme — Çalışma kılavuzu

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Şunun bir parçası: AWS SysOps Administrator Associate SOA-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.

İzleme, loglama ve iyileştirme, AWS ortamlarının operasyonel sinir sistemini oluşturur: sorunları tespit eder, bağlam sunar ve düzeltici eylemleri tetikler. Bu alan; anlamlı metrikler ve panolar oluşturmayı, logları uygun maliyetli bir şekilde toplamayı ve saklamayı, izlenebilir uygulama gözlemlenebilirliği inşa etmeyi ve uyarılar ile iyileştirmeleri otomatikleştirmeyi kapsar. İyi uygulamalar sinyal-gürültü oranını dengeler, maliyetleri kontrol altında tutar ve oyun kitapları (playbook) ile otomasyonların test edilmiş ve denetlenebilir olmasını sağlar.

CloudWatch metrikleri, panoları ve alarmları

Metrikleri, iş ve operasyonel SLI’ler (gecikme, hata oranı, kuyruk derinliği, altyapı için CPU/bellek) etrafında tasarlayın. Yerleşik metrikleri (EC2, RDS, ELB) ve uygulama seviyesi sayaçlar için PutMetricData aracılığıyla özel metrikleri (

undefined

) kullanın. Filtrelemeyi sağlayan boyutları (InstanceId, ServiceName) tercih edin ve metrik maliyetlerini fırlatan yüksek kardinaliteli boyutlardan kaçının.

Metrikleri, logları ve alarmları operasyonel görünümlerde birleştirmek için CloudWatch panolarını kullanın. Konsolda veya CloudFormation (AWS::CloudWatch::Dashboard) aracılığıyla widget’lar oluşturun ve türetilmiş metrikler için metrik matematiğini kullanın: metrik matematiği ile hata oranını hesaplayın (ERRORS/SUM(REQUESTS)) ve yüzdelik dilimleri (p50, p90, p99) görüntüleyin. Alarmlar için, amaca göre yapılandırma desenleri seçin:

Basit eşikler için tek metrikli alarmlar:

undefined

Birden çok alarmdaki koşulları (AND/OR) birleştirerek gürültüyü azaltmak için bileşik alarmlar.
Eşikleri otomatik olarak ayarlamak için anomali tespiti: beklenen mevsimsel davranışa sahip bir metrik üzerinde CloudWatch anomali tespitini kullanın.

Karar kriterleri: alarm kararsızlığını (flapping) önlemek için değerlendirme periyotlarını ve alarm için veri noktası ayarlarını kullanın; alarm eylemleri olarak SNS, Auto Scaling veya Systems Manager Automation’ı tetikleyin. Değişken temel seviyelere sahip ortamlar için bileşik alarmları ve anomali tespitini tercih edin.

CloudWatch Logs, Logs Insights ve saklama

Logları CloudWatch Log grupları ile toplayın ve bunları uygulama ve ortama göre yapılandırın. CLI aracılığıyla log grupları oluşturun:

undefined

ile saklama politikasını zorunlu kılın. Logları Kinesis Data Firehose (S3/Redshift için), Lambda (gerçek zamanlı işleme) veya iş ortağı araçlarına akıtmak için abonelik filtreleri kullanın; depolama maliyetlerini azaltmak için S3’te sıkıştırın ve bölümleyin.

Anlık (ad-hoc) sorgular ve panolar için CloudWatch Logs Insights’ı kullanın; izleme kimliklerini (trace ID) ve hata bağlamlarını çıkaran kayıtlı sorgular oluşturun (örneğin,

undefined

). Saklama ve alım maliyeti kontrolü uygulamaları:

Uyumluluk ve sorun giderme ihtiyaçlarına göre her log grubu için uygun saklama süresini (7/30/90/365 gün) ayarlayın.
Eski logları, saklama yaşam döngüsü veya sıkıştırma ve Glacier/Archive’a yönelik yaşam döngüsü kuralları ile Firehose aracılığıyla S3’e dışa aktarın.
Metrikleri türetmeye devam ederken pahalı, yüksek kardinaliteli logları azaltmak için örnekleme veya yapılandırılmış loglar (JSON) ve Gömülü Metrik Formatı (EMF) kullanın.

Karar kriterleri: ayrıntılı hata ayıklama logları için kısa saklama süresi, denetim/güvenlik logları için daha uzun saklama süresi; yüksek hacimli logları süresiz CloudWatch saklama yerine S3’e yönlendirin.

CloudTrail, denetim izleri ve olay geçmişi

Tüm bölgelerde ve hesaplarda CloudTrail’i etkinleştirin; log dosyası doğrulaması ve SSE-KMS şifrelemesi ile güvenli bir S3 bucket’ına merkezi denetim loglaması için bir kuruluş (organization) izi oluşturun. Yönetim olaylarını (Okuma/Yazma) yapılandırın ve ayrıntılı denetimin gerekli olduğu durumlarda veri olaylarını (S3 nesne seviyesi, Lambda fonksiyonu çağırma) seçici olarak etkinleştirin, çünkü veri olaylarının hacmi ve maliyeti daha yüksektir.

90 günlük hızlı aramalar için konsoldaki CloudTrail olay geçmişini ve uzun vadeli analizler ve araştırmalar için dışa aktarılan S3 logları üzerinde CloudTrail Lake veya Athena’yı kullanın. İzi (trail) şu şekilde koruyun:

Küresel hizmet olaylarını yakalamak için çok bölgeli izleri zorunlu kılın.
Neredeyse gerçek zamanlı tespit için CloudTrail’i CloudWatch Logs ile veya belirli olayları otomatik iyileştirme için Lambda/Systems Manager’a yönlendirmek üzere EventBridge ile entegre edin.
Kurcalamayı önlemek için S3 bucket politikaları ve (gerekirse) S3 Object Lock uygulayın.

Karar kriterleri: veri olaylarını yalnızca adli görünürlüğün gerekli olduğu bucket’lar/fonksiyonlar için etkinleştirin; uyumluluğu basitleştirmek için merkezi izleri ve hesaplar arası erişim desenlerini kullanın.

Uygulama izleme ve gözlemlenebilirlik (X-Ray)

Segment ve alt segmentler yaymak için uygulamaları AWS X-Ray SDK’ları ile enstrümante edin. Enstrümante edilmemiş çalışma zamanları için, X-Ray daemon/agent’ını bir sidecar veya hizmet olarak (ECS görevi, EC2 daemon’u veya Lambda yerleşik izlemesi) çalıştırın. İzleme (trace) hacmini kontrol etmek için örnekleme kuralları yapılandırın ve hizmetler arası bağımlılıkları görselleştirmek için ServiceLens’te hizmet haritaları ayarlayın. Sorun çözümüne yardımcı olmak için izleri iş anahtarlarıyla (userId, orderId) ek açıklamalarla zenginleştirin ve istisnaları/meta verileri kaydedin.

CloudWatch Logs Insights sorgularının logları ve izleri birleştirebilmesi için uygulama loglarına X-Ray izleme kimliğini (trace ID) ekleyerek izleri loglarla ilişkilendirin (mevcut izleme kimliğini almak için izleme başlığını veya SDK’yı kullanın). Lambda için, izleri otomatik olarak X-Ray’e göndermek üzere aktif izlemeyi (Konsol veya

undefined

) etkinleştirin. Kuyruk gecikmelerini, sıcak noktaları (hotspot) ve veritabanı çağrı dökümlerini tespit etmek için izleme analitiğini kullanın.

Karar kriterleri: kritik hizmetler için izlemeyi etkinleştirin ve maliyeti sınırlamak için uyarlanabilir örnekleme kullanın; Loglar+İzler korelasyonunu deterministik hale getirmek için yapılandırılmış izleri (ek açıklamalar/meta veriler) tercih edin.

Otomatik düzeltme ve uyarı (EventBridge/Lambda)

CloudWatch Alarm durumu değişikliklerini, CloudTrail olaylarını veya özel olayları eşleştirmek ve bunları Lambda, Systems Manager Automation belgeleri, Step Functions veya SNS gibi hedeflere yönlendirmek için EventBridge kurallarını kullanın. Düzeltme eylemine minimum bağlamı iletmek için girdi dönüştürücüler (input transformers) ile kurallar oluşturun (aws events put-rule –name HighErrorRule –event-pattern ‘{“source”:[“aws.cloudwatch”],…}’). Hafif düzeltmeler (bir servisi yeniden başlatma, kimlik bilgilerini iptal etme) için Lambda fonksiyonları uygulayın, ancak denetlenebilir ve kontrol noktaları (checkpoints) olan uzun süren playbook’lar için SSM Automation veya Step Functions kullanın.

Düzeltmeleri güvenlik önlemleriyle tasarlayın: dry-run modları, idempotency, doğrulama adımları, IAM en az ayrıcalık (least-privilege) ilkesi, loglama ve bir kill-switch ekleyin. EventBridge/Lambda entegrasyonlarında dead-letter queue’ları ve yeniden deneme politikalarını kullanın ve düzeltme denemelerini bir denetim günlüğüne (audit log) veya güvenlik izine (security trail) yayınlayın. Otomasyonları bir hazırlık (staging) hesabında test edin ve dağıtımdan sonra canary testleri çalıştırın.

Karar kriterleri: çok adımlı kurtarma işlemleri ve insan onayı için SSM Automation veya Step Functions’ı tercih edin; basit, hızlı düzeltmeler için Lambda kullanın. Riskli eylemler için her zaman manuel bir geri alma (rollback) veya döngüye insan dahil etme (human-in-the-loop) kesme noktası ekleyin.

Yaygın Hatalar ve Karar Kriterleri

Sağlık kararları için tek bir metriğe güvenmek: yanlış pozitifleri (false positives) önlemek için metrikleri birleştirin (ör. hata oranı + gecikme + kısıtlamalar) veya composite alarm’ları/metric math’i kullanın.
Log saklama (retention) ve alım (ingestion) maliyetlerini hesaba katmamak: her log grubu için saklama süresi belirleyin, toplu logları sıkıştırma ile Firehose üzerinden S3’e yönlendirin ve eski verileri daha ucuz katmanlara taşımak için yaşam döngüsü (lifecycle) politikalarını kullanın.
Yüksek kardinaliteli (high-cardinality) boyutlarla veya izleme örneklemesi (trace sampling) devre dışı bırakılarak aşırı enstrümantasyon yapmak: sinyali korurken maliyeti kontrol etmek için boyutları sınırlayın ve uyarlanabilir örneklemeyi (adaptive sampling) etkinleştirin.
Otomatik düzeltmeyi test etmeden dağıtmak: prodüksiyonda etkinleştirmeden önce hazırlık (staging) ortamında doğrulayın, dry-run bayraklarını kullanın ve idempotency ile güvenli geri alma (rollback) işlemlerini sağlayın.
Gürültülü alarmlardan kaynaklanan uyarı yorgunluğu: anomali tespiti, composite alarm’lar, bastırma pencereleri (suppression windows) kullanın ve yalnızca anlamlı olayları nöbetçi ekibe (on-call) iletin.
Loglar, metrikler ve izler (traces) arasında korelasyon eksikliği: trace ID’lerini loglara ve EMF metriklerine yayın ve verileri bir araya getirmek için kaydedilmiş Logs Insights sorguları ve ServiceLens görünümleri oluşturun.

Pratik Problem: Kullanım Senaryosu

Acme Payments, yoğun trafik sırasında aralıklı ödeme işleme hataları yaşıyor; mühendisler artan gecikme ve düzensiz 5xx hataları görüyor, ancak otomatik yeniden başlatmalar bazen kök nedeni maskelemiş.

Ödeme servisini X-Ray SDK ve EMF metrikleri ile enstrümante edin; uygulama loglarına trace ID’leri ekleyin ve OrdersFailed ile OrdersProcessed yapılandırılmış metriklerini PutMetricData/EMF aracılığıyla gönderin.
Hata oranını (OrdersFailed / OrdersProcessed) hesaplamak için CloudWatch metric math oluşturun ve hata oranı > eşik DEĞERİ VE p99 gecikme > eşik DEĞERİ koşullarını birleştiren bir composite alarm yaratın.
Alarm eylemlerini, teşhis adımları (son izleri/logları toplama, sağlık kontrollerini çalıştırma) için bir Step Functions iş akışını tetikleyen ve güvenliyse SSM Automation aracılığıyla otomatik bir yeniden başlatma başlatan bir EventBridge kuralına yönlendirin.
Tam logları S3’e (sıkıştırılmış olarak) arşivlemek için CloudTrail ve CloudWatch Logs aboneliğini Glacier’e yaşam döngüsü (lifecycle) ile yapılandırın ve ayrıntılı hata ayıklama (debug) logları için CloudWatch’ta kısa bir saklama süresi ayarlayın.
Prodüksiyonda otomatik düzeltmeyi etkinleştirmeden önce gözlemlenebilirlik ve düzeltme akışını doğrulamak için uçtan uca testler ve canary sentetik işlemler (CloudWatch Synthetics) çalıştırın.

Gerekçe: semptomları tekrar tekrar tedavi etmek yerine kök nedeni bulmak için metrikleri, logları ve izleri (traces) birbiriyle ilişkilendirin; gürültüyü azaltmak için alarmları birleştirin ve log depolama maliyetlerini kontrol altında tutarken güvenli düzeltme için denetlenebilir, test edilmiş otomasyon (Step Functions/SSM) kullanın.

Tüm alanlar · Yüksek Erişilebilirlik →

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