Tareas Críticas de Servidor a Automatizar con Python

Cuando montamos la infraestructura de La MIX Radio en nuestro Proxmox, nos dimos cuenta de que gestionar todo a mano era imposible.
Las tareas críticas de servidor a automatizar con Python empezaron a ser una necesidad cuando los fallos empezaron a ocurrir a las tres de la mañana.
No queremos estar pegados a la consola todo el día, pero tampoco podemos dejar que el flujo de audio se corte sin que nadie se entere.
Por eso, decidimos crear scripts que vigilen el sistema por nosotros.

Ese enfoque nos permitió pasar de un sistema reactivo, donde arreglamos cosas cuando ya fallaron, a uno proactivo.
Esta transición es la diferencia entre dormir tranquilo o despertar con el foro lleno de quejas de oyentes. Al final, el objetivo es que el servidor se cure solo o, al menos, nos avise antes de que el problema sea grave.

El problema de la gestión manual en un homelab

El problema real aparece cuando tienes varias VMs y CTs corriendo procesos distintos.
Si el servicio de Icecast se detiene por un error de memoria, el servidor sigue encendido, pero la radio está muda.
Si dependemos de un monitoreo externo, a veces el aviso llega tarde.
Si lo hacemos manual, perdemos horas revisando logs que no dicen nada útil a simple vista.

Lo peor ocurre cuando el disco se llena por archivos de log mal configurados.
Un servidor con el disco al 100% deja de escribir bases de datos y empieza a corromper archivos.
En la práctica, esto significa que el bot de Telegram deja de funcionar y el stream de Electro Swing se corta abruptamente.
Sin automatización, el síntoma es el silencio y la solución es el pánico.

Qué necesitas antes de empezar

Para implementar estas soluciones en tu propio entorno, no necesitas un equipo industrial. Nosotros usamos lo siguiente en nuestro laboratorio en Benavente:

• Un servidor con Proxmox VE instalado.
• Una VM con Debian o Ubuntu (como nuestra VM 111).
• Python 3.x instalado en el sistema.
• Acceso SSH con permisos de sudo para ejecutar comandos de sistema.
• Un bot de Telegram configurado para recibir alertas en tiempo real.

Una vez que tienes el entorno listo, el siguiente paso es identificar qué procesos son los que más fallan en tu flujo de trabajo diario.

Cómo lo resolvimos, paso a paso

Para atacar las tareas críticas de servidor a automatizar con Python, creamos un script maestro que monitorea tres cosas: el estado del proceso Icecast, la disponibilidad de espacio en disco y el consumo de RAM de los contenedores.
En lugar de usar herramientas pesadas, preferimos scripts ligeros que se ejecuten cada cinco minutos mediante cron.

Primero, necesitamos un script que verifique si el proceso del servidor de streaming está vivo. Si el proceso no existe, el script intenta reiniciarlo y nos envía un aviso inmediato.

import os
import subprocess

# Verificamos si Icecast está corriendo en la VM 111
def check_icecast():
status = subprocess.run(['pgrep', 'icecast'], capture_output=True)
if status.returncode != 0:
print("Icecast caído. Reiniciando servicio...")
# Reiniciamos el servicio usando 
systemctl os.system('
sudo 
systemctl restart icecast2')
send_telegram_alert("Alerta: Icecast se cayó y fue reiniciado automáticamente.")
else:
print("Icecast está operando normalmente.")

Después de asegurar que la radio emita, el siguiente problema es el espacio en disco. Para evitar que los logs llenen el almacenamiento de Proxmox, implementamos una función que revisa la partición raíz y borra archivos temporales si superamos el 80% de uso.

import shutil

# Monitoreo de espacio en disco para evitar colapsos
def check_disk_space():
total, used, free = shutil.disk_usage("/")
percent_u
sed = (u
sed / total) * 100

if percent_u
sed > 80:
print(f"Espacio crítico: {
percent_u
sed }% usado. Limpiando logs...")
# Borramos logs antiguos en /var/log/ que terminen en .gz
os.system('
sudo find /var/log -type f -name "*.gz" -delete')
send_telegram_alert(f"Sistemas: Espacio en disco al {
percent_u
sed }%. Limpieza ejecutada.")

Finalmente, integramos todo esto con el bot de Telegram. No sirve de nada que la máquina se arregle sola si no sabemos que hubo un problema. Usamos la librería requests para enviar el mensaje al chat de administración de La MIX Radio.

import requests

# Función simple para notificar al equipo técnico
def send_telegram_alert(message):
token = "TU_TOKEN_DE_BOT"
chat_id = "TU_CHAT_ID"
url = f"https://api.telegram.org/bot{
token
}/sendMessage?chat_id={
chat_id
}&text={
message
}"

try:
requests.get(url)
except Exception as e:
print(f"Error enviando alerta: {
e
}")

Para que esto funcione sin nuestra intervención, programamos el script en el crontab del sistema. Así, cada 5 minutos, Python revisa la salud de la radio y el servidor sin que tengamos que mover un dedo.

Automatizar las tareas críticas de servidor a automatizar con Python no se trata de escribir el código más complejo, sino de resolver los fallos que más tiempo nos quitan durante la madrugada.

Errores que nos costaron tiempo

En el proceso de automatización, cometimos varios fallos que nos enseñaron lecciones importantes. El primero fue ejecutar el script de limpieza de logs como usuario normal; el script fallaba silenciosamente porque no tenía permisos para borrar en /var/log/.
La solución fue añadir el script al archivo sudoers con el tag NOPASSWD para ese comando específico.

El segundo error fue crear un bucle infinito de notificaciones. Configuramos el aviso de disco cada minuto y, como el disco seguía al 81% después de la limpieza, el bot de Telegram nos bombardeó con 60 mensajes por hora.
Lo resolvimos implementando un «tiempo de espera» o cooldown de 4 horas entre alertas similares.

El tercer fallo ocurrió al usar rutas relativas en Python. Cuando ejecutamos el script vía cron, el sistema no encontraba los archivos de configuración porque el directorio de ejecución era distinto.
Tuvimos que cambiar todas las rutas a rutas absolutas, como /home/lamix/scripts/config.json, para que el sistema siempre supiera dónde buscar.

Cómo saber que funciona

La mejor forma de verificar que la automatización es efectiva es provocando el fallo de forma controlada. Detenemos el servicio de Icecast manualmente con sudo systemctl stop icecast2 y esperamos cinco minutos.
Si recibimos el mensaje de Telegram y el proceso vuelve a aparecer en la lista de top o htop, la tarea está cumplida.

También llenamos un archivo temporal con datos basura hasta alcanzar el 85% de capacidad del disco.
Si el script detecta el límite y borra los archivos .gz antiguos, sabemos que la salud del servidor está protegida contra desbordamientos de log.

Qué sigue

Una vez que el servidor es estable, el siguiente paso es mover estas tareas a un flujo de trabajo más avanzado con n8n.
Podríamos conectar las alertas de Python a un tablero de control visual o incluso usar la IA de Gemma para analizar los logs y sugerir por qué se está cayendo el servicio antes de que nosotros lo analicemos.