Monitorización de disponibilidad: Cómo evitar tiempos de inactividad con uptime monitoring

6.803 dólares por segundo. Parece lo que gana Jeff Bezos y no iríamos desencaminados, porque fueron las pérdidas de Amazon durante un corte de servicio de la CDN Fastly el 8 de junio de 2021. Poco más de 1 hora, 32 millones menos, porque cada segundo de downtime son ventas perdidas, trabajo interrumpido y clientes frustrados que se marchan para no volver. De ahí la importancia de implementar un uptime monitoring, o monitorización de disponibilidad, en nuestra infraestructura tecnológica.
Hoy, todo es más veloz que nunca, pero sigue sin haber nada más rápido que la impaciencia de los usuarios, y nada tan eterno como una hora sin documentos, chats o aplicaciones de trabajo, mientras ves marchar los euros por el desagüe.
Errores siempre habrá, la diferencia es la mitigación, que comienza por detectar instantáneamente cualquier anomalía. Por eso, he aquí una guía completa sobre uptime monitoring incluyendo: qué es, técnicas, herramientas, ejemplos, estrategias, criterios para elegir una buena solución y mucho más.

¿Qué es la monitorización de disponibilidad y por qué es esencial?

La monitorización de disponibilidad (uptime monitoring) es el sistema de vigilancia que asegura que nuestros servicios digitales, desde webs hasta APIs, servidores o Sistemas de Control Industrial, estén siempre operativos. En términos técnicos, es un conjunto de protocolos y herramientas que verifican, de forma automatizada y constante, la salud de los componentes de la infraestructura IT.
Esto permite:

• Detectar fallos en tiempo real antes de que los usuarios los noten.
• Prevenir el downtime de servicios mediante alertas proactivas.
• Garantizar el cumplimiento de nuestro Service Level Agreement (SLAs), como por ejemplo, un uptime del 99.99%.

En la práctica, esto funciona mediante el establecimiento de chequeos programados que evalúan:

• La conectividad de red. Es decir, ¿responde el servidor a pings?
• La funcionalidad de servicios. ¿La API devuelve los datos esperados al hacerle peticiones?
• La accesibilidad de aplicaciones y funcionamiento correcto, como que el certificado SSL de la web sea válido.

Por ejemplo, si una empresa usa Kubernetes, el uptime monitoring no solo verifica que los nodos estén activos, sino que pods críticos, como un servicio de autenticación, estén ejecutándose correctamente.

El impacto del downtime, mucho más que números

El costo de una caída de servicio va más allá de las pérdidas económicas directas. Por ejemplo:

• British Airways pagó 183 millones de libras de multa en 2017 tras 3 días de caída de su servicio, unidas a las pérdidas por no poder operar.
• En 2020, un fallo en AWS paralizó servicios y webs, poco antes del Black Friday, afectando indirectamente incluso a hospitales y logística.

Pero es que la interrupción de un servicio añade también un coste crítico difícil de cuantificar, el de la pérdida de confianza del cliente. Según datos, un 47% de los usuarios abandonan una web si tarda más de 2 segundos en cargar… Y el 80% no regresa tras una mala experiencia.
En este contexto, el uptime monitoring ya no es opcional, es lo mínimo para garantizar la continuidad en lo posible.
¿Y cómo empezamos?
La clave es combinar técnicas básicas, como ping al servicio, junto a otras más avanzadas, como monitorización de redes y experiencia de usuario y usuario web (UX y WUX), para crear una red de seguridad multicapa.
Veamos las principales técnicas a nuestra disposición para construirla.

Principales técnicas de uptime monitoring

Uno puede estar vivo, pero también agonizando. Por eso, la monitorización de disponibilidad no se limita a si un servidor responde. Debemos aplicar técnicas que, combinadas, detecten fallos en distintas capas de la infraestructura, empezando por la más básica.

Ping Monitoring (ICMP), los cimientos de la monitorización

Consiste en enviar paquetes ICMP a un dispositivo para verificar su conectividad básica. Esto identifica caídas totales o cortes en la red, si ese ping no recibe respuesta.
Pero, ¿y si nuestro WordPress no puede conectarse a su base de datos por un error de configuración? El ping nos dice que la página está viva, pero no que está enferma. Por eso, debemos implementar otras técnicas.
De lo contrario, monitorizar con ping puede convertirse en el meme del perro sentado ante una taza en medio de un incendio. El servidor dice “Everything is fine” si preguntamos, pero todo a su alrededor está en llamas.

HTTP/S Monitoring, el siguiente paso

Con esta técnica no solo hacemos que el servicio web responda, sino que lo haga con el código HTTP 200 OK y validez en los certificados SSL. Mientras sea así, aseguramos que los usuarios finales pueden acceder y usar la página web o API.
Esto resuelve, por ejemplo, que nuestra tienda Woocommerce haya dado un error 500 en el Black Friday, porque la ley de Finagle siempre se cumple («Todo lo que pueda ir mal, irá mal en el peor momento»).
En este caso, podríamos combinar también con monitorización sintética, simulando transacciones reales, comprobando que funcionan bien y optimizando la experiencia de usuario.

DNS Monitoring, garantizando la resolución del dominio

Esta técnica supervisa la resolución de DNS y tiempos de propagación, evitando que nuestro dominio resulte inalcanzable por configuración errónea, ataques DNS poisoning, etc.
Imaginemos que un banco se ha fusionado con otro y, en esas labores, es necesario actualizar DNS, pero hay un error de registros MX que provoca que los clientes no puedan acceder a su banca online.
Herramientas como monitorización DNS, con alertas por cambios no autorizados o fallo en las resoluciones avisaría de lo ocurrido.

TCP/UDP Monitoring, vigilando los puertos clave

Esta técnica verifica la accesibilidad y el rendimiento de puertos específicos en una red. Así aseguramos que los servicios dependientes de protocolos TCP (HTTP, SMTP, FTP…) y UDP (streaming de vídeo, VoIP…) estén operativos.
Por ejemplo, un hospital accede a historiales médicos de manera segura mediante el puerto 443, pero el becario (siempre es el becario) ha reconfigurado el firewall y bloqueado el puerto sin darse cuenta. Una monitorización TCP/UDP lo detectaría instantáneamente mediante una alerta y no después, mediante los gritos de los médicos.
Aquí es donde vemos la importancia de soluciones que integren monitorización de infraestructura IT.

SNMP Monitoring, el «perro guardián» de la red

Otra técnica en nuestro arsenal es la monitorización mediante el Simple Network Management Protocol (SNMP), que vigila la red, avisando de cualquier problema o comportamiento inusual. Esto se consigue recopilando datos de routers, switches, o dispositivos IoT mediante este protocolo.
¿La impresora se ha conectado a Internet y está mandando gigas de datos a un servidor extraño? Seguro que es «totalmente normal» (no, no lo es), pero una monitorización SNMP lo detectaría. Implementar esta técnica evita quebraderos de cabeza, así que aquí hay una guía para configurar SNMP.
Una buena estrategia de uptime monitoring debe combinar estas técnicas según las necesidades técnicas y operativas de nuestra organización. De este modo no caeremos en la situación de que el ping diga «todo bien», mientras la API de transacciones online está de huelga y ni nos enteramos.
El objetivo final es asegurar el cumplimiento del nivel de servicio (Service Level Agreement o SLA), por lo que conviene profundizar un poco más en este término y otros relacionados.

SLA, SLO, SLI y su relación con la monitorización de uptime

Aunque trabajemos con máquinas, lo hacemos para personas, y estas requerirán de nosotros garantías de servicio, dado lo catastrófico de cada segundo de downtime.
Aquí es donde entran todas estas siglas con las que debemos estar familiarizados:

• SLA (Service Level Agreement).Especifica el nivel mínimo de servicio que garantizamos a un cliente. Por ejemplo, que el uptime de una web sea del 99,00%. De lo contrario, pueden establecerse compensaciones por incumplimiento. Aquí tienes una guía SLA para saber todo lo necesario.
• SLO (Service Level Objective): Si lo anterior es el compromiso externo con clientes, este es el interno de eficiencia que nos ponemos como meta. Obviamente, el SLO debe ser más ambicioso que el SLA para asegurar que cumplimos este último con cierto margen de maniobra. Siguiendo el ejemplo, si prometemos 99,00% de uptime en el SLA, podemos poner un SLO de 99,90%, actuando cuando nuestro sistema de monitorización de disponibilidad diga que no alcanzamos el SLO. Eso garantiza cumplir el SLA y tener un precioso margen de maniobra para hacerlo.
• SLI (Service Level Indicator): Esta métrica mide nuestro cumplimiento del SLO. En uptime, el SLI suele ser el porcentaje de tiempo operativo.

La relación entre los tres conceptos es clara:
El SLI mide el SLO y el SLO, interno y más estricto que el SLA, asegura el cumplimiento de este último.

Cómo impacta el uptime monitoring en los SLA

Hay un documental fascinante y multipremiado titulado Man on wire (2008). Este recrea la hazaña del equilibrista francés Philippe Petit, que en 1974 tendió ilegalmente un cable de funambulista entre las Torres Gemelas de Nueva York… y caminó por él de una a otra. Cada paso para avanzar era una gesta y un mínimo error o imprevisto significaba el final. El paseo fue agónico, 45 minutos para cruzar 8 veces los 400 metros que separaban las torres.
Fascinante, en serio, pero lo importante es que, con los SLA, estamos en una situación similar. Es muy complicado avanzar y raspar centésimas de SLAs y SLOs para ascender en esos indicadores, pero es muy fácil caer e incumplir en cuanto un downtime nos tire de la cuerda.
El uptime monitoring es la red de funambulistas, que verifica cumplimientos y avisa enseguida para mitigar la caída. Sin esa monitorización de disponibilidad:

• No podremos demostrar que alcanzamos el uptime prometido.
• Nos arriesgamos a multas o penalizaciones contractuales, como British Airways.
• Y sobre todo, perdemos credibilidad frente a clientes o socios, algo hecho de la misma porcelana que los jarrones caros, fácil de romper y casi imposible de recomponer cuando sucede.

Ejemplos de métricas clave de uptime y SLA

No existen las métricas perfectas, solo las más adecuadas para una organización según su actividad, pero es cierto que algunas son fundamentales en el uptime monitoring y el cumplimiento de SLAs, como estas:

Indicador	Cómo se mide	Impacto en SLA
Uptime (en %)	(Tiempo operativo / Tiempo total) × 100	Principal indicador para SLAs de disponibilidad.
MTTR (Mean Time to Repair)	Tiempo promedio en resolver incidentes.	Un MTTR alto = Mayores penalizaciones por downtime.
Latencia máxima	Tiempo de respuesta de un servicio (ej: <500 ms).	Si se supera, puede considerarse « downtime funcional» al hacer inservible un servicio.

En esta guía definitiva de SLA, SLO y SLI puedes profundizar sobre este tema.

Comparativa de herramientas de uptime monitoring

A la hora de elegir lo adecuado para nuestra situación, debemos preguntarnos si necesitamos una simple alarma para nuestra humilde web o un centro de mando y control completo, porque estamos obligados por SLAs con clientes.
De eso dependerá la herramienta que usemos, así que analicemos algunas opciones populares:

Herramientas especializadas (enfocadas solamente en uptime)

Herramienta	Ventajas	Desventajas	Adecuado para
Uptime Robot	– Gratis hasta 50 monitors. – Alertas por email, SMS e integraciones básicas.	– Sin métricas avanzadas (ej: WUX), solo básicas (ping, HTTPs…)	Proyectos personales y negocios que empiezan.
Uptime.com	– Monitorización básica y avanzada, como la transaccional (ej: flujos de login). – Buenos informes.	– Limitado en algunas integraciones, como tickets.	Empresas con SLAs estrictos.
Pingdom	– Monitorización avanzada (sintética y de usuario real). – API sencilla.	– El coste / prestaciones es algo más elevado que otras alternativas.	Comercios online con tráfico global.

Si en nuestro caso necesitamos ese centro de mando, debemos echar un vistazo a soluciones integrales, que combinan el uptime monitoring con otras métricas fundamentales. Especialmente, si estamos en organizaciones de envergadura o muy enfocadas en tecnología.
Veamos algunas opciones.

Soluciones integrales (combinación de uptime con otras métricas)

Herramienta	Ventajas	Desventajas	Adecuado para
Better Stack	– Páginas de status personalizables. – Ideal para equipos DevOps (APIs REST).	– Pocas opciones para redes on-premise. – Se encarece pronto con muchas webs.	Webmasters y Startups tecnológicas con infraestructura cloud.
ManageEngine	– Monitorización SNMP y de red integrada. – Alertas basadas en machine learning.	– Curva de aprendizaje elevada. – La implementación no es muy intuitiva.	Empresas con redes híbridas.
Datadog	– 500+ integraciones (AWS, Kubernetes…). – Monitorización sintética y real user (RUM).	– El coste por host y por mes puede encarecerse fácilmente. – Demasiado para necesidades simples.	Corporaciones con infraestructura multicloud.
Pandora FMS	–Todo en uno: uptime, WUX, SNMP, log analysis… – Escalable de pymes a grandes empresas.	– Requiere configuración inicial detallada.	Entornos complejos (ej: monitorización de redes + WUX).

Como vemos, hay diferencias clave entre herramientas especializadas de uptime y soluciones integrales como Pandora FMS, que podemos visualizar fácilmente.

	Herramientas Especializadas	Soluciones Integrales (Pandora FMS)
Profundidad	Verifican «si está online».	Analizan «cómo funciona» (ej: rendimiento de APIs, cuellos de botella en redes…).
Integraciones	APIs básicas.	Conectan también con CRM, ERP, herramientas de Business Intelligence,logs…
Coste	Baratas al inicio, pero escalan mal.	Mayor inversión inicial, ahorro posterior evitando múltiples herramientas.
Casos de uso	Blog personal, landing page…	Cualquier organización: tiendas online, hospitales, bancos…

Resumiendo, una herramienta de uptime es como comprar un termómetro para ver la salud de nuestra infraestructura y que avise de «fiebre», pero poco más y desconociendo qué la provoca. Soluciones como Pandora FMS son sistemas de diagnóstico completo, el «hospital» que muestra causas y no solo síntomas, para resolver cualquier eventualidad que ponga en peligro los SLAs.

Las limitaciones de medir solamente el uptime: el rol de la experiencia del usuario (UX/WUX)

Un uptime del 99,95% parece impresionante, pero imagina un centro médico con esa métrica en el que cada historial de paciente tarda 30 segundos en cargar. O un error parcial en una tienda online, que no carga el carrito de compra, por ejemplo.

Ahí se comprueba que el uptime se queda corto en escenarios reales, siendo crucial la monitorización de la experiencia de usuario (User Experience o UX y Web User Experience o WUX).
Medirla es un concepto amplio y humano, que va más allá de los números, pero que podemos aplicar mediante técnicas como:

• Pruebas sintéticas: Realizadas con scripts que imitan la acción del usuario, como reservar un vuelo o pagar una compra. Se pueden medir con prestaciones como la monitorización sintética de Pandora FMS.
• Alertas proactivas: Como cuantificar tiempos de carga de esos historiales médicos, notificando a IT antes de que lleguen los tickets furibundos.

Los indicadores técnicos no son nada frente a las experiencias humanas, es por eso que, si queremos tener éxito, el mínimo es ese uptime monitoring, pero es solo el primer paso de un viaje más largo.

Criterios para elegir la mejor solución de uptime monitoring

Como hemos comentado, no hay soluciones perfectas, sino soluciones que se adapten mejor a nuestras necesidades e infraestructura IT. Por eso, todo comienza con un análisis de esas dos vertientes:

• Necesidades. ¿Qué SLAs debemos cumplir? ¿Qué debemos garantizar que funcione para una experiencia de usuario que sea un deleite?
• Infraestructura. ¿Qué servicios deben estar disponibles para cumplir esa experiencia de usuario? ¿Qué soluciones de las que hemos visto son compatibles con nuestra IT? ¿Cómo se integran con otros sistemas de monitorización? ¿Podemos tener todo en un lugar con una sola herramienta como Pandora FMS (escenario ideal)?

Cómo vemos, la respuesta será diferente según cada organización y las mejores prácticas comienzan siempre por ponernos en el lugar de las personas a las que servimos (clientes y usuarios finales), para luego escoger la tecnología que permita proporcionar esa experiencia óptima.
Así, construiremos un sistema de uptime monitoring por capas que asegure que todo funciona como un reloj y que la aplicación de tickets está en silencio (pero no porque esté caída y no lo hayamos detectado…).