Es lunes a la ma\u00f1ana y el tel\u00e9fono empieza a sonar. Un cliente avisa que la tienda online no carga, otro que no le lleg\u00f3 la factura por correo y un tercero que el formulario de contacto da error. El equipo se entera del problema por la misma v\u00eda que los clientes: cuando ya est\u00e1 afectando al negocio.<\/p>\n
Esta escena es m\u00e1s com\u00fan de lo que parece. Muchas empresas tienen sistemas que funcionan bien la mayor parte del tiempo, pero nadie mira c\u00f3mo est\u00e1n hasta que algo se rompe.<\/p>\n
Sin embargo, la mayor\u00eda de las fallas no aparecen de golpe. Un disco que se llena de a poco, un certificado que est\u00e1 por vencer, una consulta a la base de datos que cada semana tarda un poco m\u00e1s o una integraci\u00f3n que falla una de cada cien veces suelen dar se\u00f1ales antes de convertirse en un problema visible.<\/p>\n
En esta nota repasamos qu\u00e9 son el monitoreo y la observabilidad, qu\u00e9 conviene medir, c\u00f3mo armar alertas que sirvan, qu\u00e9 herramientas existen y c\u00f3mo implementarlo por etapas en una pyme. Al final hay una lista de verificaci\u00f3n para revisar el estado actual de tus sistemas.<\/p>\n
Monitorear un sistema es observarlo de forma continua para saber si est\u00e1 funcionando como se espera. En la pr\u00e1ctica, implica recolectar datos (si el sitio responde, cu\u00e1nto tarda, cu\u00e1ntos errores hay, cu\u00e1nto espacio queda en disco) y avisar cuando algo se sale de lo normal.<\/p>\n
El objetivo no es acumular gr\u00e1ficos. Es enterarse antes que los clientes.<\/p>\n
Un buen monitoreo permite:<\/p>\n
Sin monitoreo, el equipo t\u00e9cnico trabaja a ciegas. Cada incidente empieza con la misma pregunta: \u00bfdesde cu\u00e1ndo pasa esto?<\/p>\n
Los dos t\u00e9rminos suelen usarse como sin\u00f3nimos, pero apuntan a cosas distintas.<\/p>\n
El monitoreo responde preguntas que ya sabemos hacer: \u00bfel sitio est\u00e1 arriba?, \u00bfla CPU supera el 90 %?, \u00bfhay m\u00e1s errores que lo habitual? Se basa en m\u00e9tricas y umbrales definidos de antemano.<\/p>\n
La observabilidad va un paso m\u00e1s all\u00e1. Es la capacidad de entender qu\u00e9 est\u00e1 pasando dentro de un sistema a partir de los datos que produce, incluso ante problemas que nadie anticip\u00f3. El proyecto OpenTelemetry<\/a> la describe como la posibilidad de entender un sistema desde afuera, haciendo preguntas sobre \u00e9l sin necesidad de conocer de antemano su funcionamiento interno.<\/p>\n Dicho de forma simple:<\/p>\n Una pyme no necesita empezar con observabilidad completa. Pero s\u00ed conviene dise\u00f1ar los sistemas para que, cuando algo falle, haya datos suficientes para encontrar la causa.<\/p>\n La observabilidad suele apoyarse en tres tipos de datos complementarios.<\/p>\n Son valores num\u00e9ricos medidos a lo largo del tiempo: uso de CPU, memoria, tiempo de respuesta, cantidad de pedidos por hora, errores por minuto. Ocupan poco espacio, se grafican f\u00e1cilmente y son ideales para alertas.<\/p>\n Son registros de eventos con fecha y hora: un usuario inici\u00f3 sesi\u00f3n, fall\u00f3 un pago, una integraci\u00f3n devolvi\u00f3 un error. Permiten reconstruir qu\u00e9 pas\u00f3 en un momento puntual.<\/p>\n Para que sean \u00fatiles, conviene que:<\/p>\n Siguen el recorrido de una operaci\u00f3n a trav\u00e9s de varios sistemas. Por ejemplo: el cliente confirma una compra, la tienda llama a la pasarela de pago, despu\u00e9s al sistema de gesti\u00f3n y finalmente al servicio de env\u00edos. Una traza muestra cu\u00e1nto tard\u00f3 cada paso y d\u00f3nde se produjo el error.<\/p>\n Las trazas cobran importancia cuando hay integraciones, APIs y varios servicios conectados entre s\u00ed.<\/p>\n No hace falta medirlo todo desde el primer d\u00eda. Conviene empezar por lo que m\u00e1s impacta en los clientes y en la operaci\u00f3n.<\/p>\n Google propone en su libro sobre Site Reliability Engineering<\/a> cuatro se\u00f1ales clave para cualquier servicio:<\/p>\n Con esas cuatro se\u00f1ales bien medidas, la mayor\u00eda de los problemas se detectan a tiempo.<\/p>\n Lo m\u00e1s b\u00e1sico: comprobar cada pocos minutos, desde afuera, que el sitio web, la tienda online, el sistema de gesti\u00f3n y las APIs respondan correctamente.<\/p>\n Conviene verificar:<\/p>\n Los servidores, propios o en la nube, dan se\u00f1ales claras antes de fallar:<\/p>\n Muchas veces el primer s\u00edntoma de un problema t\u00e9cnico aparece en un n\u00famero del negocio. Por ejemplo:<\/p>\n Un sitio puede estar t\u00e9cnicamente arriba y, aun as\u00ed, no estar vendiendo.<\/p>\n Una alerta es \u00fatil cuando avisa algo importante, a la persona correcta, con tiempo para actuar. Cuando no cumple eso, se convierte en ruido.<\/p>\n El problema m\u00e1s com\u00fan no es la falta de alertas, sino el exceso. Si el equipo recibe veinte avisos por d\u00eda y diecinueve no requieren acci\u00f3n, pronto deja de prestarles atenci\u00f3n. Y el d\u00eda que llega la alerta importante, pasa desapercibida.<\/p>\n Algunas buenas pr\u00e1cticas son:<\/p>\n No todas las alertas merecen el mismo canal:<\/p>\n La regla es simple: si una alerta despierta a alguien a la madrugada, tiene que justificar ese costo.<\/p>\n Hay opciones para todos los tama\u00f1os y presupuestos. La elecci\u00f3n depende de qu\u00e9 se quiere medir, d\u00f3nde est\u00e1n los sistemas y qui\u00e9n va a mantener la soluci\u00f3n.<\/p>\n\n
Los tres pilares de la observabilidad<\/h2>\n
M\u00e9tricas<\/h3>\n
Logs<\/h3>\n
\n
Trazas<\/h3>\n
Qu\u00e9 conviene medir primero<\/h2>\n
\n
Disponibilidad del sitio y los sistemas<\/h3>\n
\n
Infraestructura<\/h3>\n
\n
Indicadores de negocio<\/h3>\n
\n
Alertas que sirven y alertas que molestan<\/h2>\n
\n
Elegir el canal correcto<\/h3>\n
\n
Herramientas disponibles<\/h2>\n