Cómo monitorizar la disponibilidad de un servidor: comprobaciones, herramientas y alertas

Para monitorizar la disponibilidad de un servidor (uptime), ejecute comprobaciones automáticas desde fuera del servidor (ping, puerto TCP o solicitudes HTTP desde varias ubicaciones), recoja las señales de salud del propio servidor con un agente y avise solo cuando varias ubicaciones fallan seguidas. Después registre cada caída para poder calcular cada mes la disponibilidad frente a su SLA.

Puntos clave

• Las comprobaciones sintéticas externas responden a «¿pueden llegar los usuarios?»; los agentes internos responden a «¿por qué está caído?». Necesita ambos.
• Compruebe desde al menos tres ubicaciones y avise tras fallos consecutivos para evitar falsas alarmas por una mala ruta de red. Microsoft recomienda al menos cinco ubicaciones de prueba para las pruebas de disponibilidad de Azure.
• Pruebe lo que usan los usuarios: una solicitud HTTPS que comprueba el código de estado y el contenido de la página vale más que un ping.
• Una disponibilidad del 99,9 % sigue permitiendo unos 43,8 minutos de caída al mes. Averigüe qué permite su objetivo antes de fijar los umbrales de alerta.
• Excluya de forma coherente las ventanas de mantenimiento acordadas e informe de la disponibilidad siempre con los mismos datos cada mes.

¿Qué es la monitorización de la disponibilidad de un servidor?

La monitorización de la disponibilidad de un servidor es la comprobación continua de si un servidor y los servicios que aloja son accesibles y responden correctamente. Produce dos cosas: alertas cuando algo se cae y un histórico que se puede convertir en un porcentaje de disponibilidad.

Uptime y disponibilidad están relacionados, pero no son idénticos. Un servidor puede estar encendido (uptime alto) mientras su servicio web devuelve errores (disponibilidad baja). Para la mayoría de las empresas, la cifra que importa es la disponibilidad del servicio tal como la ven los usuarios.

¿Cuánta caída permite cada objetivo de disponibilidad?

La disponibilidad es (tiempo total − tiempo de caída) ÷ tiempo total. La tabla convierte los objetivos habituales en tiempo de caída permitido, con un mes medio de 730 horas.

Un objetivo exigente cambia la forma de monitorizar. Con un 99,99 %, un intervalo de comprobación de cinco minutos ni siquiera puede detectar todos los incumplimientos, así que necesita comprobaciones cada minuto o más rápidas y una respuesta de guardia medida en minutos. El capítulo del libro de SRE de Google sobre asumir el riesgo explica por qué cada nueve adicional cuesta más y por qué el objetivo debe responder a la necesidad del negocio.

¿Qué comprobaciones debe ejecutar?

Comprobaciones externas (sintéticas)

• Ping ICMP: muestra que el host responde en la red. Es barato, pero muchos firewalls lo bloquean y un host puede responder al ping con sus aplicaciones caídas.
• Comprobaciones de puerto TCP: confirman que un servicio está escuchando, por ejemplo el 443 para HTTPS, el 3389 para RDP o el 5432 para PostgreSQL.
• Comprobaciones HTTP(S): solicitan una URL y comprueban el código de estado, el tiempo de respuesta y un fragmento de contenido esperado. Use un endpoint de salud específico que pruebe también la conexión a la base de datos.
• Comprobaciones de certificados TLS: avisan antes de que caduque un certificado. Un certificado caducado es una caída para los usuarios aunque el servidor esté sano.
• Comprobaciones de DNS: confirman que el nombre se resuelve a la dirección correcta.

Señales internas (basadas en agentes)

• Heartbeat: el agente informa cada minuto; la ausencia de heartbeat significa que el host o el agente están caídos.
• Contador de uptime del sistema: muestra reinicios no planificados. En Linux use uptime o last reboot; en Windows, el ID de evento 6008 del registro del sistema registra un apagado inesperado.
• Métricas de recursos: CPU, memoria, espacio en disco y latencia de disco. Los discos llenos y el agotamiento de la memoria son causas frecuentes de «activo pero sin funcionar».
• Estado de servicios y procesos: ¿se está ejecutando el servidor web, la base de datos o la tarea programada?

Para hosts Windows, nuestra guía sobre cómo monitorizar el rendimiento de Windows Server enumera los contadores que conviene recoger.

¿Qué herramientas pueden monitorizar la disponibilidad de un servidor?

La elección importa menos que la configuración. Una herramienta autoalojada también necesita monitorización: si su único servidor de monitorización está en el mismo rack que los servidores que vigila, un corte de energía se lleva a ambos. Ejecute al menos una comprobación externa desde otra red o desde un servicio en la nube.

Cómo configurar alertas de disponibilidad sin falsas alarmas

1. Use varias ubicaciones. Microsoft recomienda al menos cinco ubicaciones de prueba para las pruebas de disponibilidad de Azure y un umbral de alerta igual al número de ubicaciones menos dos, por ejemplo tres que fallen de cinco.
2. Exija fallos consecutivos. La opción de reintento de Azure notifica un fallo solo cuando fallan tres intentos sucesivos; Microsoft señala que alrededor del 80 % de los fallos desaparece al reintentar.
3. Fije la gravedad según el impacto. Un portal de clientes en producción avisa al ingeniero de guardia; un servidor de pruebas genera un ticket.
4. Dirija las alertas a quienes pueden actuar, con escalado si nadie las reconoce en un tiempo determinado.
5. Silencie el mantenimiento planificado en la herramienta de monitorización en lugar de ignorar las alertas por costumbre.
6. Avise también de la recuperación, para que el equipo sepa cuándo ha terminado el incidente.

La guía de SRE de Google sobre monitorización de sistemas distribuidos añade una regla útil: cada aviso debe ser urgente, accionable y requerir a una persona. Todo lo demás pertenece a un ticket o a un panel.

Cómo informar de la disponibilidad frente a un SLA

• Defina qué cuenta como caída, por ejemplo «el endpoint de salud falla desde tres de cinco ubicaciones en dos comprobaciones consecutivas».
• Acuerde qué ventanas de mantenimiento se excluyen y regístrelas en la herramienta.
• Calcule la disponibilidad mensual a partir de los resultados de las comprobaciones, no de la memoria ni de las notas de los tickets.
• Mantenga un registro de caídas con inicio, fin, causa y solución. Los patrones, como caídas tras cada noche de parches, muestran dónde invertir.
• Compare su cifra con lo que se compromete su proveedor de nube. Por ejemplo, el SLA de Amazon Compute se compromete a un 99,99 % de disponibilidad mensual para EC2 desplegado en varias zonas de disponibilidad de una región, pero solo a un 99,5 % para una única instancia EC2. La disponibilidad de su aplicación nunca puede superar la que ofrezca su dependencia más débil.

La monitorización le informa de las caídas; la redundancia las evita. Ejecute las cargas críticas en más de un servidor o zona de disponibilidad detrás de un balanceador de carga, para que un único fallo no tumbe el servicio. WorkBuster, una plataforma SaaS de selección de personal, funciona sobre EC2 detrás de un Application Load Balancer con MySQL RDS multi-AZ, un grupo de escalado automático y paneles y alarmas de CloudWatch; el caso de éxito de WorkBuster muestra la configuración completa.

Cómo ayuda Opsio

Opsio presta monitorización y respuesta a incidentes 24/7 para servidores y cargas en la nube de AWS, Azure y Google Cloud. Configuramos las comprobaciones, el enrutamiento de alertas y los informes mensuales de disponibilidad, y nuestros ingenieros actúan ante las alertas. Consulte nuestras páginas de servicios de monitorización y soporte en la nube, monitorización remota de infraestructura y observabilidad con Prometheus y Grafana.

Preguntas frecuentes

¿Cómo compruebo cuánto tiempo lleva en marcha un servidor?

En Linux, ejecute uptime o last reboot. En Windows, abra la pestaña Rendimiento del Administrador de tareas, ejecute systeminfo y lea «System Boot Time», o consulte el registro de eventos del sistema. Muestran el tiempo desde el último arranque, no si los servicios estuvieron disponibles.

¿Con qué frecuencia deben ejecutarse las comprobaciones de disponibilidad?

Cada uno a cinco minutos en la mayoría de los servicios de producción. Adapte el intervalo a su objetivo: con un 99,99 % solo tiene unos 4,4 minutos de caída al mes, así que un intervalo de cinco minutos es demasiado lento para medirlo.

¿Basta con el ping para monitorizar la disponibilidad de un servidor?

No. El ping solo demuestra que responde la pila de red. Añada una comprobación TCP o HTTPS contra el servicio del que dependen los usuarios, idealmente con una coincidencia de contenido, además de comprobaciones basadas en agentes en el propio servidor.

¿Qué porcentaje de disponibilidad es bueno para un servidor?

Para aplicaciones de negocio, el 99,9 % es un objetivo habitual; los servicios de cara al cliente suelen aspirar al 99,95 % o más. Los objetivos más altos exigen redundancia: AWS, por ejemplo, se compromete solo a un 99,5 % para una única instancia EC2, pero a un 99,99 % para EC2 repartido en varias zonas de disponibilidad.

¿Puedo monitorizar la disponibilidad gratis?

Sí. Las herramientas de código abierto como Prometheus con blackbox_exporter, Zabbix o Nagios no cuestan nada en licencias, aunque se paga en alojamiento y tiempo de mantenimiento. Las comprobaciones nativas de los proveedores de nube cuestan poco para un número reducido de endpoints.

Lecturas relacionadas

• What Is Cloud Monitoring
• ¿Qué es la monitorización de servidores y aplicaciones en tiempo real?
• ¿Cómo controlar el rendimiento del servidor Windows?