Monitoreo, logs y alertas con los servicios nativos
Cada nube trae su propio servicio de métricas, logs y alertas, y con eso alcanza para la mayoría de los sistemas. Lo que decide si sirve no es la herramienta: es qué se mide, cuánto se retiene y qué llega a interrumpir a una persona.
Datos de proveedores verificados contra la documentación oficial el 19 de sept de 2026.
El monitoreo nativo viene puesto: las métricas de las instancias, los logs de las funciones y los paneles por defecto aparecen sin configurar nada. Da una sensación de cobertura que dura hasta el primer incidente.
Porque lo que viene por defecto responde “¿cómo está la máquina?” y el incidente pregunta otra cosa: ¿el sistema está sirviendo bien a quien lo usa? Esa diferencia es todo el tema.
Métricas, logs y trazas
| Señal | Qué responde | Costo | Cuándo se mira |
|---|---|---|---|
| Métricas | ¿Está pasando algo raro? | Bajo: son números agregados | Siempre, en paneles y alertas |
| Logs | ¿Qué pasó exactamente? | Alto: crecen con el tráfico | Cuando ya se sabe dónde mirar |
| Trazas | ¿Dónde se fue el tiempo? | Medio, con muestreo | Cuando algo está lento y hay varios servicios |
El orden de uso es siempre el mismo: la métrica avisa, la traza ubica en qué servicio está el problema, y el log dice qué pasó en esa línea concreta. Saltar directo a los logs es lo que convierte un incidente de diez minutos en uno de una hora.
Qué medir, si hay que elegir
Las métricas de la máquina —CPU, memoria, disco— son útiles para diagnosticar, no para saber si el sistema anda. Las que dicen si anda son las que ve el usuario.
Las cuatro que casi siempre alcanzan
- Latencia, medida en percentiles y no en promedio: el promedio esconde exactamente a los usuarios que la están pasando mal.
- Tráfico: requests por segundo, o el equivalente del sistema. Sin esto, ninguna otra métrica se puede interpretar.
- Errores: la proporción, no la cantidad. Cien errores sobre un millón de requests es otra cosa que cien sobre mil.
- Saturación: qué tan cerca está del límite el recurso más escaso, que es lo único que anticipa el problema antes de que ocurra.
Para el trabajo asincrónico la cuarta cambia de forma y es la más importante: la antigüedad del mensaje más viejo pendiente. Es la métrica que avisa que los consumidores no dan abasto mientras todavía hay tiempo de hacer algo.
Antes de seguir, predecí
Logs: estructurados, retenidos a conciencia y caros
Cuatro decisiones que definen si los logs sirven
- Estructurados, en JSON, con campos consistentes. Un log de texto libre se puede leer; uno estructurado se puede consultar, agrupar y graficar.
- Sin datos personales ni secretos. Lo que entra a los logs se replica, se exporta y se retiene por meses: es la vía más común de filtración accidental.
- Con niveles usados en serio. Si todo es
info, no hay señal. Si haydebugen producción, la factura lo va a mostrar. - Con retención por tipo: los de auditoría, largo; los de aplicación, semanas; los de acceso, lo que haga falta para diagnosticar. Retener todo un año “por las dudas” es una decisión de costo, no de seguridad.
Antes de seguir, predecí
Alertas: pocas y accionables
El criterio es el mismo en cualquier herramienta: si al recibirla no hay nada que hacer, no era una alerta. Lo que agregan los servicios nativos es dónde ponerla.
El conjunto mínimo de una aplicación en la nube
- Disponibilidad vista desde afuera, con un chequeo sintético desde otra región: es lo único que detecta que el DNS, el certificado o el balanceador se rompieron.
- Proporción de errores por encima del objetivo, sostenida unos minutos.
- Latencia del percentil alto por encima del objetivo.
- Trabajo pendiente creciendo en colas y en tareas programadas.
- Presupuesto y anomalías de gasto, que en la nube es una alerta operativa y no administrativa.
- Auditoría: cambios en políticas de identidad, en claves y en reglas de red.
Más a fondo · nivel seniorObjetivos de nivel de servicio en vez de umbrales sueltos
El salto de calidad no es tener más alertas sino cambiar la pregunta. En vez de “alertar si la latencia supera X”, se define qué proporción de requests tiene que ser buena en una ventana —por ejemplo, el 99,5 % por debajo de 300 ms en 30 días— y se mide cuánto margen de error queda.
Eso da dos cosas que los umbrales sueltos no dan: una alerta que dispara según cuán rápido se está consumiendo el margen —urgente si se gasta en una hora, un ticket si se gasta en dos semanas—, y una conversación con producto en términos concretos, porque el margen restante es el argumento para decidir si la semana que viene se lanza una funcionalidad o se arregla la estabilidad.
Los tres proveedores ya lo soportan de forma nativa, y es lo que evita el otro extremo del problema: alertas que no molestan a nadie porque nadie les cree.
Cierre
Autoevaluación
¿Lo entendiste?
Práctica