Modelo mental
CloudWatch no es un producto: son dos servicios distintos con el mismo nombre, y casi todos los problemas vienen de tratarlos como uno.
Métricas es una serie temporal: publicas números, se agregan por periodos y se leen como estadísticas. Logs es un almacén de texto: ingieres líneas, se guardan y se consultan. Facturan distinto, escalan distinto y se rompen distinto. El único puente entre ambos son los metric filters, que buscan un patrón en los logs y publican una métrica cuando lo encuentran.
Envejecer no es caducar
Es el concepto que más gente descubre tarde, en mitad de una investigación:
| Resolución del dato | Cuánto vive así |
|---|---|
| menos de 60 s (alta resolución) | 3 horas |
| 60 s | 15 días |
| 300 s (5 min) | 63 días |
| 3 600 s (1 hora) | 455 días (15 meses) |
Y lo importante es cómo transiciona: un dato publicado por minuto sigue existiendo pasados 15 días, pero solo se puede leer agregado a 5 minutos. Pasados 63 días, a una hora.
Traducido: el pico de 30 segundos que causó el incidente del trimestre pasado ya no existe. Existe la media de la hora en la que ocurrió, que no dice nada. Si un dato va a hacer falta con grano fino más adelante, sácalo de CloudWatch a tiempo.
La dimensión que multiplica la factura
CloudWatch trata cada combinación única de dimensiones como una métrica
separada, aunque el nombre sea el mismo. Y solo puedes consultar las
combinaciones que publicaste: si mandaste Server=Prod,Domain=Frankfurt no
puedes preguntar por Server=Prod a secas.
De ahí sale el error caro: añadir una dimensión de alta cardinalidad
—usuarioId, pedidoId— no enriquece una métrica. Crea una métrica por cada
valor, y cada métrica personalizada se factura. Es la vía más rápida a una
factura de observabilidad que nadie sabe explicar.
Para eso están los logs y Contributor Insights, no las dimensiones.
Cómo te factura
| Concepto | Cómo se paga |
|---|---|
| Métricas personalizadas | por métrica y mes |
PutMetricData |
por millón de peticiones |
| Alarmas | por alarma y mes, y más caras las de alta resolución |
| Logs · ingesta | por GB ingerido — la línea dominante |
| Logs · almacenamiento | por GB y mes |
| Logs Insights | por GB escaneado en cada consulta |
Dos cosas dominan la factura y ninguna es la que la gente vigila:
La ingesta de logs. Se paga por GB que entra, no por GB que consultas. Un
console.log por invocación en una función con cien millones de invocaciones al
mes es una decisión de coste, no de estilo.
Logs Insights cobra por GB escaneado. Una consulta sin filtrar sobre un mes de logs escanea —y factura— el mes entero, aunque devuelva tres líneas. Acota siempre el rango temporal y el grupo de logs antes de filtrar por contenido.
Y una que sorprende: las métricas de alta resolución multiplican todo. Cada
PutMetricData se cobra, así que publicar cada segundo cuesta sesenta veces más
que publicar cada minuto, y las alarmas de 10 o 30 segundos tienen tarifa
propia.
Cuándo NO usarlo
- Como base de datos de series temporales. La retención de 15 meses es agregada; para análisis histórico con grano fino, exporta.
- Para trazas distribuidas. Ver cómo una petición atraviesa cinco servicios es X-Ray, no logs correlacionados a mano.
- Para consultas exploratorias frecuentes. Logs Insights cobra por GB escaneado; si vas a hacer veinte consultas al día sobre el mismo mes, sale más barato exportar a S3 y usar Athena.
- Para métricas de negocio de alta cardinalidad. Un contador por usuario no es una métrica: son miles de métricas.
Errores comunes
Meter identificadores en las dimensiones. Multiplica el número de métricas y la factura, y además ninguna de esas métricas se puede agregar después.
Creer que el dato de hace tres meses conserva el detalle. Está agregado a una hora. Lo que necesitabas ver ya no está.
No poner retención a los grupos de logs. Por defecto los logs no caducan: se guardan y se facturan para siempre. Es la línea de factura más común y la más fácil de arreglar.
Consultar en Logs Insights sin acotar. Filtra primero por grupo y por
tiempo; el filter por contenido se aplica sobre lo que ya escaneaste y pagaste.
Suponer que caben cinco destinos y luego seis. Los filtros de suscripción por grupo de logs son 5, y no se amplían. Es el techo real cuando quieres mandar los mismos logs a varios sitios.
Alarmas sobre una métrica que a veces no existe. Si una métrica deja de
publicarse, la alarma se queda en Insufficient Data en vez de dispararse.
Configura treatMissingData a conciencia — sobre todo en las alarmas de DLQ,
que precisamente vigilan algo que casi siempre está vacío.
Desplegar cien alarmas de golpe. PutMetricAlarm va a 3 por segundo.
Fuentes
Retención por resolución, agregación al envejecer, caducidad a los 15 meses,
dimensiones por métrica, rango admitido de timestamps, periodos válidos y
comportamiento de las alarmas:
Metrics concepts — Amazon CloudWatch.
Límites de API de métricas y alarmas:
CloudWatch service quotas.
Tamaño de evento, lote de PutLogEvents, grupos por cuenta, filtros de métrica
y de suscripción, FilterLogEvents por región y Live Tail:
CloudWatch Logs quotas.
Los modelos de precio proceden de la página de precios de AWS, que se renderiza
dinámicamente y no pudo citarse literalmente.