El sistema de citas de un centro de diagnóstico automotor de Cali, con tres sedes, se cayó un sábado en la mañana y estuvo caído 51 minutos. El aviso que le llegó a Wilmar Ospina entró a los 34 minutos y fue un cliente por teléfono. El servidor no se había reiniciado. Se quedó sin disco, la base de datos dejó de aceptar escrituras, y la aplicación reportó eso como un error al agendar y nada más.
Casi todo lo que hay que saber sobre servidores cabe en esa distancia entre la falla y el momento en que alguien se enteró. Un servidor no es un escritorio que se queda prendido. Es una máquina de la que alguien depende ahorita mismo sin estar en el cuarto, y la disciplina entera trata de qué pasa cuando se detiene.
Los tres números que merecen una alarma, y el que no
La carga del procesador es el número que todo el mundo grafica y casi nunca es el que arruina un sábado. Los tres que sí importan siempre son el espacio en disco, la presión de memoria y si el servicio está contestando.
Un disco al 90 por ciento es una alerta y un disco al 100 por ciento es una caída, y la distancia entre los dos puede ser una hora en una máquina ocupada o un mes en una tranquila, por eso la alarma tiene que sonar por la tendencia y no solo por el nivel. El disco de Cali llevaba nueve días arriba del 90 por ciento, y en cualquiera de esos nueve días la reparación habría sido rotar bitácoras en cinco minutos.
La revisión que lo habría agarrado de todos modos es la que hace la pregunta que hace un cliente. Vigilar lo que hace un usuario, no lo que reporta la máquina: una petición que agenda una cita de prueba cada minuto y avisa cuando falla habría sonado en el minuto uno y no en el 34. Las métricas de la máquina dicen por qué se rompió algo. Una revisión sintética dice que se rompió, y son dos trabajos distintos que la gente insiste en hacer con una sola herramienta.
La luz se va, y una UPS sin apagado automático solo retrasa el desastre
Este es el renglón que la versión escrita en inglés puede darse el lujo de mencionar de paso. Un servidor tiene que sobrevivir a un corte de luz con sus datos intactos, dice, y sigue adelante. Por acá el corte no es una hipótesis: es lo que pasó el mes pasado, y la sede del sur tiene el regulador quemado desde entonces.
Casi todo el mundo compra la UPS, que en México se pide como no-break, y ahí se detiene. Una UPS sin apagado automático solo retrasa la caída sucia diez minutos. La batería aguanta lo que aguanta, la luz no vuelve, el equipo se apaga de golpe igual, y una base de datos que se apaga a media escritura amanece con la tabla en un estado que nadie quiere revisar un domingo. La parte que falta cuesta cero pesos: conectar el cable de datos de la UPS al servidor e instalar el demonio que lo escucha, para que a los dos minutos de batería el sistema empiece un apagado ordenado por su cuenta.
La prueba de que quedó bien es una sola y hay que hacerla el día que se instala, no el día del corte: desconectar la UPS de la pared con el servidor prendido y cronometrar. Si a los dos minutos no empezó a apagarse solo, el cable está de adorno.
Leer la máquina cuando ya está molesta
Dos comandos contestan casi todo, y los dos ya están instalados.
df -himprime cada sistema de archivos con su uso en porcentaje, y el que está lleno rara vez es el que uno esperabajournalctl -p err -S -1himprime solo los errores de la última hora
df -h reporta por sistema de archivos, así que un disco lleno puede ser un solo directorio. Muchas máquinas vienen con volúmenes separados, y que el directorio de bitácoras se llene mientras el disco principal va en 40 por ciento es el caso normal y no la excepción. Mirar una sola cifra general es la manera de que un disco lleno siga invisible mientras la gráfica se ve sana.
En el otro extremo del parque de la región está el servidor virtual barato, con 25 gigabytes y un solo sistema de archivos, donde no hay volumen separado que confunda a nadie. Ahí el que llena el disco suele ser el respaldo: un volcado de la base de datos escrito todas las noches en la misma máquina que está respaldando. Un respaldo que llena el disco que protege es la falla más común de ese tamaño de servidor, y tiene el agravante de que además no sirve como respaldo, porque vive en la máquina que puede morirse.
Un sábado
La falla tardó un segundo y darse cuenta tardó 34 minutos
Cinco momentos de una sola caída. Solo en los dos últimos alguien tocó el servidor.
- Nueve días antesEl disco pasa el 90 por cientoSin alarma configurada sobre ese volumen, y la cifra general todavía se lee cómoda
- 09:12El disco se llenaLa base de datos deja de aceptar escrituras y la aplicación reporta un error al agendar
- 09:46Llama un cliente34 minutos adentro, y este es el sistema de monitoreo que de verdad funcionó
- 09:58df -h nombra el volumenDoce minutos para encontrarlo, porque las gráficas de la máquina eran del número equivocado
- 10:03Bitácoras rotadas, vuelven las escriturasCinco minutos, que es lo que habría costado la reparación cualquiera de los nueve días
El espaciado no es proporcional y la forma es la afirmación: la reparación fueron cinco minutos y la caída fueron 51, y todo lo de en medio fue averiguar.
La otra mitad del tiempo arriba es el cambio que alguien hizo
La causa más grande de que un servidor deje de estar disponible no es el hardware ni un ataque. Es un cambio, desplegado por la misma gente que administra la máquina, en día hábil. Eso no es un argumento en contra de cambiar cosas; es un argumento para cambiarlas de manera que se puedan deshacer, y para no hacerlo un viernes a las cuatro.
La versión práctica es que un servicio debe arrancar limpio desde su archivo de configuración con un solo comando, y que ese archivo debe estar en control de versiones. Si volver al comportamiento de la semana pasada significa acordarse de qué se editó, la máquina no es recuperable, apenas sigue prendida. El programa que de verdad contesta las peticiones, y la configuración que decide cómo, son los servidores web.
Las diferencias con un escritorio son concretas y no filosóficas: no tiene pantalla, se espera que aguante un corte de luz con los datos completos, se actualiza en una fecha que alguien decidió y no cuando aparece un aviso, y varias personas tienen acceso administrativo. Cada una cambia cómo se arma, y juntas son la sustancia de qué hace un servidor. Los servicios que la gente nota a los minutos de caerse son el correo y los calendarios compartidos, y cuestan reputación de una manera que un sitio lento no, que es el argumento para tratar el correo y la colaboración como un escalón aparte con alarmas más apretadas. Dónde vive físicamente la máquina, y quién responde por la capa de abajo, es el alojamiento, y esa decisión determina qué se puede arreglar solo a las dos de la mañana.
Dónde se atora la gente
El atoro es el cansancio de alarmas y llega como a los seis meses del primer sistema de monitoreo. Alguien prende las alarmas por omisión, recibe cuarenta al día, aprende a ignorar el canal, y la que importaba llega a un cuarto que dejó de leer. Una alarma sobre la que nadie actúa es peor que ninguna, porque fabrica la creencia de que algo está siendo vigilado. El número correcto de alarmas en un parque chico es un puñado a la semana, y llegar ahí significa borrar la mayoría de lo que sugiere la herramienta, que se siente como negligencia y no lo es.
Antes de eso hay un atoro anterior y es de acá. En una empresa de tres sedes no hay guardia, hay una persona que además tiene otro trabajo. La alerta tiene que llegar donde la persona ya está mirando, y eso es WhatsApp. Un correo a las tres de la mañana no llega a nadie, una aplicación de guardia que nadie instaló tampoco, y el canal por el que ya entra todo lo demás sí. Alertmanager manda a un enlace web y del otro lado se pone un puente hacia WhatsApp o Telegram, que es media tarde de trabajo y es la diferencia entre tener monitoreo y tener gráficas. El costo de esa decisión hay que decirlo: el canal deja de ser solo personal, así que las alarmas tienen que ser pocas de verdad.
El segundo atoro es el parque de Windows, que se administra con herramientas completamente distintas y que quien viene de Linux suele tratar como un tema menor en lugar de un tema distinto. Es la mayoría del trabajo corporativo con servidores en la región, y Windows Server es una profesión completa.
Qué abrir en 2026
Para métricas, Prometheus con Grafana es lo estándar y los dos son gratis y de código abierto. Reemplazaron a Nagios y su generación, que revisaban si una cosa estaba arriba en lugar de registrar cómo se comportaba con el tiempo, y la diferencia importa exactamente en el caso de arriba: un nivel no dice nada que una tendencia no hubiera dicho nueve días antes. Alertmanager viene con Prometheus y es la pieza que decide a dónde sale el aviso.
Para bitácoras, journalctl ya está en la máquina y alcanza para un parque chico. Vale la pena montar un sistema central de bitácoras cuando hay más máquinas de las que uno puede entrar a mano, y no antes, porque el costo honesto de operarlo es una máquina más.
Para la luz, NUT habla con la UPS por el cable de datos y le ordena al sistema apagarse cuando la batería baja de un umbral. Es gratis y de código abierto, está en los repositorios de cualquier distribución, y reemplazó a confiar en que alguien va a estar ahí para apagar la máquina a mano. Sirve con equipos de las marcas que se consiguen en la región y es la única pieza de esta página que evita una falla que ninguna nube tiene.
Lo que ninguna herramienta compra es el documento: una página que diga qué revisar, en qué orden, para cada alarma, escrita por quien la arregló la vez pasada. De eso trata al final el monitoreo de servidores, y es la parte que no se compra. Las preguntas de abajo, sobre permisos y bitácoras, siguen siendo las de sistemas operativos, y las de más abajo todavía son redes de computadoras.
Queda una pregunta que este centro de diagnóstico ya se está haciendo: si la máquina no fuera suya, la luz sería problema de otro. Es cierto, y a cambio la factura llega en dólares y la contraseña de administrador queda en manos ajenas. Ese intercambio, renglón por renglón, es el cómputo en la nube.