El dominio de Monitoreo y Registro representa el 15% del examen DOP-C02. Las preguntas van mas alla de saber que servicio recopila que datos: evaluan si puedes disenar un pipeline completo desde la recopilacion hasta el analisis y la automatizacion de acciones. Piensa en un ingeniero de guardia resolviendo un incidente de produccion a las 3 AM: el examen pregunta que combinacion de herramientas es correcta para cada situacion.
Diseno del Pipeline de Recopilacion de Logs
La base del monitoreo efectivo es recopilar datos correctamente. CloudWatch es una plataforma poderosa donde un solo agente puede recopilar logs y metricas personalizadas simultaneamente.
CloudWatch Agent y Metricas Personalizadas
Las metricas predeterminadas de CloudWatch para EC2 no incluyen utilizacion de memoria ni I/O de disco detallado. Para recopilarlas, debes instalar CloudWatch Agent. El agente funciona de manera identica en EC2 (Linux y Windows) y en servidores on-premises.
Considera una empresa de videojuegos que opera miles de instancias EC2. Mantenia un daemon de recopilacion de logs desarrollado internamente y experimentaba gaps de configuracion frecuentes al lanzar nuevas instancias. La solucion es CloudWatch Agent combinado con AWS Systems Manager State Manager. State Manager aplica el agente automaticamente a nuevas instancias, mientras SSM Parameter Store almacena la configuracion centralizada y versionada del agente.
| Metodo de Recopilacion | Objetivo | Caracteristicas Clave | |----------------------|---------|----------------------| | CloudWatch Agent | EC2, on-premises | Metricas de memoria/disco y recopilacion de archivos de log | | CloudWatch Embedded Metric Format (EMF) | Lambda, ECS, EC2 | Incrusta metricas en logs JSON, sin llamadas directas a PutMetricData | | AWS Distro for OpenTelemetry (ADOT) | Contenedores, serverless | Estandar OpenTelemetry, envia a X-Ray y CloudWatch simultaneamente |
EMF es efectivo para reducir costos de API. Enviar multiples puntos de datos de metricas individualmente via PutMetricData genera cargos por llamada. EMF envia logs JSON estructurados a CloudWatch Logs y AWS extrae automaticamente las metricas. El costo es menor que las llamadas directas a PutMetricData, y las metricas extraidas soportan alarmas igual que las metricas estandar de CloudWatch.
Kinesis Data Firehose con Transformacion Lambda
Un escenario comun en el examen involucra una plataforma IoT que recibe logs en diferentes formatos de miles de dispositivos, necesitando almacenarlos en S3 y consultarlos con Athena. La respuesta es Kinesis Data Firehose con una transformacion Lambda.
Kinesis Data Firehose es un servicio completamente administrado que no requiere administracion de servidores. Una funcion Lambda actua como procesador de transformacion de datos, convirtiendo varios formatos de log a JSON antes de escribir en S3. La configuracion de tamano de buffer (1-128 MB) e intervalo de buffer (60-900 segundos) proporciona entrega por lotes en tiempo casi real.
La distincion de Kinesis Data Streams es clara. Data Streams requiere gestion de shards e implementacion de checkpoints, aumentando la complejidad operativa. Firehose entrega automaticamente a S3, Redshift u OpenSearch sin codigo de consumidor. Firehose tambien es menos costoso.
Los registros con fallo de transformacion se conservan en un bucket S3 separado, garantizando cero perdida de datos. Este comportamiento de "preservacion de registros de error" se evalua cuando la pregunta incluye la condicion "no se acepta perdida de datos."
Politicas de Suscripcion a Nivel de Cuenta y Agregacion de Logs Entre Cuentas
Cuando se agregan cientos de grupos de logs dinamicamente, configurar filtros de suscripcion individualmente es impractico operativamente. Las politicas de suscripcion a nivel de cuenta de CloudWatch Logs, configuradas una vez, se aplican automaticamente a todos los grupos de logs actuales y futuros en la cuenta. Este es el patron de respuesta cuando la pregunta combina "minimizar sobrecarga operativa" con un numero creciente de grupos de logs.
Arquitectura de agregacion de logs multi-cuenta:
Cada cuenta miembro: configurar politica de suscripcion a nivel de cuenta de CloudWatch Logs Cuenta central de Auditoria: Kinesis Data Firehose esperando para recibir logs Los filtros de suscripcion de cuentas miembro reenvian directamente al Firehose central (entrega entre cuentas) Politica de Ciclo de Vida S3: transicion automatica a S3 Glacier despues de 90 dias
La distincion entre Export Task y filtro de suscripcion importa. Las Export Tasks son por lotes y manuales, con retrasos de hasta 12 horas. Los filtros de suscripcion son en tiempo real y automaticos, proporcionando entrega en tiempo casi real.
Campos de Tiempo en Logs de Acceso ALB
Los logs de acceso ALB dividen el tiempo de procesamiento de solicitudes en tres campos. El examen te pide distinguirlos con precision.
| Campo | Significado | Que Indica si es Alto | |-------|-------------|----------------------| | request_processing_time | Tiempo desde recibir solicitud del cliente hasta reenviar al destino | Cuello de botella en ALB | | target_processing_time | Tiempo que el destino tarda en procesar la solicitud | Problema de rendimiento de aplicacion o base de datos | | response_processing_time | Tiempo desde recibir respuesta del destino hasta enviar al cliente | Latencia de red o ruta de retorno ALB |
Cuando target_processing_time es alto, el problema esta en el codigo de la aplicacion o las consultas de base de datos. Cuando request_processing_time es alto, el cuello de botella es el ALB mismo. Estos campos se analizan usando CloudWatch Logs Insights o Athena.
Rastreo Distribuido y Monitoreo Hibrido
Rastreo Distribuido con X-Ray
En una arquitectura de microservicios, cuando una llamada API especifica es lenta, identificar que servicio es el cuello de botella es dificil. X-Ray visualiza el camino completo que toma una solicitud a traves de multiples servicios.
Conceptos clave de X-Ray: Trace: el camino de ejecucion completo de una sola solicitud Segment: la unidad de trabajo realizada en cada servicio Subsegment: unidades de trabajo granulares como llamadas a API externas y consultas de base de datos Mapa de Servicio: representacion visual de dependencias de servicios y tiempos de respuesta
Puedes instrumentar Lambda, ECS, EC2, API Gateway y Elastic Beanstalk usando el SDK de X-Ray. Lambda soporta X-Ray Active Tracing, que habilita rastreo basico sin cambios de codigo.
Amazon Managed Grafana + Prometheus para Entornos Hibridos
Para monitoreo unificado de entornos hibridos que mezclan EKS, ECS y on-premises, la combinacion de Amazon Managed Grafana + Amazon Managed Service for Prometheus aparece en el examen. Este par es completamente administrado sin administracion de servidores, siendo compatible con el ecosistema Prometheus.
El modelo de recopilacion de metricas difiere de CloudWatch. CloudWatch usa un modelo push; Prometheus usa un modelo pull, haciendo scraping de targets para metricas. Grafana soporta ambas fuentes de datos, permitiendo dashboards unificados que combinan metricas de CloudWatch y Prometheus.
Herramientas de Analisis de CloudWatch Logs
Logs Insights y Filtros de Metricas
CloudWatch Logs Insights proporciona analisis interactivo de logs usando un lenguaje de consulta similar a SQL con capacidades de busqueda en tiempo casi real. Esto lo hace adecuado para consultar logs de aplicaciones de Elastic Beanstalk, ECS y otros servicios en tiempo real. Athena es un servicio de consultas por lotes que analiza datos ya almacenados en S3.
CloudWatch Logs Metric Filter detecta patrones regex en streams de log en tiempo real y convierte coincidencias en metricas personalizadas de CloudWatch. Se configura completamente en la consola sin ningun codigo, manteniendo baja la sobrecarga operativa.
Escenario de Centro de Operaciones de Seguridad: cuando los logs del firewall deben activar alertas inmediatas en eventos de severidad CRITICAL sin servicios de seguridad adicionales, la respuesta es CloudWatch Logs Metric Filter + CloudWatch Alarm + SNS. Este patron de tres servicios es la respuesta cuando las condiciones incluyen "sin codigo requerido", "minimizar sobrecarga operativa" y "basado en CloudWatch Logs existente."
Distincion entre Metric Filter y Subscription Filter: Metric Filter: el emparejamiento de patrones produce metricas de conteo que activan Alarmas (para alertas) Subscription Filter: transmite eventos de log a Lambda, Kinesis o Firehose en tiempo real (para pipelines de datos)
Automatizacion Basada en Eventos y Auto-Recuperacion
Patrones de Eventos EventBridge
EventBridge es el hub para construir cadenas de automatizacion a partir de eventos emitidos por servicios AWS. Patrones de eventos importantes para el examen:
| Servicio | Valor source | Eventos Clave | |---------|-------------|--------------| | EC2 Auto Scaling | aws.autoscaling | EC2_INSTANCE_LAUNCH_UNSUCCESSFUL | | AWS Trusted Advisor | aws.trustedadvisor | Limite de servicio aproximandose al 80% | | AWS Health | aws.health | Retiro de instancia, interrupcion de servicio | | AWS Config | aws.config | Cambio de cumplimiento de configuracion |
Escenario de fallo en el lanzamiento de instancia de Auto Scaling: durante un evento promocional, Auto Scaling fallo en lanzar instancias pero el equipo solo lo supo horas despues. La solucion es una regla EventBridge que detecta eventos EC2_INSTANCE_LAUNCH_UNSUCCESSFUL y los enruta a SNS para notificacion inmediata. No se necesita infraestructura adicional mas alla de EventBridge y SNS.
No confundas esto con Lifecycle Hooks. Los Lifecycle Hooks se ejecutan despues de un lanzamiento exitoso de instancia mientras esta en estado Pending. No pueden detectar un fallo de lanzamiento.
CloudWatch Alarms + Lambda para Auto-Remediacion
Las Alarmas de CloudWatch van mas alla de las notificaciones simples