La monitorización de la disponibilidad (uptime) de un sitio web responde una sola pregunta, una y otra vez: ¿está mi sitio web accesible ahora mismo? Un monitor solicita tu sitio según un calendario, registra lo que le devolvió y te avisa cuando la respuesta cambia. Esta guía explica cómo funciona, qué pueden y qué no pueden decirte los resultados y cómo decidir lo que necesitas.
Trata del método. Para las definiciones, consulta disponibilidad y tiempo de inactividad en el glosario. Para la configuración práctica, consulta Cómo monitorizar la disponibilidad de un sitio web.
Qué es la monitorización de la disponibilidad de un sitio web
La monitorización es un ciclo de cuatro partes:
- Comprobar. Un sistema ajeno a tu sitio web solicita una dirección que elegiste.
- Juzgar. Decide si la respuesta cuenta como correcta.
- Alertar. Si la respuesta es mala, avisa a las personas que indicaste.
- Registrar. Se guarda cada resultado, para que puedas mirar atrás.
Las dos primeras partes determinan lo útil que es el resto. Un monitor que comprueba la dirección equivocada, o que acepta las respuestas equivocadas, informará de calma mientras tus visitantes ven errores.
Por qué importa la disponibilidad
Cuando un sitio web es inaccesible, los visitantes no pueden comprar, iniciar sesión, leer ni contactar contigo. La mayoría de los propietarios se enteran de una caída por un cliente, un compañero o un pedido que no llega. Cada una de esas vías llega tarde y no te dice nada sobre cuándo empezó el problema.
La monitorización cambia dos cosas. Te enteras de un problema cuando empieza y conservas un registro de cuánto duró. El registro también es útil después: muestra si un problema es algo puntual o un patrón.
Cómo funciona la monitorización HTTP
La mayoría de los monitores de sitios web hablan HTTP, el mismo idioma que usan los navegadores. En cada comprobación, el monitor:
- Busca la dirección en el DNS.
- Abre una conexión y, en las direcciones
https://, una conexión segura TLS. - Envía una solicitud HTTP, normalmente
GET. - Lee el código de estado de la respuesta.
El código de estado es el veredicto. Un 200 dice que el servidor atendió la solicitud. Un 503 dice que el servidor está activo pero no puede atenderla. La ausencia total de respuesta, porque falló el DNS o se agotó el tiempo de espera de la conexión, también es un fallo.
Las redirecciones necesitan una regla. Si http://example.com envía a los visitantes a https://www.example.com, el monitor puede seguir la redirección y juzgar la respuesta final, o juzgar la propia redirección. UptimeWire sigue un número limitado de redirecciones y juzga la respuesta final: un estado final de 200 a 399 cuenta como disponible y cualquier otro estado cuenta como un fallo. Una cadena que nunca termina también es un fallo.
Qué mide realmente una comprobación
Una comprobación mide una solicitud a una dirección desde un lugar en un momento. Eso es más estrecho de lo que parece:
- Mide la dirección que le diste, no todo tu sitio web. Un monitor en la página de inicio no dice nada sobre
/checkout/. - Mide la respuesta, no lo que hace la página en un navegador. No se ejecutan scripts, imágenes ni widgets de terceros.
- Mide un momento. Lo que ocurrió entre comprobaciones es invisible.
La comprobación también registra cuánto tardó la respuesta. Consulta tiempo de respuesta para ver qué incluye esa cifra y por qué difiere entre herramientas.
Elegir un intervalo de monitorización
El intervalo es el tiempo entre comprobaciones. Un intervalo más corto encuentra los problemas antes, porque un fallo solo lo puede notar una comprobación que se ejecute mientras ocurre.
| Intervalo | Qué significa en la práctica |
|---|---|
| 1 minuto | Un problema se detecta en aproximadamente uno o dos minutos. Adecuado para sitios donde los minutos cuestan dinero. |
| 5 minutos | Un valor predeterminado razonable para la mayoría de los sitios de empresa. |
| De 15 a 30 minutos | Suficiente para sitios de poco tráfico donde una caída breve es tolerable. |
| 1 hora o más | Solo detecta caídas largas. Una caída breve puede pasar entre dos comprobaciones sin que se vea. |
Dos precauciones. Primera, el intervalo no es el tiempo de detección: la confirmación (siguiente sección) añade un poco. Segunda, más corto no siempre es mejor. Si una comprobación además desencadena un trabajo pesado en tu servidor, ejecútala con menos frecuencia o apúntala a una dirección más ligera.
Los planes limitan lo corto que puede ser un intervalo. En UptimeWire, el más corto es de 5 minutos en Free, de 3 en Starter y de 1 en Business y Agency.
Confirmar una caída
Las redes son ruidosas. Una sola solicitud puede fallar por un paquete perdido, una sobrecarga breve o un problema del lado del monitor, mientras el sitio está bien para todos los demás. Si cada comprobación fallida generara una alerta, aprenderías a ignorar las alertas.
La confirmación lo soluciona. El monitor repite una comprobación fallida, con una breve pausa entre ellas, y abre un incidente solo cuando los fallos continúan. UptimeWire funciona así y, cuando hay un segundo punto de observación disponible, también puede preguntarle a ese. Esto cuesta un poco de tiempo de detección, un precio justo por alertas en las que puedes confiar.
Note
La confirmación significa que una alerta no llega en el instante en que el sitio se rompe. El tiempo de detección depende del intervalo, de las comprobaciones repetidas y de lo rápido que la notificación llegue hasta ti. Ningún monitor puede prometer un tiempo exacto.
Monitorizar desde fuera
Hay dos grandes maneras de vigilar un sistema. El libro de SRE de Google las llama monitorización de caja negra y de caja blanca. La monitorización de caja negra prueba lo que un usuario puede ver, desde fuera. La monitorización de caja blanca lee las señales del propio sistema, como la carga de CPU, la memoria y los registros.
La monitorización de la disponibilidad de un sitio web es de caja negra. Esa es su fortaleza: ve lo que ven los visitantes, incluidos los fallos de los que tu propio servidor no puede informar, como una red inalcanzable o un registro DNS roto. También es su límite: te dice que algo va mal, no por qué.
Los dos enfoques se complementan. Las comprobaciones externas dicen «los visitantes no pueden llegar al sitio». Las métricas internas ayudan a explicar por qué.
Tiempo de respuesta
Un sitio lento es un sitio parcialmente roto. Seguir el tiempo de respuesta junto con la disponibilidad muestra los problemas antes de que se conviertan en una caída: una base de datos que empieza a sufrir, un despliegue que añadió una consulta lenta, un servidor corto de recursos.
Trata la cifra con cuidado. Es el tiempo de una solicitud simple, no el tiempo que tarda una página en ser utilizable en un navegador. Compárala con su propio historial y no con la cifra de otra herramienta.
Certificados, dominios y DNS
Un sitio web puede fallar sin que el servidor web tenga la culpa. Tres cosas distintas tienen que seguir funcionando:
- El certificado SSL/TLS. Cuando caduca, los navegadores muestran una advertencia a pantalla completa. Consulta Cómo evitar que caduque un certificado SSL.
- El registro del dominio. Si se pasa la renovación, el dominio deja de funcionar y puede perderse.
- La resolución DNS. Si el nombre ya no se resuelve, los visitantes no encuentran el servidor, por sano que esté.
Estos fallos ocurren despacio y luego de golpe. Necesitan comprobaciones propias, con su propio calendario, porque la comprobación HTTP no te avisará con antelación. Un certificado que caduca mañana todavía responde 200 hoy.
UptimeWire comprueba el certificado, la fecha de vencimiento del dominio y la resolución DNS de cada sitio web, por separado de la comprobación de disponibilidad. Los avisos de certificado, dominio y DNS salen por correo y por Telegram.
Historial de incidentes y páginas de estado
Un incidente es un período de fallo confirmado, desde la primera comprobación mala confirmada hasta la recuperación. Conservar un historial de incidentes responde preguntas que surgen más tarde: ¿cuándo empezó?, ¿cuánto duró?, ¿con qué frecuencia ocurre?
Una página de estado es una página pública que muestra a los visitantes si tu servicio funciona. Ahorra tiempo de soporte durante una caída y genera confianza después. Que la necesites depende de tu audiencia. Una tienda o un producto SaaS con clientes que esperan respuestas se beneficia. Un blog personal no.
Lo que la monitorización no puede hacer
Ten claros los límites, para que un panel tranquilo no se confunda con una prueba de que todo va bien.
- Un
200no es «funciona». Un servidor puede responder200mientras la base de datos está caída, el pago está roto o la página muestra un mensaje de error. Una comprobación de solicitud simple no puede verlo. Para detectarlo, el monitor necesita buscar algo concreto en la respuesta, o tienes que monitorizar una dirección más profunda, como un endpoint de estado. - Solo se vigilan las direcciones configuradas. Una dirección es una dirección. Monitorizar
example.comno cubreshop.example.comni/api/. Añade cada una que importe. - No sustituye a la monitorización interna. Te dice que el sitio está caído, no qué componente falló.
- No es una prueba contractual. Las cifras de una herramienta de monitorización son una estimación vista desde un único punto de observación. Sirven para tus propios registros, pero un acuerdo de nivel de servicio (SLA) define su propia forma de medir. Consulta SLA.
- Las comprobaciones muestrean el tiempo. Una caída de un minuto entre dos comprobaciones de cinco minutos puede no verse nunca.
Elegir qué monitorizar
Empieza por lo que más dolería si se rompiera, no por lo que es más fácil de comprobar.
- Haz una lista de las direcciones de las que dependen los visitantes. La página de inicio, la de inicio de sesión, el pago, un endpoint de API. Cada una puede fallar de forma independiente.
- Elige un intervalo para cada una. Cuanto más rápido crece el coste de una caída, más corto debe ser el intervalo.
- Decide a quién se avisa y cómo. El correo llega a todos; un canal de chat llega más rápido a la persona de guardia. Asegúrate de que la alerta va a alguien que la vea.
- Añade los fallos lentos. La caducidad del certificado, el vencimiento del dominio y el DNS deben estar en la lista.
- Decide si los visitantes necesitan una página de estado.
Una lista de comprobación práctica
- Cada dirección importante está monitorizada, no solo la página de inicio.
- La dirección monitorizada devuelve una respuesta significativa, no una genérica.
- El intervalo se ajusta a lo costosa que es una caída.
- Las alertas llegan a una persona que actuará.
- Las comprobaciones de certificado, dominio y DNS están activadas.
- Has probado que una alerta llega de verdad.
- Revisas el historial de incidentes de vez en cuando.
Cuando estés listo para configurarlo, Cómo monitorizar la disponibilidad de un sitio web te guía por los pasos en UptimeWire.