Monitoreo y observabilidad: cómo detectar problemas antes que los clientes

Es lunes a la mañana y el teléfono empieza a sonar. Un cliente avisa que la tienda online no carga, otro que no le llegó la factura por correo y un tercero que el formulario de contacto da error. El equipo se entera del problema por la misma vía que los clientes: cuando ya está afectando al negocio.

Esta escena es más común de lo que parece. Muchas empresas tienen sistemas que funcionan bien la mayor parte del tiempo, pero nadie mira cómo están hasta que algo se rompe.

Sin embargo, la mayoría de las fallas no aparecen de golpe. Un disco que se llena de a poco, un certificado que está por vencer, una consulta a la base de datos que cada semana tarda un poco más o una integración que falla una de cada cien veces suelen dar señales antes de convertirse en un problema visible.

En esta nota repasamos qué son el monitoreo y la observabilidad, qué conviene medir, cómo armar alertas que sirvan, qué herramientas existen y cómo implementarlo por etapas en una pyme. Al final hay una lista de verificación para revisar el estado actual de tus sistemas.

Qué es el monitoreo y por qué importa

Monitorear un sistema es observarlo de forma continua para saber si está funcionando como se espera. En la práctica, implica recolectar datos (si el sitio responde, cuánto tarda, cuántos errores hay, cuánto espacio queda en disco) y avisar cuando algo se sale de lo normal.

El objetivo no es acumular gráficos. Es enterarse antes que los clientes.

Un buen monitoreo permite:

Detectar caídas en minutos, no en horas.
Ver tendencias antes de que se transformen en fallas.
Saber qué cambió cuando algo empezó a andar mal.
Medir si una mejora realmente mejoró algo.
Tener datos concretos para decidir inversiones en infraestructura.

Sin monitoreo, el equipo técnico trabaja a ciegas. Cada incidente empieza con la misma pregunta: ¿desde cuándo pasa esto?

Monitoreo y observabilidad no son lo mismo

Los dos términos suelen usarse como sinónimos, pero apuntan a cosas distintas.

El monitoreo responde preguntas que ya sabemos hacer: ¿el sitio está arriba?, ¿la CPU supera el 90 %?, ¿hay más errores que lo habitual? Se basa en métricas y umbrales definidos de antemano.

La observabilidad va un paso más allá. Es la capacidad de entender qué está pasando dentro de un sistema a partir de los datos que produce, incluso ante problemas que nadie anticipó. El proyecto OpenTelemetry la describe como la posibilidad de entender un sistema desde afuera, haciendo preguntas sobre él sin necesidad de conocer de antemano su funcionamiento interno.

Dicho de forma simple:

El monitoreo avisa que algo anda mal.
La observabilidad ayuda a entender por qué.

Una pyme no necesita empezar con observabilidad completa. Pero sí conviene diseñar los sistemas para que, cuando algo falle, haya datos suficientes para encontrar la causa.

Los tres pilares de la observabilidad

La observabilidad suele apoyarse en tres tipos de datos complementarios.

Métricas

Son valores numéricos 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ácilmente y son ideales para alertas.

Logs

Son registros de eventos con fecha y hora: un usuario inició sesión, falló un pago, una integración devolvió un error. Permiten reconstruir qué pasó en un momento puntual.

Para que sean útiles, conviene que:

Tengan un formato consistente.
Incluyan fecha, hora y nivel (información, advertencia, error).
Se guarden en un lugar centralizado y no solo en cada servidor.
No registren contraseñas, tarjetas ni datos personales innecesarios.
Tengan un período de retención definido.

Trazas

Siguen el recorrido de una operación a través de varios sistemas. Por ejemplo: el cliente confirma una compra, la tienda llama a la pasarela de pago, después al sistema de gestión y finalmente al servicio de envíos. Una traza muestra cuánto tardó cada paso y dónde se produjo el error.

Las trazas cobran importancia cuando hay integraciones, APIs y varios servicios conectados entre sí.

Qué conviene medir primero

No hace falta medirlo todo desde el primer día. Conviene empezar por lo que más impacta en los clientes y en la operación.

Google propone en su libro sobre Site Reliability Engineering cuatro señales clave para cualquier servicio:

Latencia: cuánto tarda en responder.
Tráfico: cuánta demanda recibe.
Errores: qué proporción de pedidos falla.
Saturación: qué tan cerca está de su límite de capacidad.

Con esas cuatro señales bien medidas, la mayoría de los problemas se detectan a tiempo.

Disponibilidad del sitio y los sistemas

Lo más básico: comprobar cada pocos minutos, desde afuera, que el sitio web, la tienda online, el sistema de gestión y las APIs respondan correctamente.

Conviene verificar:

Que la página responda con un código correcto.
Que el tiempo de respuesta esté dentro de lo esperado.
Que el contenido sea el correcto (y no una página de error con código 200).
Que el certificado SSL esté vigente.
Que el dominio no esté por vencer.

Infraestructura

Los servidores, propios o en la nube, dan señales claras antes de fallar:

Espacio en disco.
Uso de memoria y CPU.
Conexiones a la base de datos.
Estado de los backups.
Tareas programadas que se ejecutaron (o no).

Indicadores de negocio

Muchas veces el primer síntoma de un problema técnico aparece en un número del negocio. Por ejemplo:

Pedidos por hora muy por debajo de lo habitual.
Pagos rechazados por encima del promedio.
Formularios de contacto que dejan de llegar.
Facturas que no se emiten.
Correos transaccionales que no salen.

Un sitio puede estar técnicamente arriba y, aun así, no estar vendiendo.

Alertas que sirven y alertas que molestan

Una alerta es útil cuando avisa algo importante, a la persona correcta, con tiempo para actuar. Cuando no cumple eso, se convierte en ruido.

El problema más común no es la falta de alertas, sino el exceso. Si el equipo recibe veinte avisos por día y diecinueve no requieren acción, pronto deja de prestarles atención. Y el día que llega la alerta importante, pasa desapercibida.

Algunas buenas prácticas son:

Alertar sobre síntomas que afectan a los usuarios, no sobre cada métrica interna.
Definir umbrales a partir de datos reales y no de supuestos.
Usar distintos niveles de urgencia.
Enviar cada alerta a un responsable concreto.
Incluir en el aviso qué pasa, desde cuándo y dónde mirar.
Revisar periódicamente las alertas que nunca generaron acción.

Elegir el canal correcto

No todas las alertas merecen el mismo canal:

Caída del sitio o del sistema de gestión: aviso inmediato por mensaje o llamada.
Disco al 80 % o certificado que vence en 15 días: correo o canal del equipo.
Tendencias y reportes: resumen semanal.

La regla es simple: si una alerta despierta a alguien a la madrugada, tiene que justificar ese costo.

Herramientas disponibles

Hay opciones para todos los tamaños y presupuestos. La elección depende de qué se quiere medir, dónde están los sistemas y quién va a mantener la solución.

Tipo	Para qué sirve	Ejemplos
Monitoreo de disponibilidad	Verificar desde afuera que sitios y APIs respondan	UptimeRobot, Uptime Kuma, Better Stack
Métricas e infraestructura	Medir servidores, bases de datos y servicios	Prometheus, Grafana, Zabbix
Logs centralizados	Reunir y buscar registros de varios sistemas	Grafana Loki, Elastic, Graylog
Errores de aplicación	Detectar y agrupar errores en el código	Sentry
Plataformas integrales	Métricas, logs y trazas en un solo lugar	Datadog, New Relic, Grafana Cloud

Varias de estas herramientas son de código abierto, como Prometheus, Grafana o Zabbix, y pueden instalarse en servidores propios. Otras se contratan como servicio y se pagan según el volumen de datos o la cantidad de equipos.

Los proveedores de nube también ofrecen sus propias herramientas, como Amazon CloudWatch o Azure Monitor, que se integran directamente con los recursos contratados.

Qué tener en cuenta al elegir

Antes de decidir, conviene preguntarse:

¿Qué sistemas necesitamos monitorear?
¿Están en la oficina, en la nube o en ambos lados?
¿Quién va a configurar y mantener la herramienta?
¿Cuánto cuesta a medida que crece el volumen de datos?
¿Se integra con los canales que ya usa el equipo?
¿Dónde se guardan los datos y por cuánto tiempo?

Una herramienta sofisticada que nadie mira sirve menos que un monitoreo simple que el equipo revisa todos los días.

Errores frecuentes al implementar monitoreo

Los problemas más comunes no son técnicos, sino de enfoque.

Monitorear solo la infraestructura

Un servidor puede tener la CPU baja y la memoria libre mientras la tienda online devuelve errores en el checkout. Si solo se miran los recursos del equipo, se pierden las fallas de la aplicación.

Monitorear solo desde adentro

Si el chequeo corre en el mismo servidor que se quiere vigilar, cuando ese servidor se cae también se cae el monitoreo. Siempre conviene tener al menos una verificación externa.

No probar las alertas

Una alerta configurada y nunca probada puede no funcionar el día que hace falta: un correo mal escrito, un canal archivado o un número de teléfono que cambió.

Olvidarse de los backups

Muchas empresas tienen backups programados, pero nadie verifica que se ejecuten ni que se puedan restaurar. Un backup que falla en silencio durante meses es uno de los riesgos más caros.

Medir sin actuar

Tableros llenos de gráficos que nadie revisa no aportan valor. El monitoreo tiene que estar conectado con un proceso: quién mira, cuándo y qué hace con lo que ve.

Del incidente al aprendizaje

Por más monitoreo que haya, los incidentes van a ocurrir. La diferencia está en cómo se responden y qué se aprende de ellos.

Una respuesta ordenada suele seguir estos pasos:

Detectar el problema y confirmar su alcance.
Avisar a las personas que tienen que saberlo, incluidos los clientes si corresponde.
Restablecer el servicio lo antes posible, aunque sea con una solución temporal.
Investigar la causa con los datos de métricas, logs y trazas.
Corregir la causa de fondo.
Documentar qué pasó y qué se cambió.

El último paso es el que más se saltea y el que más valor genera. Una revisión breve después de cada incidente, sin buscar culpables, ayuda a que el mismo problema no se repita.

Algunas preguntas útiles para esa revisión:

¿Cuándo empezó realmente el problema?
¿Cuándo nos enteramos y por qué vía?
¿Qué alerta debería haberlo detectado antes?
¿Qué información nos faltó para resolverlo más rápido?
¿Qué vamos a cambiar para evitarlo?

Cada incidente bien analizado mejora el monitoreo.

Escenarios concretos

Una tienda online en temporada alta

Durante un evento como el Hot Sale de la CACE, una tienda recibe mucho más tráfico que de costumbre. Con monitoreo de tiempo de respuesta y de errores en el checkout, el equipo puede ver que el sitio se está poniendo lento antes de que empiece a rechazar compras, y escalar recursos o desactivar funciones secundarias a tiempo.

Una distribuidora con sistema de gestión propio

El sistema de gestión corre en un servidor y genera los pedidos para el depósito todas las mañanas. Una alerta de espacio en disco al 85 % avisa con días de anticipación que los logs están llenando el equipo. Sin ese aviso, el problema aparecería un lunes a las 8 con el depósito parado.

Una empresa de servicios con integraciones

La empresa conecta su CRM con el sistema de facturación mediante una API. Un día, el proveedor cambia algo y una de cada veinte facturas falla. Sin monitoreo de errores en la integración, el problema se descubre a fin de mes, cuando los clientes reclaman. Con una alerta sobre la tasa de errores, se detecta el mismo día.

Un sitio institucional

Un sitio web sencillo también puede fallar: un plugin desactualizado, un certificado vencido o un dominio que no se renovó. Un chequeo externo cada cinco minutos y un aviso de vencimientos alcanzan para evitar la mayoría de estos sustos.

Cómo implementarlo por etapas

No hace falta un proyecto enorme. Un enfoque gradual permite obtener resultados desde la primera semana.

Etapa 1: chequeos externos de disponibilidad para el sitio, la tienda y los sistemas críticos, con alertas a un responsable.
Etapa 2: monitoreo de vencimientos (certificados y dominios), espacio en disco y estado de los backups.
Etapa 3: métricas de infraestructura y de rendimiento de las aplicaciones principales.
Etapa 4: centralización de logs y seguimiento de errores de aplicación.
Etapa 5: indicadores de negocio, tableros compartidos y revisión periódica de alertas.
Etapa 6: trazas en integraciones y servicios conectados, si la complejidad lo justifica.

Cada etapa debería dejar algo funcionando y en uso antes de pasar a la siguiente.

Quién se encarga

El monitoreo necesita un dueño. Puede ser una persona del equipo interno, un proveedor externo o una combinación de ambos. Lo importante es que esté claro:

Quién recibe las alertas.
Quién responde fuera del horario laboral.
Quién revisa los tableros y con qué frecuencia.
Quién actualiza la configuración cuando cambian los sistemas.

Cuánto cuesta y cuánto ahorra

El costo del monitoreo depende de la cantidad de sistemas, del volumen de datos y de si se usan herramientas propias o servicios pagos. Para una pyme, un esquema básico puede armarse con herramientas gratuitas o de bajo costo.

La comparación que conviene hacer no es contra cero, sino contra el costo de una caída:

Ventas perdidas mientras el sitio no funciona.
Horas del equipo dedicadas a apagar incendios.
Reclamos y pérdida de confianza de los clientes.
Datos perdidos por backups que no funcionaban.
Trabajo urgente fuera de horario, que suele ser más caro.

Una sola caída evitada en temporada alta puede justificar la inversión de todo un año.

Seguridad y monitoreo

El monitoreo también es una herramienta de seguridad. Muchos ataques dejan rastros visibles en los datos: intentos de inicio de sesión fallidos, picos de tráfico inusuales, cambios en archivos que no deberían modificarse o accesos desde ubicaciones extrañas.

La guía OWASP Top 10 incluye las fallas de registro y monitoreo entre los riesgos de seguridad más relevantes en aplicaciones web, justamente porque sin ellos los ataques pasan desapercibidos durante mucho tiempo.

Algunas señales que conviene vigilar:

Intentos fallidos de acceso al panel de administración.
Creación de usuarios con permisos elevados.
Cambios en archivos del sitio fuera de una actualización.
Tráfico anormal hacia formularios o APIs.
Accesos a datos sensibles fuera del horario habitual.

Lista de verificación

Antes de dar por resuelto el monitoreo de tu empresa, revisá:

Que exista un inventario de sistemas, sitios y servicios críticos.
Que cada sistema crítico tenga un chequeo externo de disponibilidad.
Que se mida el tiempo de respuesta, no solo si responde.
Que los certificados SSL y los dominios tengan aviso de vencimiento.
Que el espacio en disco tenga alertas con margen suficiente.
Que los backups se monitoreen y se prueben restaurándolos.
Que las tareas programadas avisen si no se ejecutan.
Que los logs estén centralizados y tengan retención definida.
Que los logs no guarden contraseñas ni datos sensibles.
Que los errores de aplicación se registren y agrupen.
Que las integraciones tengan monitoreo de errores.
Que haya al menos un indicador de negocio vigilado.
Que cada alerta tenga un responsable.
Que las alertas estén clasificadas por urgencia.
Que se hayan probado los canales de aviso.
Que exista un procedimiento para responder incidentes.
Que los incidentes se documenten y revisen.
Que se revisen periódicamente las alertas que no generan acción.
Que el monitoreo se actualice cuando cambian los sistemas.
Que el equipo sepa dónde mirar cuando algo falla.

Enterarse primero es una ventaja

Ningún sistema es perfecto. Los discos se llenan, los certificados vencen, las integraciones cambian y el tráfico crece cuando menos se espera.

La diferencia entre un susto y una crisis suele estar en quién se entera primero. Si es el equipo, hay tiempo para actuar. Si es el cliente, el daño ya empezó.

El monitoreo y la observabilidad no requieren grandes inversiones para empezar. Requieren decidir qué es importante, medirlo de forma continua y tener a alguien atento a las señales.

En Soup IT ayudamos a empresas a mantener sus sistemas y sitios funcionando: configuramos monitoreo de disponibilidad, rendimiento, backups y vencimientos, centralizamos logs y definimos alertas útiles. Podemos acompañar con soporte y mantenimiento continuo de desarrollos a medida, sitios web e infraestructura, propia o en la nube.

Si tu empresa se entera de los problemas por los clientes o no sabe bien qué pasa dentro de sus sistemas, podemos revisar tu situación y convertirla en un plan concreto de monitoreo y soporte, con etapas, prioridades y costos realistas. Escribinos por WhatsApp o a contacto@soupit.ar.

Además, podés visitar Soup IT y seguirnos en LinkedIn e Instagram para encontrar más contenidos sobre soporte, monitoreo, desarrollo de software, automatización, infraestructura y tecnología aplicada a empresas.