Por qué el cliente se entera de la caída antes que la agencia
Sin vigilancia, la caída se descubre por el extremo equivocado: el cliente abre su sitio, ve un error y le escribe. El tiempo entre la caída y su reacción ya no lo mide usted, lo mide él. Por el contrario, una vigilancia mal ajustada fracasa de otro modo: diez alertas por semana de las que nueve son falsas, un canal que ya nadie lee y la caída real perdida entre el ruido.
El objetivo no es vigilarlo todo, sino saber tres cosas de cada sitio: si es accesible, si responde con el contenido correcto y si sus vencimientos (certificado, dominio) están lejos. A fin de mes aparece una segunda necesidad: el cliente pide una prueba de disponibilidad, y solo una medición continua y con marca de tiempo permite responder sin reconstruir la historia de memoria.
Tipos de sonda y qué detecta cada una
Desplace la tabla
| Sonda | Qué detecta | Qué no ve |
|---|---|---|
| HTTP (código de respuesta) | Servidor detenido, error 5xx, tiempo agotado, sitio inaccesible | Una página de error devuelta con código 200 |
| HTTP con palabra clave esperada | Página en blanco, mensaje de error de la aplicación, base de datos ausente, página de mantenimiento olvidada | Un defecto visual o una función rota más adelante en el recorrido |
| Certificado TLS | Certificado caducado o a punto de caducar, cadena incompleta, nombre de host incorrecto | Un sitio fuera de línea cuyo certificado sigue vigente |
| DNS | Registro A, AAAA o MX modificado o desaparecido, zona que ya no responde | Un servidor web caído detrás de un DNS correcto |
| Vencimiento del dominio | Dominio cerca de su fecha de vencimiento, renovación automática inactiva | El estado de salud del servidor |
| Latido de tarea programada | Copia de seguridad, cron o cola de mensajes que no se ejecutó en el plazo previsto | Una tarea que se ejecuta pero da un resultado erróneo |
La regla de confirmación: n comprobaciones antes de alertar
La mayoría de los falsos positivos son caídas de unos segundos: un reinicio de servicio, un corte de red en la sonda, un pico de carga. Una alerta lanzada al primer error despierta a alguien para nada. El remedio es una sola regla: declarar la caída solo tras n comprobaciones consecutivas fallidas, separadas por un intervalo corto.
El coste de esta regla es conocido y calculable: el retraso de detección es aproximadamente el intervalo multiplicado por n. Con una comprobación por minuto y tres fallos consecutivos, se alerta tras unos tres minutos. Para un sitio de presentación ese retraso es aceptable. Para una tienda en rebajas, se acorta el intervalo en lugar de suprimir la confirmación. Y una vez declarado el incidente, se sigue comprobando: el fin del incidente también se confirma con varios éxitos seguidos; si no, un sitio inestable genera una ráfaga de mensajes alternos.
Causas de falsos positivos que hay que eliminar
- Sonda única — una sola sonda en una sola red confunde su propio corte con el del sitio; dos ubicaciones independientes, o una segunda comprobación desde otro punto, lo resuelven.
- Tiempo de espera demasiado corto — un tiempo de respuesta fijado por debajo del tiempo de arranque de un WordPress en frío provoca una alerta en la primera visita tras un periodo tranquilo.
- Solo el código — un control limitado al código 200 no detecta la página en blanco, mientras que una palabra clave frágil (un eslogan que cambia) alerta en cada cambio editorial; elija un elemento estable, como el nombre de la marca en el pie de página.
- Redirecciones no seguidas — una redirección de http a https o del dominio raíz a www, mal gestionada por la sonda, se toma por un error.
- Protección contra robots — un cortafuegos de aplicaciones web o un límite de peticiones que bloquea la dirección de la sonda produce 403 recurrentes; autorice la dirección de la sonda en lugar de rebajar la protección del sitio.
- Mantenimiento no declarado — una actualización programada que corta el servicio unos minutos provoca una alerta y ensucia el informe del mes; se declara antes, véase más abajo.
Umbrales de partida orientativos, a ajustar por sitio
Desplace la tabla
| Parámetro | Valor de partida orientativo | Motivo |
|---|---|---|
| Intervalo de comprobación | 1 minuto para un sitio crítico, 5 minutos para un sitio de presentación | Cuanto más corto el intervalo, más rápida la detección, pero mayor la carga de la sonda |
| Fallos antes de alertar | 3 comprobaciones consecutivas | Filtra cortes de unos segundos sin retrasar la detección más de unos minutos |
| Tiempo máximo de respuesta | De 10 a 30 segundos según el sitio | Pasado ese tiempo, el visitante ya se ha ido |
| Éxitos antes de cerrar el incidente | 2 comprobaciones consecutivas | Evita las ráfagas de mensajes de apertura y cierre en un sitio inestable |
| Alerta de vencimiento del certificado | 30, 14 y 7 días antes del vencimiento | Deja tiempo para entender por qué falló la renovación automática |
| Alerta de vencimiento del dominio | 60 y 30 días antes del vencimiento | Recuperar un dominio caducado cuesta más que una caída de servidor |
Poner en marcha la vigilancia de una cartera
Elaborar el inventario de sitios
Liste cada sitio con su dirección, su alojamiento, la fecha de vencimiento de su dominio y un contacto del lado del cliente. Sin este inventario es imposible decir qué sitio no está vigilado.
Elegir una palabra clave estable por sitio
Abra la página de inicio y elija un texto presente en todas las respuestas normales, por ejemplo el nombre de la marca. Compruébelo a mano con
curl -s https://your-domain.com | grep -c "Nombre de la marca".Medir a mano la respuesta de un sitio
Antes de configurar la sonda, anote el código y el tiempo de respuesta con
curl -s -o /dev/null -w "%{http_code} %{time_total}\n" https://your-domain.com. Ese tiempo de referencia sirve para fijar el plazo máximo.Controlar el certificado
Lea la fecha de fin de validez con
echo | openssl s_client -connect your-domain.com:443 -servername your-domain.com 2>/dev/null | openssl x509 -noout -enddatey active la sonda de certificado con los umbrales de la tabla.Controlar el DNS
Anote los valores esperados con
dig +short A your-domain.comydig +short MX your-domain.com, y haga que la sonda DNS avise ante cualquier diferencia.Ajustar intervalo y confirmación
Aplique los valores de partida de la tabla y déjelo funcionar una semana. Una alerta falsa se corrige tratando su causa, nunca desactivando la sonda.
Vincular cada sonda a un canal
Asocie las alertas críticas a un canal que despierte a alguien y los avisos a un canal que se lea durante el día, como se detalla más abajo.
Ventanas de mantenimiento y canales de alerta
Una ventana de mantenimiento es un tramo horario declarado de antemano durante el cual las caídas de un sitio no disparan alerta. Cumple dos funciones: proteger a su guardia y seguir visible en el informe, donde el periodo se cuenta aparte en lugar de ocultarse. Una ventana bien llevada indica el sitio, la hora de inicio, la hora de fin y el motivo. No la prolongue por costumbre: una ventana abierta de forma permanente es una vigilancia apagada.
En cuanto a los canales, separe lo urgente de lo informativo. Una caída confirmada de un sitio de producción va a un canal que suena, por ejemplo una mensajería de equipo con notificación móvil o una llamada de guardia. Un certificado a 14 días del vencimiento va a un canal que se lee cada mañana, como un buzón de correo compartido o un hilo dedicado. Prevea también un segundo destinatario: una alerta leída por una sola persona falla el día de sus vacaciones.
Rompa la sonda antes de fiarse de ella
Una sonda que nunca ha alertado no está probada. En un sitio de pruebas, cambie a propósito la palabra clave esperada o detenga el servicio web, y compruebe tres cosas: el retraso antes de la alerta coincide con el cálculo intervalo por n, el mensaje llega al canal correcto y el cierre se dispara al volver el servicio. Repita esta prueba tras cada cambio de sonda o de canal.
El informe mensual: lo que el cliente lee en dos minutos
El cliente no lee un registro de eventos. Quiere saber, en una página, si su sitio aguantó, qué pasó cuando no lo hizo y qué ha cambiado usted desde entonces. Un informe útil cabe en una página y se genera a partir de las mismas mediciones que disparan sus alertas, sin retoques manuales: un informe retocado pierde su valor como prueba.
El cálculo de la disponibilidad medida es deliberadamente sencillo: los minutos en que el sitio respondió, divididos por los minutos del periodo, tras restar las ventanas de mantenimiento declaradas. A modo de ilustración solamente, 22 minutos de indisponibilidad en un periodo de 43 200 minutos suponen cerca de un 0,05 % de tiempo perdido. Es un ejemplo de cálculo, no un compromiso: indique siempre el método junto al resultado y no prometa nunca una cifra por adelantado.
Modelo de informe mensual
Desplace la tabla
| Apartado | Contenido | Ejemplo |
|---|---|---|
| Periodo y alcance | Fechas de inicio y fin, sitio, sondas activas, intervalo de comprobación | Del 1 al 30 del mes, página de inicio y página de contacto, comprobación cada 5 minutos |
| Disponibilidad medida | Porcentaje calculado, minutos de indisponibilidad, método de cálculo | 22 minutos sobre 43 200, mantenimiento declarado excluido |
| Incidentes con marca de tiempo | Inicio, fin y duración de cada incidente | El día 12, de 02:14 a 02:36, es decir, 22 minutos |
| Causa | Origen establecido, o mención explícita de que sigue siendo desconocido | Reinicio de un servicio tras una actualización de seguridad |
| Acciones realizadas | Lo que se corrigió o se decidió | Reinicio programado ahora situado fuera del horario de apertura |
| Ventanas de mantenimiento | Tramos declarados, descontados del cálculo, con su motivo | El día 20, de 03:00 a 03:30, actualización del sistema |
Disponibilidad medida por la agencia y SLA del proveedor: dos nociones distintas
El informe de la agencia mide lo que ve un visitante: si el sitio respondió, con el contenido correcto, desde el exterior. El SLA del proveedor de alojamiento es un compromiso contractual sobre la infraestructura, con sus propias definiciones, exclusiones y condiciones de compensación. Ambos pueden diferir sin que nadie mienta: una aplicación que se bloquea mientras el servidor sigue funcionando no cuenta contra el proveedor, pero sí contra el sitio.
Por tanto, no presente nunca su medición como la garantía del proveedor, ni al revés. En el informe, diga qué se midió, con qué sonda y desde qué punto. Si un incidente procede de la infraestructura, adjunte la solicitud enviada al proveedor y su respuesta, y lea las condiciones de su compromiso antes de prometer una compensación a su cliente. Este reparto claro de responsabilidades protege también la relación: usted documenta, no promete en lugar de un tercero.
Cuando la cartera crece
Con cinco sitios bastan una hoja de cálculo y unas pocas sondas. Con cincuenta, la dificultad pasa a ser la exhaustividad: un sitio olvidado, un dominio cuyo vencimiento nadie vigila, un contacto de cliente obsoleto. Nombre a un responsable del inventario, añada la creación de sondas a la lista de puesta en línea de cada proyecto nuevo y cruce cada mes la lista de sitios vigilados con la de contratos.
Las sondas de disponibilidad responden a la pregunta «¿funciona el sitio?». Complementan, sin sustituirlas, la supervisión de recursos del servidor y la auditoría de seguridad mensual: un disco lleno, una memoria saturada o una actualización atrasada son causas de caída que conviene ver venir en lugar de constatar.
La documentación oficial
Manual de curl: https://curl.se/docs/manpage.html
Comando openssl s_client: https://docs.openssl.org/master/man1/openssl-s_client/
Comando openssl x509: https://docs.openssl.org/master/man1/openssl-x509/
Herramienta dig: https://bind9.readthedocs.io/en/latest/manpages.html
Protocolo RDAP y fechas de vencimiento de un dominio: https://www.icann.org/rdap
Documentación de Uptime Kuma: https://github.com/louislam/uptime-kuma/wiki
