Amazon DOP-C02: Monitoreo, Registro y Observabilidad — Guía de estudio

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

Forma parte de la AWS DevOps Engineer Professional DOP-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Resumen general

El monitoreo, registro y observabilidad en AWS requieren combinar métricas, registros, trazas, eventos y telemetría de estado en señales procesables. Las arquitecturas efectivas utilizan Amazon CloudWatch para métricas, alarmas y dashboards; CloudWatch Logs y Logs Insights para la ingesta y análisis de registros; AWS X-Ray para el rastreo distribuido; AWS CloudTrail para auditoría e integridad; Amazon EventBridge para la detección y automatización basadas en eventos; AWS Health para eventos de servicio específicos de la cuenta; y pipelines centralizados (Kinesis Data Firehose y OpenSearch) para búsqueda y correlación a escala. Los patrones a continuación enfatizan la reducción de ruido, el enrutamiento preciso de señales, la automatización y las operaciones multi-cuenta/multi-región.

Métricas, alarmas, dashboards y alarmas compuestas de CloudWatch

Las métricas de CloudWatch son la base para los SLO, el escalado y las alertas. Publica métricas personalizadas con dimensiones detalladas para aislar señales (por ejemplo, apiOperation, appVersion, statusCode). Usa el formato de métrica embebido de CloudWatch (EMF) con registros estructurados para emitir dimensiones de alta cardinalidad de manera eficiente desde Lambda, contenedores y EC2, evitando la sobrecarga de la API PutMetricData.

Configura alarmas con una evaluación robusta:

Elige períodos alineados con la granularidad de los datos y las ventanas de los SLO.
Establece datapointsToAlarm (m de n) para resiliencia contra el ruido transitorio.
Usa TreatMissingData para evitar falsos positivos durante despliegues o pausas.
Aprovecha las bandas de detección de anomalías cuando las líneas base varían con la estacionalidad, y la matemática de métricas para indicadores derivados (latencia p95, porcentajes de error, ratios de saturación).
Asocia acciones a las alarmas: notificar a través de SNS, crear OpsItems en OpsCenter, ejecutar SSM Automation o recuperar instancias de EC2. Las políticas de escalado pueden hacer referencia a los estados de las alarmas para tomar acción, pero las alarmas compuestas no pueden activar el escalado directamente.

Las alarmas compuestas reducen la fatiga de alarmas al combinar múltiples alarmas subyacentes con lógica AND/OR. Por ejemplo, alertar solo cuando la latencia p95 es alta Y la tasa de errores 5xx excede el umbral Y la saturación de CPU persiste, alineándose así con el impacto al usuario. Las alarmas compuestas aceptan actualizaciones de estado de alarmas secundarias entre regiones/cuentas a través de la observabilidad entre cuentas o flujos de métricas hacia una cuenta central.

Los dashboards visualizan indicadores clave entre servicios. Usa widgets para métricas, resultados de consultas de Logs Insights y el estado de las alarmas (Alarm Status). Estandariza las convenciones de los dashboards (nombres, rangos de tiempo, superposiciones de SLO) y aprovecha las vistas multi-región/multi-cuenta con CloudWatch Observability Access Manager (OAM). Para la correlación ad hoc, fija widgets de Logs Insights y X-Ray ServiceLens uno al lado del otro con widgets de mapas de servicio y tasas de error de Kinesis Firehose.

CloudWatch Logs: Grupos de registros, filtros de métricas, filtros de suscripción y Logs Insights

Estructura los grupos de registros (log groups) por aplicación/componente y etapa del ciclo de vida. Establece políticas de retención explícitas (no confíes en “Nunca expira”) y habilita el cifrado con KMS donde sea necesario. Usa políticas de recursos e IAM detallado para controlar a los productores y suscriptores. Para la ingesta de alto rendimiento, asegura una concurrencia y procesamiento por lotes (batching) adecuados de los flujos de registros (log streams).

Los filtros de métricas (metric filters) convierten patrones de registro en métricas. Define un patrón de filtro con tokens extraídos (JSON o delimitados por espacios) y mapea los tokens a dimensiones de métricas. Esto soporta casos de uso como métricas por API, por versión o por código de respuesta, publicadas directamente desde los registros sin modificar a los productores. Asegúrate de que las unidades y los valores predeterminados sean correctos; prefiere 1 por evento y deriva las tasas mediante matemática de métricas. Usa estas métricas para alertas de SLO y dashboards.

Los filtros de suscripción (subscription filters) transmiten registros casi en tiempo real a:

Kinesis Data Firehose para transformación y entrega a S3/OpenSearch.
Kinesis Data Streams para consumidores personalizados.
Lambda para enrutamiento personalizado, redacción de PII o notificaciones basadas en eventos. Usa un destino de CloudWatch Logs con un rol de IAM para suscripciones entre cuentas. Planifica para reintentos y contrapresión (backpressure); Lambda y Firehose proporcionan reintentos integrados y DLQs/buckets de S3 para errores, respectivamente.

CloudWatch Logs Insights proporciona consultas interactivas y sin servidor sobre los registros. Los operadores principales incluyen fields, filter, parse, stats, sort, limit, dedup y bin para la agrupación por tiempo. Analiza (parse) campos JSON o usa un análisis tipo grok para registros de texto. Ejemplos:

undefined

Guarda las consultas de uso frecuente con QueryDefinition para que el equipo las reutilice, e insértalas en los dashboards como widgets de consulta. Para la automatización, programa una función Lambda a través de EventBridge para ejecutar StartQuery/GetQueryResults y publicar resúmenes en SNS u OpsCenter. Restringe el alcance de la consulta a grupos de registros y ventanas de tiempo específicos para controlar el costo.

AWS X-Ray: Trazado, Reglas de muestreo, Mapas de servicio y Anotaciones

X-Ray captura trazas distribuidas a través de los servicios para encontrar contribuyentes a la latencia y límites de fallos. Instrumente los servicios con AWS Distro for OpenTelemetry (ADOT) o los SDK de X-Ray, propague la cabecera de la traza (p. ej., X-Amzn-Trace-Id) y ejecute el daemon/agente de X-Ray donde sea necesario (ECS/EKS/EC2). Muchos servicios administrados se integran de forma nativa (API Gateway, ALB a través de logs de acceso que actúan como proxy para las trazas, Lambda con trazado activo, Step Functions a través de subsegmentos).

Las reglas de muestreo controlan el volumen de datos y la fidelidad de la señal. Use un conjunto de reglas de muestreo centralizado con:

Un reservorio fijo por segundo para las trazas de referencia por servicio.
Un porcentaje de muestreo basado en una tasa para escalar con el rendimiento.
Prioridad de regla y coincidencia de servicio/URL para rutas críticas y escenarios de error. Aumente el muestreo durante incidentes y para el tráfico canary para proteger la observabilidad mientras gestiona los costos.

Los mapas de servicio visualizan el gráfico de llamadas, mostrando conexiones con latencia, tasas de error e indicadores de throttle. Profundice en las trazas para examinar segmentos y subsegmentos en busca de dependencias posteriores. Use anotaciones (pares clave-valor indexados) para el filtrado de alta cardinalidad, como customerTier, apiOperation, appVersion o ID de solicitud de AWS. Use metadatos para contexto detallado y no indexado para evitar la explosión del índice. Combine los grupos de trazas de X-Ray con CloudWatch ServiceLens para correlacionar logs, métricas y trazas en una vista única. Cree expresiones de filtro (p. ej., annotation.appVersion = “2.3.1” and fault = true) para aislar regresiones y exportar los ID de traza para una búsqueda de logs dirigida.

Gobernanza y Eventos: CloudTrail, EventBridge y AWS Health

CloudTrail registra la actividad de la API para gobernanza y análisis forense. Habilite un trail de organización en todas las cuentas y todas las Regiones, entréguelo a un bucket de S3 centralizado con SSE-KMS, habilite la validación de archivos de log e intégrelo con CloudWatch Logs para una detección casi en tiempo real. Distinga las clases de eventos:

Eventos de gestión: plano de control (p. ej., CreateUser, RunInstances). Configure para incluir solo lectura y solo escritura según sea necesario.
Eventos de datos: operaciones de alto volumen en el plano de datos como el acceso a nivel de objeto en S3, invocaciones de Lambda, API de ítems de DynamoDB, llamadas al servidor API de EKS. Limite el alcance de los eventos de datos selectivamente (por bucket/función/tabla) para controlar los costos. Use CloudTrail Insights para detectar picos inusuales de API y envíe los eventos de CloudTrail a EventBridge para la autorremediación. Valide la integridad de los logs usando archivos digest y el comando de AWS CLI cloudtrail validate-logs durante las auditorías.

EventBridge proporciona una plataforma de eventos para detección y automatización. Use el event bus por defecto para los eventos de servicios de AWS y cree buses personalizados para los eventos del dominio de la aplicación. Defina patrones de eventos que coincidan con el origen, el tipo de detalle, los campos de detalle, los prefijos, los rangos numéricos y “cualquier cosa excepto”. Aplique transformadores de entrada para remodelar los eventos, adjunte políticas basadas en recursos para la publicación entre cuentas y configure reintentos/DLQ en los destinos. Los destinos comunes incluyen Lambda (remediación), Step Functions (orquestación), SQS (desacoplamiento), Systems Manager Automation (acciones de operaciones), CodePipeline (disparadores de CI) y SNS (notificaciones). Archive y reproduzca eventos para recuperarse de interrupciones del consumidor, y use el registro de esquemas para generar modelos de eventos fuertemente tipados.

AWS Health expone eventos de servicio específicos de la cuenta, cambios programados y problemas operativos. Intégrelo a través de EventBridge con el origen aws.health y el tipo de detalle AWS Health Event para enrutar a canales de incidentes, abrir OpsItems en OpsCenter o disparar acciones seguras de apagado/escalado para ventanas de mantenimiento. Use la Vista Organizacional con una cuenta de administrador delegado para agregar eventos de Health de todas las cuentas, y considere la API de AWS Health o la solución AWS Health Aware para enviar notificaciones curadas a los sistemas de guardia.

← Infraestructura como Código y Gestión de la Configuración · Todos los dominios · Seguridad →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →