Amazon DOP-C02: Monitoraggio, Logging e Osservabilità — Guida allo studio

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

Fa parte della AWS DevOps Engineer Professional DOP-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Il monitoraggio, la registrazione (logging) e l’osservabilità su AWS richiedono di combinare metriche, log, tracce, eventi e telemetria sullo stato di salute (health) in segnali utilizzabili (actionable). Le architetture efficaci utilizzano Amazon CloudWatch per metriche, allarmi e dashboard; CloudWatch Logs e Logs Insights per l’ingestion e l’analisi dei log; AWS X-Ray per il tracciamento distribuito; AWS CloudTrail per l’auditing e l’integrità; Amazon EventBridge per il rilevamento e l’automazione basati su eventi; AWS Health per eventi di servizio specifici dell’account; e pipeline centralizzate (Kinesis Data Firehose e OpenSearch) per la ricerca e la correlazione su larga scala. I pattern descritti di seguito enfatizzano la riduzione del rumore, l’instradamento preciso dei segnali, l’automazione e le operazioni multi-account/multi-regione.

Metriche, Allarmi, Dashboard e Allarmi Compositi di CloudWatch

Le metriche di CloudWatch sono il fondamento per SLO, scalabilità e alerting. Pubblicare metriche personalizzate con dimensioni a grana fine per isolare i segnali (ad esempio, apiOperation, appVersion, statusCode). Utilizzare il CloudWatch Embedded Metric Format (EMF) con log strutturati per emettere in modo efficiente dimensioni ad alta cardinalità da Lambda, container ed EC2, evitando l’overhead dell’API PutMetricData.

Configurare gli allarmi con una valutazione robusta:

Scegliere periodi allineati alla granularità dei dati e alle finestre SLO.
Impostare datapointsToAlarm (m su n) per la resilienza al rumore transitorio.
Usare TreatMissingData per evitare falsi positivi durante i deployment o le pause.
Sfruttare le bande di rilevamento delle anomalie (anomaly detection) quando le baseline variano con la stagionalità, e la metric math per indicatori derivati (latenza p95, percentuali di errore, rapporti di saturazione).
Associare azioni agli allarmi: notificare tramite SNS, creare OpsItem in OpsCenter, eseguire SSM Automation o ripristinare istanze EC2. Le policy di scalabilità possono fare riferimento allo stato degli allarmi per intraprendere un’azione, ma gli allarmi compositi non possono attivare direttamente la scalabilità.

Gli allarmi compositi (Composite alarms) riducono l’affaticamento da allarmi (alarm fatigue) combinando più allarmi sottostanti con logica AND/OR. Ad esempio, attivare un allarme solo quando la latenza p95 è alta E il tasso di errori 5xx supera la soglia E la saturazione della CPU persiste, allineandosi così all’impatto sull’utente. Gli allarmi compositi accettano aggiornamenti di stato dagli allarmi figli (child alarms) tra regioni/account tramite l’osservabilità cross-account o gli stream di metriche verso un account centrale.

Le dashboard visualizzano gli indicatori chiave tra i vari servizi. Utilizzare widget per metriche, risultati di query di Logs Insights e stato degli allarmi (Alarm Status). Standardizzare le convenzioni delle dashboard (naming, intervalli di tempo, overlay SLO) e sfruttare le viste cross-region/cross-account con CloudWatch Observability Access Manager (OAM). Per la correlazione ad hoc, affiancare i widget di Logs Insights e X-Ray ServiceLens a quelli della mappa dei servizi (service map) e ai tassi di errore di Kinesis Firehose.

CloudWatch Logs: Gruppi di Log, Filtri di Metrica, Filtri di Sottoscrizione e Logs Insights

Strutturare i gruppi di log (log group) per applicazione/componente e fase del ciclo di vita. Impostare policy di conservazione (retention) esplicite (non fare affidamento su “Never Expire”) e abilitare la crittografia KMS dove richiesto. Utilizzare resource policy e IAM a grana fine per controllare producer e subscriber. Per l’ingestion ad alto throughput, assicurare un’adeguata concorrenza e batching dei log stream.

I filtri di metrica (Metric filters) trasformano i pattern dei log in metriche. Definire un filter pattern con token estratti (JSON o delimitati da spazi) e mappare i token alle dimensioni della metrica. Questo supporta casi d’uso come metriche per-API, per-versione, per-codice-di-risposta pubblicate direttamente dai log senza modificare i producer. Assicurarsi che le unità e i valori predefiniti siano corretti; preferire 1 per evento e derivare i tassi tramite metric math. Utilizzare queste metriche per l’alerting SLO e le dashboard.

I filtri di sottoscrizione (Subscription filters) inviano in streaming i log quasi in tempo reale a:

Kinesis Data Firehose per la trasformazione e la consegna a S3/OpenSearch.
Kinesis Data Streams per consumer personalizzati.
Lambda per routing personalizzato, redazione di PII o notifiche basate su eventi. Utilizzare una destinazione di CloudWatch Logs con un ruolo IAM per le sottoscrizioni cross-account. Pianificare i tentativi (retry) e la contropressione (backpressure); Lambda e Firehose forniscono rispettivamente tentativi integrati e DLQ/bucket S3 per gli errori.

CloudWatch Logs Insights fornisce un’interfaccia di query interattiva e serverless sui log. Gli operatori principali includono fields, filter, parse, stats, sort, limit, dedup e bin per il raggruppamento temporale (time bucketing). Eseguire il parsing di campi JSON o utilizzare un parsing simile a grok per i log di testo. Esempi:

undefined

Salvare le query usate di frequente con QueryDefinition per il riutilizzo da parte del team e incorporarle nelle dashboard come widget di query. Per l’automazione, pianificare una Lambda tramite EventBridge per eseguire StartQuery/GetQueryResults e pubblicare i riepiloghi su SNS o OpsCenter. Limitare l’ambito della query a specifici gruppi di log e finestre temporali per controllare i costi.

AWS X-Ray: Tracciamento, Regole di Campionamento, Mappe dei Servizi e Annotazioni

X-Ray acquisisce tracce distribuite tra i servizi per individuare i responsabili della latenza e i confini dei guasti. Strumentare i servizi con AWS Distro for OpenTelemetry (ADOT) o con gli SDK di X-Ray, propagare l’header di traccia (es. X-Amzn-Trace-Id) ed eseguire il demone/agente X-Ray dove necessario (ECS/EKS/EC2). Molti servizi gestiti si integrano nativamente (API Gateway, ALB tramite i log di accesso che inoltrano le tracce, Lambda con il tracciamento attivo, Step Functions tramite sottosegmenti).

Le regole di campionamento controllano il volume dei dati e la fedeltà del segnale. Utilizzare un set di regole di campionamento centralizzato con:

Un serbatoio fisso al secondo per le tracce di base per ogni servizio.
Una percentuale di campionamento basata sulla frequenza per scalare con il throughput.
Priorità delle regole e corrispondenza per servizio/URL per i percorsi critici e gli scenari di errore. Aumentare il campionamento durante gli incidenti e per il traffico canary per garantire l’osservabilità gestendo al contempo i costi.

Le mappe dei servizi visualizzano il grafo delle chiamate, mostrando archi con latenza, tassi di errore e indicatori di throttling. Analizzare in dettaglio le tracce per esaminare segmenti e sottosegmenti alla ricerca di dipendenze a valle. Usare le annotazioni (coppie chiave-valore indicizzate) per il filtraggio ad alta cardinalità, come customerTier, apiOperation, appVersion o ID di richiesta AWS. Usare i metadati per un contesto verboso e non indicizzato per evitare un’esplosione dell’indice. Combinare i gruppi di tracce di X-Ray con CloudWatch ServiceLens per correlare log, metriche e tracce in un’unica vista. Creare espressioni di filtro (es. annotation.appVersion = “2.3.1” and fault = true) per isolare le regressioni ed esportare gli ID delle tracce per una ricerca mirata nei log.

Governance ed Eventi: CloudTrail, EventBridge e AWS Health

CloudTrail registra l’attività delle API per la governance e l’analisi forense. Abilitare un trail a livello di organizzazione su tutti gli account e in tutte le Regioni, inviarlo a un bucket S3 centralizzato con SSE-KMS, abilitare la validazione dei file di log e integrarlo con CloudWatch Logs per il rilevamento quasi in tempo reale. Distinguere le classi di eventi:

Eventi di gestione: control plane (es. CreateUser, RunInstances). Configurare per includere eventi di sola lettura e di sola scrittura secondo necessità.
Eventi di dati: operazioni ad alto volume sul data plane come l’accesso a livello di oggetto S3, Lambda Invoke, API per item di DynamoDB, chiamate al server API di EKS. Limitare selettivamente l’ambito degli eventi di dati (per bucket/funzione/tabella) per controllare i costi. Usare CloudTrail Insights per rilevare picchi anomali di chiamate API e inviare gli eventi CloudTrail a EventBridge per l’autoriparazione. Validare l’integrità dei log usando i file di digest e il comando della AWS CLI cloudtrail validate-logs durante gli audit.

EventBridge fornisce un “event fabric” (tessuto di eventi) per il rilevamento e l’automazione. Usare il bus di eventi predefinito per gli eventi dei servizi AWS e creare bus personalizzati per gli eventi del dominio applicativo. Definire pattern di eventi che corrispondano a source, detail-type, campi di detail, prefissi, intervalli numerici e “anything-but”. Applicare trasformatori di input per rimodellare gli eventi, associare policy basate su risorse per la pubblicazione cross-account e configurare retry/DLQ sulle destinazioni. Le destinazioni comuni includono Lambda (riparazione), Step Functions (orchestrazione), SQS (disaccoppiamento), Systems Manager Automation (azioni operative), CodePipeline (trigger di CI) e SNS (notifiche). Archiviare e rieseguire gli eventi per ripristinare il servizio dopo interruzioni dei consumer e usare il registro degli schemi per generare modelli di eventi fortemente tipizzati.

AWS Health espone eventi di servizio specifici dell’account, modifiche pianificate e problemi operativi. Integrarlo tramite EventBridge con source aws.health e detail-type AWS Health Event per instradare gli eventi verso i canali di gestione degli incidenti, aprire OpsItems in OpsCenter o attivare azioni di spegnimento o scalabilità sicuri per le finestre di manutenzione. Usare la Organizational View con un account amministratore delegato per aggregare gli eventi Health di tutti gli account e considerare l’uso dell’API di AWS Health o della soluzione AWS Health Aware per inviare notifiche mirate ai sistemi di reperibilità.

Log centralizzati con Kinesis Data Firehose e OpenSearch

Una strategia di logging multi-account e multi-regione standardizza l’ingestione e la ricerca. In ogni account producer, configurare i filtri di sottoscrizione di CloudWatch Logs verso una destinazione Logs cross-account supportata da un Kinesis Data Firehose centrale. Abilitare le funzionalità di Firehose:

Trasformazione dei dati tramite Lambda per la normalizzazione (JSON), l’oscuramento delle PII (Personally Identifiable Information) e l’arricchimento con metadati relativi ad account AWS, regione, VPC e servizio.
Compressione (GZIP) e partizionamento dinamico durante la consegna a S3 per ottimizzare le prestazioni delle query in Athena.
Crittografia con KMS e consegna tramite VPC per endpoint privati. Consegnare ad Amazon OpenSearch Service per la ricerca a bassa latenza e la visualizzazione tramite dashboard Kibana/OpenSearch. Utilizzare template di indice, policy ILM/ISM per il rollover e la retention, e policy di accesso granulari (fine-grained) che associano gli utenti a pattern di indice (es. account/team/servizio). Configurare l’output degli errori su S3 per i documenti non riusciti e monitorare le metriche di consegna di Firehose e di ingestione di OpenSearch (DeliveryToElasticsearch.Success, ElasticsearchFailedRequests). Per volumi molto elevati, considerare di far atterrare tutti i log in S3 tramite Firehose e di inviare in streaming solo un sottoinsieme a OpenSearch, utilizzando query Athena on-demand su S3 per indagini a coda lunga (long-tail) al fine di controllare i costi.

Combinare questa pipeline con i filtri di metrica di CloudWatch per contatori veloci e a basso costo e con Logs Insights per query approfondite ad hoc. Utilizzare le regole di EventBridge, attivate da anomalie di Firehose/OpenSearch o da allarmi di CloudWatch, per avviare azioni di remediation o per generare incident.

Scenario pratico

Airbnb riscontra picchi intermittenti di errori API e latenza sui microservizi distribuiti su EKS e Lambda, con più versioni dell’app mobile in uso. Il team Operations necessita di un rilevamento quasi in tempo reale per operazione API, codice di risposta e versione dell’app; di un’analisi rapida della causa radice (root cause analysis) attraverso trace e log; di una remediation automatizzata per pattern di errore noti; e di audit trail di livello governance.

Standardizzare il logging strutturato

Implementare log JSON strutturati secondo il formato EMF nei servizi (EKS, Lambda), includendo campi per apiOperation, statusCode, appVersion, tenantId e latencyMs.
Perché: Il formato EMF consente l’estrazione diretta di metriche in CloudWatch con un basso overhead e dimensioni ad alta cardinalità per allarmi precisi.

Creare filtri di metrica in CloudWatch Logs

Per ogni gruppo di log di servizio, definire filtri di metrica che incrementino i contatori per apiOperation, statusCode e appVersion.
Perché: Produce metriche per dimensione senza percorsi di codice aggiuntivi, abilitando dashboard e allarmi azionabili per ogni API e versione del client.

Costruire allarmi CloudWatch a più livelli e un allarme composito

Impostare allarmi sulla latenza p95, sul tasso di errori 5xx e sulla saturazione (CPU, memoria, concorrenza/throttle). Creare un allarme composito: LatencyHigh AND ErrorsHigh per 2 periodi consecutivi su 3.
Perché: Riduce il rumore di fondo e si concentra sugli incidenti che hanno un impatto reale sull’utente.

Implementare il tracing X-Ray con campionamento mirato

Utilizzare i collector ADOT su EKS e il tracing attivo per Lambda. Definire regole di campionamento per catturare tutti i trace di errore e un campione rappresentativo delle chiamate andate a buon fine, con un campionamento più elevato per le nuove versioni dell’app.
Perché: Garantisce visibilità sui fallimenti e una copertura sufficiente per individuare i performance hotspot, mantenendo i costi sotto controllo.

Correlare con ServiceLens e Logs Insights

Creare dashboard che combinino widget di metriche, la mappa dei servizi di X-Ray e query di Logs Insights (es.

undefined

Perché: La correlazione in un unico pannello (single-pane) accelera la diagnosi di quale operazione e versione del client ha subito una regressione.

Centralizzare i log tramite Firehose verso OpenSearch e S3

Configurare filtri di sottoscrizione verso un Firehose centrale con una trasformazione Lambda per normalizzare, oscurare le PII e arricchire con i dati di account/regione. Consegnare a OpenSearch per la ricerca ‘hot’ a 7 giorni e a S3 per la retention durevole e le query con Athena.
Perché: Ricerca rapida e cross-team sui problemi attuali, con analisi storica a basso costo.

Automatizzare il rilevamento e la remediation con EventBridge

Creare regole EventBridge per le variazioni di stato degli allarmi CloudWatch e per eventi API di scrittura selezionati di CloudTrail (es. modifiche ai security group). Target: Lambda per rollback sicuri (es. ripristino di feature flag) e Step Functions per remediation multi-step.
Perché: I cicli di controllo event-driven (guidati dagli eventi) riducono il MTTR (Mean Time To Repair) e applicano i guardrail di sicurezza.

Integrare AWS Health e la gestione della manutenzione

Aggiungere regole EventBridge per gli eventi aws.health che interessano EC2, EKS o il networking. Target: SSM Automation per isolare/svuotare (cordon/drain) i nodi o per deviare il traffico.
Perché: La mitigazione proattiva di problemi pianificati o operativi riduce i tempi di inattività (downtime).

Rafforzare la governance con un trail CloudTrail a livello di organizzazione e l’integrità dei log

Abilitare un trail multi-regione a livello di organizzazione con eventi dati per S3 e Lambda, crittografia SSE-KMS e validazione dell’integrità dei file di log. Inviare in streaming a CloudWatch Logs e OpenSearch per l’individuazione di anomalie e per le indagini.
Perché: Un audit completo e a prova di manomissione (tamper-evident) soddisfa i requisiti di conformità e accelera la RCA (Root Cause Analysis).

Notifiche e integrazione con le Operations

Inoltrare gli eventi critici a SNS e ai sistemi di reperibilità (on-call), aprire OpsItem in OpsCenter con runbook allegati e associare tag agli allarmi per definirne la proprietà e la gravità.
Perché: Una chiara attribuzione di responsabilità (ownership) e runbook automatizzati migliorano la qualità e la velocità della risposta.

Questo design è stato scelto per combinare metriche a bassa latenza e ricche di dimensioni (CloudWatch + EMF), correlazione approfondita dei trace (X-Ray + ServiceLens), ricerca su larga scala (OpenSearch + S3/Athena), remediation event-driven (EventBridge + Lambda/SSM/Step Functions) e governance verificabile (CloudTrail con integrità). Bilancia costi e fedeltà dei dati attraverso il campionamento, livelli di retention differenziati e allarmi mirati che riflettono l’impatto reale sull’utente.

← Infrastruttura come Codice e Gestione della Configurazione · Tutti i domini · Sicurezza →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →