Amazon DVA-C02: Monitoreo, registro y depuración (CloudWatch, X-Ray, Rastreo, Alarmas) — Guía de estudio

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

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

CloudWatch Logs, Métricas y Filtros de Métricas de Logs

CloudWatch Logs es el canal principal para la telemetría de aplicaciones y plataformas; los desarrolladores deben diseñar los logs para que sean estructurados (JSON) de modo que Metrics e Insights puedan analizarlos de forma fiable. Para métricas de aplicación personalizadas, prefiere CloudWatch Embedded Metric Format (EMF) o PutMetricData para necesidades de dimensiones inmediatas y alta resolución; EMF incrusta JSON de _aws en las líneas de log y permite a CloudWatch extraer muchas métricas en una sola llamada a PutLogEvents para una mayor eficiencia en costos y rendimiento. Cuando necesites derivar métricas a partir de logs textuales en el lado del servicio, crea filtros de métricas (PutMetricFilter) contra un grupo de logs que mapeen patrones de filtro a MetricTransformations; estos producen métricas de CloudWatch que se pueden graficar y sobre las que se pueden crear alarmas. Las API operativas comunes son CreateLogGroup, CreateLogStream y PutLogEvents (presta atención al sequenceToken y a los límites de tamaño de lote de PutLogEvents), y AssociateKmsKey para asociar una clave KMS administrada por el cliente a un grupo de logs para el cifrado en reposo. Vigila IAM: PutLogEvents y PutMetricData requieren permisos explícitos, y las concesiones de KMS deben permitir que el principal del servicio use las claves para el cifrado. Usa políticas de retención para controlar los costos y prefiere métricas de alta resolución (PutMetricData con StorageResolution=1) solo cuando necesites visibilidad por debajo del minuto.

Trazado y X-Ray para Sistemas Distribuidos

El trazado distribuido instrumenta los flujos de solicitudes a través de los servicios para revelar dónde ocurren la latencia y los errores; AWS X-Ray es la opción integrada. Habilita el trazado Activo en las funciones Lambda (Lambda TracingConfig Mode: Active) y habilita X-Ray para las etapas de API Gateway para propagar la cabecera de traza de X-Ray. Usa el SDK de AWS X-Ray en tu entorno de ejecución (aws-xray-sdk-core para Node, aws_xray_sdk para Python, AWSXRayRecorder para Java) para crear subsegmentos, añadir anotaciones (indexadas, valores pequeños) y metadatos (no indexados, objetos más grandes). Captura las llamadas a SDK posteriores (downstream) envolviendo los clientes del SDK de AWS con el grabador de X-Ray para que el SDK instrumente automáticamente las solicitudes a S3, DynamoDB y las llamadas HTTP. Para cargas de trabajo en contenedores, ejecuta el daemon de X-Ray como un sidecar o usa la capa del daemon; este acepta paquetes UDP (puerto 2000 por defecto) y los agrupa en lotes para enviarlos al servicio de X-Ray. Configura reglas de muestreo (CreateSamplingRule) para evitar el ruido, pero ajusta las reglas o usa la anulación del SDK para flujos críticos que siempre quieras trazar. Ten en cuenta los límites de tamaño del documento de segmento y nunca pongas PII en las anotaciones porque están indexadas y se pueden buscar.

Diseño de Alarmas, Notificaciones y Alertas

Las alarmas deben detectar eventos accionables, reducir el ruido e integrarse con los runbooks. Usa alarmas de CloudWatch sobre métricas nativas, métricas personalizadas (de PutMetricData o filtros de métricas) o expresiones de métricas matemáticas; ajusta DatapointsToAlarm y EvaluationPeriods para evitar el “flapping” y prefiere alarmas compuestas para condiciones de múltiples señales (downstream roto + tasa de errores aumentada) para reducir el volumen de alertas. Las acciones de alarma pueden publicar en temas de SNS para flujos de trabajo humanos o de automatización, invocar Auto Scaling o Systems Manager OpsCenter (crear OpsItems), o enrutar a través de reglas de EventBridge para playbooks complejos (source: aws.cloudwatch). Para necesidades rápidas de guardias (on-call), usa SNS -> endpoint HTTP o la integración con PagerDuty; para la remediación automatizada, usa EventBridge -> Step Functions o Lambda con el mínimo privilegio de IAM. Considera los modelos de detección de anomalías para establecer líneas base de tráfico y define umbrales de OK con histéresis. Las trampas comunes incluyen crear demasiadas alarmas dimensionadas (explosión de los costos de monitoreo), depender únicamente de disparadores de un solo punto de datos y no asegurar los temas de notificación (políticas de acceso de SNS) para que las alertas no se filtren a consumidores no deseados.

Patrones de Solución de Problemas y Prácticas de SDK/API

Comience la solución de problemas enmarcando un cronograma de lo esperado vs. lo observado y luego correlacione logs, métricas y trazas. Use CloudWatch Logs Insights para consultas ad-hoc (fields @timestamp, @message | parse … | stats count() by bin(1m)) para encontrar picos y luego pasar a las trazas de X‑Ray para obtener latencias detalladas. Para las API respaldadas por Lambda, verifique los arranques en frío (cold starts), los tiempos de asociación de ENI de VPC (para funciones en una VPC) y si los destinos de Lambda o las DLQ están configurados para capturar invocaciones asíncronas fallidas. Para capturar invocaciones fallidas, use Lambda Destinations (onFailure a SNS, SQS o EventBridge) o una DLQ asíncrona para preservar las cargas útiles (payloads). Al instrumentar el código, gestione la limitación (throttling) de la API implementando un retroceso exponencial con fluctuación (jitter) y monitorizando los errores 429 mediante filtros de métricas o contadores EMF. Errores comunes: PutLogEvents requiere primero el token de secuencia correcto y CreateLogStream; PutMetricData puede ser limitado (throttled)—agrupe y emita métricas agregadas; X‑Ray requiere los permisos xray:PutTraceSegments y xray:PutTelemetryRecords (política gestionada AWSXRayDaemonWriteAccess); y el muestreo puede ocultar problemas a menos que ajuste las reglas para flujos de baja frecuencia pero críticos.

Problema Práctico: Escenario de Caso de Uso

Escenario: Acme Retail opera un servicio de pago sin servidor en AWS usando API Gateway -> Lambda -> DynamoDB. El equipo utiliza CloudWatch Logs y X‑Ray de forma centralizada, pero carece de métricas de rendimiento de dispositivos por minuto y necesita alertas fiables sobre picos en la latencia de la API sin crear alertas ruidosas.

Desafío: Capturar recuentos de dispositivos/mensajes por minuto casi en tiempo real, asegurar la trazabilidad de extremo a extremo para solicitudes lentas y crear una alarma de bajo ruido que active una Lambda de remediación automatizada y notifique al personal de guardia.

Enfoque Recomendado:

Instrumentar la Lambda de pago para emitir una métrica personalizada de alta resolución usando la API PutMetricData con Namespace=Acme/Checkout, MetricName=DeviceReportsPerMinute, Timestamp=now, Value=1 y StorageResolution=1; agruparlas en memoria y vaciarlas (flush) cada 30 segundos para evitar la limitación (throttling) de la API.
Incrustar también JSON de EMF en los logs de Lambda para obtener dimensiones más ricas (customerId, region) y depender de CloudWatch Logs para extraer métricas adicionales a través de PutLogEvents y filtros de métricas (PutMetricFilter) para los recuentos de errores.
Habilitar el rastreo de X‑Ray: establecer el TracingConfig Mode de Lambda en Active, habilitar X‑Ray en la etapa (stage) de API Gateway y usar el SDK de X‑Ray para añadir anotaciones (sin PII) y subsegmentos alrededor de las llamadas HTTP externas a API de terceros.
Crear una alarma compuesta de CloudWatch que combine una métrica de latencia alta del percentil 95 (usando metric math) con un pico en DeviceReportsPerMinute; establecer EvaluationPeriods=3, DatapointsToAlarm=2, y una acción a un tema de SNS que active un endpoint del personal de guardia más una regla de EventBridge que invoque una Lambda de remediación (con un rol de privilegios mínimos).

Justificación: Emitir métricas de alta resolución y EMF proporciona tanto recuentos inmediatos por minuto como una dimensionalidad más rica; X‑Ray proporciona la causa raíz de la latencia hasta las llamadas a servicios posteriores (downstream); las alarmas compuestas reducen el ruido al requerir condiciones correlacionadas antes de alertar y permiten la automatización a través de EventBridge.

← Seguridad · Todos los dominios · Almacenamiento →

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