Administración de operaciones

Por qué existen métricas de 1 minuto y 5 minutos en CloudWatch - El equilibrio entre granularidad de monitoreo y costo

Explicamos las razones técnicas y económicas por las que el monitoreo básico (5 minutos) y el monitoreo detallado (1 minuto) de CloudWatch están separados, la agregación gradual de los períodos de retención de métricas y el modo de alta resolución de métricas personalizadas.

約 8 分で読めます

Por qué el intervalo de 5 minutos es el predeterminado

El monitoreo básico de EC2 recopila métricas en intervalos de 5 minutos. ¿Por qué 5 minutos y no 1 minuto? Hay 2 razones. Primero, el volumen de datos y el costo de almacenamiento. AWS recopila métricas de millones de instancias EC2. Con intervalos de 1 minuto se generan 5 veces más puntos de datos que con intervalos de 5 minutos, multiplicando por 5 los costos de almacenamiento y procesamiento. Para ofrecer el monitoreo básico de forma gratuita, el intervalo de 5 minutos es la línea económicamente razonable. Segundo, porque para la mayoría de las cargas de trabajo, los intervalos de 5 minutos son suficientes. Para comprender las tendencias de uso de CPU o tráfico de red, los datos de 5 minutos son adecuados. Las decisiones de escalado de Auto Scaling también funcionan correctamente con métricas de 5 minutos. Sin embargo, para detectar picos de carga o monitorear cargas de trabajo sensibles a la latencia, los intervalos de 5 minutos son demasiado gruesos. Un pico de CPU de 30 segundos se pierde en el valor promedio de 5 minutos y no se detecta. En estos casos, es necesario habilitar el monitoreo detallado (intervalo de 1 minuto).

Período de retención de métricas y agregación gradual

Los datos de métricas de CloudWatch se retienen permanentemente, pero la resolución disminuye gradualmente con el tiempo. Los puntos de datos de intervalo de 1 segundo se retienen durante 3 horas. Los puntos de datos de intervalo de 1 minuto se retienen durante 15 días. Los puntos de datos de intervalo de 5 minutos se retienen durante 63 días. Los puntos de datos de intervalo de 1 hora se retienen durante 455 días (aproximadamente 15 meses). Esta agregación gradual es un diseño que equilibra la eficiencia de almacenamiento con el análisis de tendencias a largo plazo. En las últimas 3 horas puede investigar incidentes con datos detallados por segundo, y en los últimos 15 meses puede planificar capacidad con datos por hora. Sin conocer esta regla de agregación, resulta confuso que "los datos de 1 minuto de ayer son visibles, pero los datos del mes pasado solo se ven en intervalos de 5 minutos". Si desea retener datos de alta resolución durante períodos prolongados, puede exportar datos a S3 mediante CloudWatch Metrics Streams y analizarlos con Athena.

Modo de alta resolución de métricas personalizadas

Las métricas personalizadas de CloudWatch tienen un intervalo predeterminado de 1 minuto, pero usando el modo de alta resolución (High-Resolution) puede enviar puntos de datos en intervalos de 1 segundo. Solo necesita establecer el parámetro StorageResolution de la API PutMetricData en 1. Las métricas de alta resolución son poderosas en casos de uso que requieren tiempo real. Por ejemplo, si monitorea el tiempo de respuesta de una API en intervalos de 1 segundo, puede detectar inmediatamente picos de latencia de unos pocos segundos. Con intervalos de 1 minuto, los picos se suavizan en el valor promedio de 60 segundos y se vuelven invisibles. Sin embargo, las métricas de alta resolución requieren consideración de costos. El precio de las métricas personalizadas es de 0.30 USD mensuales por métrica (hasta las primeras 10,000 métricas), sin diferencia de precio por resolución. Sin embargo, como aumenta el número de llamadas a la API PutMetricData, el costo de API (0.01 USD por cada 1,000 solicitudes) se incrementa. Enviar métricas en intervalos de 1 segundo durante un mes genera aproximadamente 2.6 millones de solicitudes (aproximadamente 26 USD mensuales). Con intervalos de 1 minuto son aproximadamente 43,000 solicitudes (aproximadamente 0.43 USD mensuales). Considerando esta diferencia de costo de 60 veces, aplique la alta resolución solo a las métricas que realmente la necesiten.

Período de evaluación de alarmas y configuración M de N

Las alarmas de CloudWatch son una función que envía notificaciones cuando una métrica supera un umbral, pero hay especificaciones detalladas en la lógica de evaluación que debe conocer. El período de evaluación (Period) de la alarma es el intervalo de tiempo para agregar puntos de datos de métricas. Si establece el período de evaluación en 5 minutos, el valor promedio (o máximo, mínimo, suma) de 5 minutos se compara con el umbral. La configuración "M de N" (Datapoints to Alarm) activa la alarma cuando el umbral se supera M o más veces en los últimos N períodos de evaluación. Por ejemplo, con "3 de 5", la alarma pasa al estado ALARM cuando el umbral se supera 3 o más veces en los últimos 5 períodos de evaluación. Esta configuración suprime las falsas alarmas (False Positives) causadas por picos temporales. Un aspecto que se pasa por alto fácilmente es el comportamiento cuando faltan puntos de datos de métricas. Cuando una instancia EC2 se detiene, deja de enviar métricas de CPU y los puntos de datos faltan. De forma predeterminada, los puntos de datos faltantes se tratan como "missing" y no afectan la transición de estado de la alarma. Con el parámetro TreatMissingData puede cambiar para tratar los datos faltantes como "breaching" (superando el umbral) o "notBreaching" (dentro del umbral).

Patrones donde los costos de CloudWatch se vuelven inesperadamente altos

El costo de CloudWatch que más se pasa por alto es el cargo por llamadas a la API GetMetricData. Cada vez que abre un dashboard de CloudWatch, se llama a la API GetMetricData para todas las métricas mostradas. Un dashboard con 10 widgets mostrando 5 métricas cada uno, con actualización automática (intervalo de 1 minuto) durante 8 horas, genera aproximadamente 24,000 solicitudes por día. El precio de GetMetricData es 0.01 USD por cada 1,000 solicitudes de métricas, por lo que solo este dashboard cuesta aproximadamente 7 USD mensuales. Con 10 dashboards son 70 USD mensuales. Otro patrón de alto costo es la ingesta de datos de CloudWatch Logs. Cuando las funciones Lambda o tareas ECS generan grandes volúmenes de logs, el cargo de ingesta (0.50 USD/GB) aumenta rápidamente. Dejar habilitados los logs de nivel DEBUG en producción puede generar cientos de dólares mensuales en cargos de logs. Como contramedidas, están la configuración apropiada del nivel de log, la reducción del período de retención de logs (el predeterminado es indefinido) y la exportación de solo los logs necesarios a S3 mediante filtros de suscripción de CloudWatch Logs. Para aprender sistemáticamente sobre diseño de monitoreo y optimización de costos, consulte libros especializados en Amazon.

Servicios relacionados

Amazon CloudWatchUn servicio que proporciona monitoreo, gestión de logs y alarmas para recursos AWS y aplicacionesAWS X-RayServicio de rastreo distribuido para analizar y depurar aplicaciones distribuidas

Artículos relacionados

Monitoreo integrado con Amazon CloudWatch - Diseño de métricas, logs y alarmasConstruya un monitoreo integrado con los 3 pilares de métricas, logs y alarmas. Presentamos el análisis interactivo con Logs Insights, notificaciones de alta precisión con alarmas compuestas y el uso de Embedded Metric Format.La capacidad de integración del stack de observabilidad de AWS - La transparencia operativa lograda por CloudWatch, X-Ray y CloudTrailComparamos el nivel de integración del stack de observabilidad de AWS centrado en CloudWatch, X-Ray y CloudTrail con Azure Monitor y GCP Cloud Logging, explicando la diferencia en calidad operativa que aportan los tres pilares de métricas, trazas y logs.

Más sobre este tema

El mecanismo de sincronización horaria interna de AWS - Amazon Time Sync Service y el diseño de smearing de segundos intercalaresExplicamos el mecanismo de Amazon Time Sync Service operado de forma independiente por AWS, la fuente de tiempo de alta precisión con GPS y relojes atómicos, la decisión de diseño de absorber los segundos intercalares mediante smearing y la importancia de la sincronización horaria en sistemas distribuidos.Centralización de registros de auditoría SaaS con AWS AppFabric - Estandarización OCSF e integración con Security LakeExplicamos la recopilación de registros de auditoría de aplicaciones SaaS con AppFabric, la estandarización al formato OCSF y la construcción de pipelines de análisis.Implementación de Feature Flags con AWS AppConfig - Despliegue seguro de configuración y rollbackDespliega cambios de configuración de forma independiente al código mediante estrategias Linear y Exponential. Garantiza la seguridad con rollback automático activado por alarmas de CloudWatch.Revisión de arquitectura - Evaluación sistemática de cargas de trabajo con AWS Well-Architected ToolExplica la revisión de arquitectura de cargas de trabajo usando AWS Well-Architected Tool. Presenta la evaluación basada en 6 pilares, la elaboración de planes de mejora y el uso de lentes personalizados.Diseño y operación de logs de auditoría - Registro completo de actividad API con CloudTrailExplica las técnicas de diseño de logs de auditoría con AWS CloudTrail, el registro de actividad API, el almacenamiento a largo plazo en S3 y la respuesta de cumplimiento mediante integración con Config.Lecciones de sistemas distribuidos de los informes de incidentes (COE) de AWS - Principios de diseño que cambiaron las grandes interrupciones del pasadoA partir de los Correction of Errors (COE) e informes de incidentes publicados por AWS, explicamos las causas raíz de grandes incidentes pasados como la interrupción de S3, la interrupción de DNS en us-east-1 y la interrupción de Kinesis, y cómo cambiaron los principios de diseño de AWS.El diseño de tags determina las operaciones - Curiosidades y reglas de nomenclatura prácticas de la estrategia de tags de recursos AWSExplicamos por qué los tags de recursos AWS no son simples etiquetas sino la base de la asignación de costos, control de acceso y automatización, las reglas de nomenclatura de claves de tags, cómo usar el límite de 50 tags y la gobernanza mediante políticas de tags.Por qué existen las cuotas de servicio de AWS - Diseño multitenant que protege la infraestructura compartidaExplicamos que las cuotas de servicio de AWS (antes límites de servicio) no son simples restricciones sino un diseño para proteger a otros clientes en un entorno multitenant, desde el problema del vecino ruidoso, la diferencia entre límites soft y hard, y el trasfondo de las solicitudes de aumento.

Artículos y servicios similares

Amazon CloudWatchServicio de monitoreo completamente administrado que supervisa y analiza de forma unificada métricas, logs y eventos de recursos AWS y aplicacionesPor qué los costos de CloudWatch Logs se vuelven inesperadamente altos - Estructura de costos de ingesta, almacenamiento y análisisExplicamos la estructura de precios donde el costo de ingesta de CloudWatch Logs es más de 20 veces el costo de almacenamiento, la explosión de costos causada por VPC Flow Logs y logs de Lambda, y las estrategias de optimización con la clase Infrequent Access y la exportación a S3.Base de datos de series temporales - Gestión eficiente de datos IoT y métricas con Amazon TimestreamExplicamos la gestión, consulta y análisis de datos de series temporales con Amazon Timestream. Presentamos el almacenamiento de datos de sensores IoT y métricas de aplicaciones, el almacenamiento con jerarquización automática y el análisis mediante consultas SQL.Construcción de una plataforma de análisis de datos industriales con AWS IoT SiteWise - Recopilación de datos de equipos y modelado de activosRecopile datos de equipos industriales con edge gateways, estructúrelos con modelos de activos y visualícelos en dashboards. Presentamos una plataforma de análisis de datos de equipos compatible con OPC-UA.