Amazon DOP-C02: İzleme, Günlükleme ve Gözlemlenebilirlik — Çalışma kılavuzu

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Şunun bir parçası: AWS DevOps Engineer Professional DOP-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.

Genel Bakış

AWS’te izleme, günlük kaydı ve gözlemlenebilirlik; metrikleri, günlükleri, izleri, olayları ve sağlık telemetrisini eyleme dönüştürülebilir sinyaller halinde birleştirmeyi gerektirir. Etkili mimariler; metrikler, alarmlar ve panolar için Amazon CloudWatch’ı; günlük alımı ve analizi için CloudWatch Logs ve Logs Insights’ı; dağıtık izleme için AWS X-Ray’i; denetim ve bütünlük için AWS CloudTrail’i; olay güdümlü tespit ve otomasyon için Amazon EventBridge’i; hesaba özgü hizmet olayları için AWS Health’i; ve büyük ölçekte arama ve korelasyon için merkezi işlem hatlarını (Kinesis Data Firehose ve OpenSearch) kullanır. Aşağıdaki desenler gürültünün azaltılmasını, hassas sinyal yönlendirmesini, otomasyonu ve çoklu hesap/çoklu Bölge operasyonlarını vurgular.

CloudWatch Metrikleri, Alarmları, Panoları ve Bileşik Alarmlar

CloudWatch metrikleri; SLO’lar, ölçeklendirme ve uyarılar için temel oluşturur. Sinyalleri izole etmek için (örneğin, apiOperation, appVersion, statusCode) ayrıntılı boyutlara sahip özel metrikler yayınlayın. Lambda, container’lar ve EC2’den yüksek kardinaliteli boyutları verimli bir şekilde yaymak ve PutMetricData API’sinin ek yükünden kaçınmak için yapılandırılmış günlüklerle birlikte CloudWatch Gömülü Metrik Formatını (EMF) kullanın.

Alarmları sağlam bir değerlendirme ile yapılandırın:

Veri granüleritesi ve SLO pencereleriyle uyumlu periyotlar seçin.
Geçici gürültüye karşı dayanıklılık için datapointsToAlarm’ı (n’de m) ayarlayın.
Dağıtım veya duraklamalar sırasında yanlış pozitifleri önlemek için TreatMissingData kullanın.
Temel çizgiler mevsimselliğe göre değiştiğinde anomali tespit bantlarından ve türetilmiş göstergeler (p95 gecikmesi, hata yüzdeleri, doygunluk oranları) için metrik matematiğinden yararlanın.
Alarmlara eylemler ekleyin: SNS aracılığıyla bildirim gönderin, OpsCenter OpsItems oluşturun, SSM Automation çalıştırın veya EC2 örneklerini kurtarın. Ölçeklendirme politikaları eylem için alarm durumlarına başvurabilir, ancak bileşik alarmlar ölçeklendirmeyi doğrudan tetikleyemez.

Bileşik alarmlar, birden çok temel alarmı AND/OR mantığıyla birleştirerek alarm yorgunluğunu azaltır. Örneğin, yalnızca p95 gecikmesi yüksek olduğunda VE 5xx oranı eşiği aştığında VE CPU doygunluğu devam ettiğinde uyarı vererek kullanıcı etkisine göre hizalanın. Bileşik alarmlar, hesaplar arası gözlemlenebilirlik veya merkezi bir hesaba metrik akışları aracılığıyla Bölgeler/hesaplar genelindeki alt alarmlardan durum güncellemelerini kabul eder.

Panolar, hizmetler genelindeki temel göstergeleri görselleştirir. Metrikler, Logs Insights sorgu sonuçları ve Alarm Durumu için widget’lar kullanın. Pano kurallarını (adlandırma, zaman aralıkları, SLO katmanları) standartlaştırın ve CloudWatch Observability Access Manager (OAM) ile Bölgeler arası/hesaplar arası görünümlerden yararlanın. Anlık korelasyon için, Logs Insights ve X-Ray ServiceLens widget’larını hizmet haritası widget’ları ve Kinesis Firehose hata oranları ile yan yana sabitleyin.

CloudWatch Logs: Günlük Grupları, Metrik Filtreleri, Abonelik Filtreleri ve Logs Insights

Günlük gruplarını uygulama/bileşen ve yaşam döngüsü aşamasına göre yapılandırın. Açık saklama politikaları belirleyin (“Never Expire” seçeneğine güvenmeyin) ve gerektiğinde KMS şifrelemesini etkinleştirin. Üreticileri ve aboneleri kontrol etmek için kaynak politikalarını ve ayrıntılı IAM’i kullanın. Yüksek verimli alım için yeterli günlük akışı eşzamanlılığını ve toplu işlemeyi sağlayın.

Metrik filtreleri, günlük desenlerini metriklere dönüştürür. Çıkarılan belirteçlerle (JSON veya boşlukla ayrılmış) bir filtre deseni tanımlayın ve belirteçleri metrik boyutlarına eşleyin. Bu, üreticileri değiştirmeden doğrudan günlüklerden yayınlanan API başına, sürüm başına, yanıt kodu başına metrikler gibi kullanım senaryolarını destekler. Birimlerin ve varsayılan değerlerin doğru olduğundan emin olun; olay başına 1’i tercih edin ve oranları metrik matematiği aracılığıyla türetin. Bu metrikleri SLO uyarısı ve panolar için kullanın.

Abonelik filtreleri, günlükleri neredeyse gerçek zamanlı olarak şuraya akıtır:

Dönüşüm ve S3/OpenSearch’e teslimat için Kinesis Data Firehose.
Özel tüketiciler için Kinesis Data Streams.
Özel yönlendirme, PII (Kişisel Tanımlanabilir Bilgi) redaksiyonu veya olay güdümlü bildirimler için Lambda. Hesaplar arası abonelikler için bir IAM rolü ile bir CloudWatch Logs hedefi kullanın. Yeniden deneme ve geri basınç için plan yapın; Lambda ve Firehose sırasıyla yerleşik yeniden denemeler ve DLQ’lar/hata S3 bucket’ları sağlar.

CloudWatch Logs Insights, günlükler üzerinde etkileşimli, sunucusuz sorgulama sağlar. Temel operatörler arasında zaman gruplaması için fields, filter, parse, stats, sort, limit, dedup ve bin bulunur. JSON alanlarını ayrıştırın veya metin günlükleri için grok benzeri ayrıştırma kullanın. Örnekler:

undefined

Sık kullanılan sorguları ekibin yeniden kullanımı için QueryDefinition ile kaydedin ve bunları sorgu widget’ları olarak panolara gömün. Otomasyon için, StartQuery/GetQueryResults’ı çalıştırmak ve özetleri SNS veya OpsCenter’da yayınlamak üzere EventBridge aracılığıyla bir Lambda zamanlayın. Maliyeti kontrol etmek için sorgu kapsamını belirli günlük grupları ve zaman pencereleriyle kısıtlayın.

AWS X-Ray: İzleme, Örnekleme Kuralları, Servis Haritaları ve Ek Açıklamalar

X-Ray, gecikmeye neden olan etkenleri ve hata sınırlarını bulmak için servisler arasındaki dağıtık izleri (trace) yakalar. Servisleri AWS Distro for OpenTelemetry (ADOT) veya X-Ray SDK’ları ile enstrümante edin, izleme başlığını (ör. X-Amzn-Trace-Id) yayın ve gerektiğinde (ECS/EKS/EC2) X-Ray daemon/agent’ını çalıştırın. Birçok yönetilen servis yerel olarak entegre olur (API Gateway, erişim logları aracılığıyla izleri proxy’leyen ALB, aktif izlemeli Lambda, alt segmentler aracılığıyla Step Functions).

Örnekleme kuralları, veri hacmini ve sinyal doğruluğunu kontrol eder. Aşağıdakileri içeren merkezi bir örnekleme kuralı seti kullanın:

Her servis için temel izlemeler için saniye başına sabit bir rezervuar.
Verimle (throughput) ölçeklenmek için orana dayalı örnekleme yüzdesi.
Sık kullanılan yollar (hot path) ve hata senaryoları için kural önceliği ve servis/URL eşleştirmesi. Maliyeti yönetirken gözlemlenebilirliği korumak için olaylar sırasında ve canary trafiği için örneklemeyi artırın.

Servis haritaları, çağrı grafiğini görselleştirerek gecikme, hata oranları ve kısıtlama (throttle) göstergeleriyle kenarları (edge) gösterir. Alt bağımlılıklar için segmentleri ve alt segmentleri incelemek üzere izlerin (trace) derinine inin. customerTier, apiOperation, appVersion veya AWS istek kimlikleri gibi yüksek kardinaliteye sahip filtreleme için ek açıklamaları (indekslenmiş anahtar-değer çiftleri) kullanın. İndeks şişmesini önlemek için ayrıntılı, indekslenmemiş bağlam için meta verileri kullanın. Logları, metrikleri ve izleri tek bir görünümde ilişkilendirmek için X-Ray izleme gruplarını CloudWatch ServiceLens ile birleştirin. Regresyonları izole etmek ve hedeflenmiş log araması için izleme kimliklerini dışa aktarmak amacıyla filtre ifadeleri (ör. annotation.appVersion = “2.3.1” and fault = true) oluşturun.

Yönetişim ve Olaylar: CloudTrail, EventBridge ve AWS Health

CloudTrail, yönetişim ve adli analiz için API etkinliğini kaydeder. Tüm hesaplar ve tüm Bölgeler (Region) genelinde bir kuruluş izi (organization trail) etkinleştirin, SSE-KMS ile merkezi bir S3 bucket’ına teslim edin, log dosyası doğrulamasını etkinleştirin ve neredeyse gerçek zamanlı tespit için CloudWatch Logs ile entegre edin. Olay sınıflarını ayırt edin:

Yönetim olayları (Management events): kontrol düzlemi (control plane) (ör. CreateUser, RunInstances). Gerektiğinde salt okunur ve salt yazılır olayları içerecek şekilde yapılandırın.
Veri olayları (Data events): S3 nesne düzeyinde erişim, Lambda Invoke, DynamoDB öğe API’leri, EKS API sunucusu çağrıları gibi yüksek hacimli veri düzlemi (data plane) işlemleri. Maliyeti kontrol etmek için veri olaylarını seçici olarak (bucket/fonksiyon/tabloya göre) kapsama alın. Anormal API artışlarını tespit etmek için CloudTrail Insights’ı kullanın ve otomatik iyileştirme için CloudTrail olaylarını EventBridge’e yönlendirin. Denetimler sırasında özet dosyalarını (digest file) ve AWS CLI cloudtrail validate-logs komutunu kullanarak log bütünlüğünü doğrulayın.

EventBridge, tespit ve otomasyon için bir olay altyapısı (event fabric) sağlar. AWS servis olayları için varsayılan olay yolunu (event bus) kullanın ve uygulamaya özgü alan (domain) olayları için özel yollar oluşturun. source, detail-type, detail alanları, önekler, sayısal aralıklar ve “anything-but” (hariç her şey) ile eşleşen olay desenleri (event pattern) tanımlayın. Olayları yeniden şekillendirmek için girdi dönüştürücüleri (input transformer) uygulayın, hesaplar arası yayınlama için kaynak tabanlı politikalar ekleyin ve hedefler üzerinde yeniden deneme/DLQ yapılandırın. Yaygın hedefler arasında Lambda (iyileştirme), Step Functions (orkestrasyon), SQS (ayrıştırma/decoupling), Systems Manager Automation (operasyon eylemleri), CodePipeline (CI tetikleyicileri) ve SNS (bildirimler) bulunur. Tüketici (consumer) kesintilerinden kurtulmak için olayları arşivleyin ve yeniden oynatın (replay) ve güçlü tipli (strongly typed) olay modelleri oluşturmak için şema kaydını (schema registry) kullanın.

AWS Health, hesaba özgü servis olaylarını, planlanmış değişiklikleri ve operasyonel sorunları yüzeye çıkarır. Olay kanallarına yönlendirmek, OpsCenter OpsItems açmak veya bakım pencereleri için güvenli kapatma/ölçekleme eylemlerini tetiklemek amacıyla, source aws.health ve detail-type AWS Health Event ile EventBridge üzerinden entegre edin. Tüm hesaplardaki Health olaylarını birleştirmek için yetkilendirilmiş bir yönetici hesabıyla Organizasyonel Görünümü (Organizational View) kullanın ve nöbetçi (on-call) sistemlerine özel olarak hazırlanmış bildirimleri göndermek için AWS Health API’sini veya AWS Health Aware çözümünü değerlendirin.

Kinesis Data Firehose ve OpenSearch ile Merkezi Loglama

Çoklu hesap ve çoklu Bölge (multi-Region) loglama stratejisi, veri alımını (ingestion) ve aramayı standartlaştırır. Her bir üretici (producer) hesapta, CloudWatch Logs abonelik filtrelerini, merkezi bir Kinesis Data Firehose tarafından desteklenen, hesaplar arası (cross-account) bir Logs hedefine yönlendirecek şekilde yapılandırın. Firehose özelliklerini etkinleştirin:

Normalleştirme (JSON), PII (Kişisel Tanımlanabilir Bilgiler) redaksiyonu ve AWS hesap, Bölge, VPC ve hizmet üst verileriyle zenginleştirme için Lambda aracılığıyla veri dönüşümü.
Athena’daki sorgu performansını optimize etmek için S3’e teslimat sırasında sıkıştırma (GZIP) ve dinamik bölümleme (dynamic partitioning).
Özel uç noktalar (private endpoints) için KMS ile şifreleme ve VPC üzerinden teslimat. Düşük gecikmeli arama ve Kibana/OpenSearch Dashboards görselleştirmesi için Amazon OpenSearch Service’e teslim edin. Dizin şablonları (index templates), devir (rollover) ve saklama (retention) için ILM/ISM politikaları ve kullanıcıları dizin desenleriyle (ör. hesap/takım/hizmet) eşleştiren ayrıntılı erişim politikaları (fine-grained access policies) kullanın. Başarısız belgeler için hata çıktısını S3’e yönlendirecek şekilde yapılandırın ve Firehose teslimat ile OpenSearch veri alım metriklerini (DeliveryToElasticsearch.Success, ElasticsearchFailedRequests) izleyin. Çok yüksek hacimler için, tüm logları Firehose aracılığıyla S3’e indirmeyi ve maliyeti kontrol altında tutmak amacıyla uzun soluklu (long-tail) araştırmalar için S3 üzerinde isteğe bağlı Athena sorguları ile birlikte, OpenSearch’e yalnızca bir alt kümesini akıtmayı (stream) düşünün.

Hızlı, düşük maliyetli sayaçlar için bu işlem hattını (pipeline) CloudWatch metrik filtreleriyle ve anlık (ad hoc) derinlemesine sorgular için Logs Insights ile birleştirin. Düzeltme (remediation) eylemlerini başlatmak veya olay (incident) kaydı oluşturmak için Firehose/OpenSearch anomalileri veya CloudWatch alarmları tarafından tetiklenen EventBridge kurallarını kullanın.

Pratik Problem Senaryosu

Airbnb, EKS ve Lambda üzerinde dağıtılmış mikroservislerde, piyasada birden fazla mobil uygulama sürümü varken, API hatalarında ve gecikmede aralıklı ani artışlar yaşıyor. Operasyon ekibinin API operasyonu, yanıt kodu ve uygulama sürümüne göre neredeyse gerçek zamanlı tespit yapmaya; izler (traces) ve loglar arasında hızlı kök neden analizine; bilinen hata kalıpları için otomatik düzeltmeye ve yönetişim düzeyinde denetim izlerine (audit trails) ihtiyacı var.

Yapılandırılmış loglamayı standartlaştırın

Servislerde (EKS, Lambda) apiOperation, statusCode, appVersion, tenantId ve latencyMs gibi alanları içeren EMF yapısında JSON logları uygulayın.
Neden: EMF, hassas alarmlar için düşük ek yük (overhead) ve yüksek kardinaliteli (high-cardinality) boyutlarla CloudWatch’ta doğrudan metrik çıkarımını sağlar.

CloudWatch Logs metrik filtreleri oluşturun

Her hizmet log grubu için apiOperation, statusCode ve appVersion’a göre sayaçları artıran metrik filtreleri tanımlayın.
Neden: Ekstra kod yolları olmadan boyut başına metrikler üreterek, her API ve istemci sürümü için panolar (dashboards) ve eyleme geçirilebilir alarmlar sağlar.

Katmanlı CloudWatch alarmları ve bir bileşik alarm (composite alarm) oluşturun

p95 gecikmesi, 5xx oranı ve doygunluk (CPU, bellek, eşzamanlılık/kısıtlama) üzerine alarm kurun. Bir bileşik alarm oluşturun: Ardışık 3 periyodun 2’sinde LatencyHigh AND ErrorsHigh.
Neden: Gürültüyü azaltır ve kullanıcıyı etkileyen olaylara odaklanır.

Hedefli örnekleme (sampling) ile X-Ray izlemeyi (tracing) dağıtın

EKS üzerinde ADOT toplayıcılarını (collectors) ve Lambda için aktif izlemeyi kullanın. Tüm hata izlerini ve başarılı çağrıların temsili bir örneğini yakalamak için örnekleme kuralları tanımlayın, yeni uygulama sürümlerinde daha yüksek örnekleme yapın.
Neden: Maliyeti kontrol altında tutarken, hatalara karşı görünürlüğü ve performans darboğazları için yeterli kapsamayı garanti eder.

ServiceLens ve Logs Insights ile korelasyon kurun

Metrik widget’larını, X-Ray hizmet haritasını ve Logs Insights sorgularını (ör.

undefined

) birleştiren panolar oluşturun.

Neden: Tek bir ekranda (single-pane) korelasyon, hangi operasyonun ve istemci sürümünün gerilediğinin teşhisini hızlandırır.

Logları Firehose aracılığıyla OpenSearch ve S3’te merkezileştirin

Normalleştirmek, PII’ı redakte etmek ve hesap/Bölge bilgileriyle zenginleştirmek için Lambda dönüşümü içeren merkezi bir Firehose’a abonelik filtreleri yapılandırın. 7 günlük sıcak (hot) arama için OpenSearch’e ve dayanıklı saklama ile Athena sorguları için S3’e teslim edin.
Neden: Düşük maliyetli geçmiş analizi ile güncel sorunlar üzerinde hızlı, ekipler arası arama imkanı sağlar.

EventBridge ile tespiti ve düzeltmeyi otomatikleştirin

CloudWatch alarm durumu değişiklikleri ve seçili CloudTrail yazma API olayları (ör. güvenlik grubu değişiklikleri) için EventBridge kuralları oluşturun. Hedefler: Güvenli geri alma işlemleri (ör. özellik bayraklarını geri çevirme) için Lambda ve çok adımlı düzeltme için Step Functions.
Neden: Olay güdümlü (event-driven) kontrol döngüleri, MTTR’ı (Ortalama Onarım Süresi) kısaltır ve koruma mekanizmalarını (guardrails) uygular.

AWS Health ve bakım yönetimi entegrasyonu yapın

EC2, EKS veya ağı etkileyen aws.health olayları için EventBridge kuralları ekleyin. Düğümleri (nodes) kordona almak/boşaltmak (cordon/drain) veya trafiği kaydırmak için SSM Automation’ı hedefleyin.
Neden: Planlanmış veya operasyonel sorunların proaktif olarak azaltılması, kesinti süresini (downtime) azaltır.

CloudTrail organizasyon izi (org trail) ve bütünlüğü ile yönetişimi güçlendirin

S3 ve Lambda için veri olayları (data events), SSE-KMS şifrelemesi ve log dosyası doğrulaması içeren bir organizasyon çapında, çoklu Bölge izi (trail) etkinleştirin. Anomali tespiti ve araştırmalar için CloudWatch Logs ve OpenSearch’e akıtın.
Neden: Tam, kurcalamaya karşı korumalı (tamper-evident) denetim, uyumluluk gereksinimlerini karşılar ve RCA’yı (Kök Neden Analizi) hızlandırır.

Bildirimler ve Ops entegrasyonu

Kritik olayları SNS’e ve nöbetçi (on-call) sistemlere yönlendirin, ekli runbook’lar ile OpsCenter’da OpsItems açın ve sahiplik ile önem derecesi için alarm etiketleri ekleyin.
Neden: Net sahiplik ve otomatikleştirilmiş runbook’lar, müdahale kalitesini ve hızını artırır.

Bu tasarım; düşük gecikmeli, boyut açısından zengin metrikleri (CloudWatch + EMF), derinlemesine iz (trace) korelasyonunu (X-Ray + ServiceLens), ölçekte aramayı (OpenSearch + S3/Athena), olay güdümlü düzeltmeyi (EventBridge + Lambda/SSM/Step Functions) ve denetlenebilir yönetişimi (bütünlüğe sahip CloudTrail) birleştirmek için seçilmiştir. Örnekleme, saklama katmanları (retention tiers) ve gerçek kullanıcı etkisini yansıtan hedeflenmiş alarmlar ile maliyet ve doğruluğu (fidelity) dengeler.

← Kod Olarak Altyapı ve Yapılandırma Yönetimi · Tüm alanlar · Güvenlik →

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