: Python; 08 Septiembre 2026

Cómo programar un monitor de servidores con Python: CPU, RAM, disco, servicios y alertas automáticas

Autor: Carlos Monje | Publicado: 08/09/2026

Python Lenguaje de Programación

Un monitor de servidores con Python permite detectar problemas antes de que se conviertan en caídas reales. Con pocas líneas bien organizadas puedes revisar CPU, memoria RAM, swap, disco, servicios críticos y enviar alertas automáticas cuando algo supera un umbral definido.

Python es ideal para este tipo de tareas porque cuenta con bibliotecas maduras como psutil, que permite obtener información de procesos y uso del sistema, incluyendo CPU, memoria, discos, red y sensores. Además, la biblioteca estándar incluye módulos como smtplib para enviar correos SMTP y logging para registrar eventos en archivos.

Idea central: el objetivo no es reemplazar a Prometheus, Zabbix o Wazuh, sino crear un monitor liviano, entendible y adaptable para servidores pequeños, laboratorios, VPS, proyectos internos o alertas rápidas de administración Linux.

1. Qué debe vigilar un monitor básico de servidores

Un monitor útil debe revisar los recursos que suelen causar incidentes: CPU alta, RAM agotada, swap excesiva, disco lleno, servicios caídos y errores repetidos. También debe evitar alertas duplicadas cada minuto, por lo que necesita un mecanismo de enfriamiento o cooldown.

Elemento	Qué revisar	Ejemplo de alerta
CPU	Porcentaje de uso promedio.	CPU superior a 85 %.
RAM	Uso de memoria física.	RAM superior a 90 %.
Disco	Uso por partición o punto de montaje.	/var o / supera 85 %.
Servicios	Estado de nginx, ssh, mariadb, docker, etc.	nginx.service no está activo.

2. Arquitectura del monitor

La arquitectura será sencilla: un script Python lee un archivo de configuración, revisa métricas del servidor, valida umbrales, genera logs, guarda estado de alertas y envía notificaciones por correo o webhook. Para ejecutarlo periódicamente, usaremos systemd timer, que permite activar servicios en intervalos mediante opciones como OnBootSec y OnUnitActiveSec.

Flujo lógico

Servidor Linux
   ↓
Script Python
   ↓
psutil: CPU, RAM, swap, disco
   ↓
systemctl: servicios críticos
   ↓
Evaluación de umbrales
   ↓
Logs + estado de alertas
   ↓
Correo SMTP o webhook
   ↓
Administrador recibe aviso

3. Preparar el entorno en Linux

El monitor se puede instalar en cualquier servidor Linux con Python 3. La única dependencia externa será psutil. Para evitar contaminar el sistema, conviene usar un entorno virtual.

Instalación base

# Debian / Ubuntu
sudo apt update
sudo apt install python3 python3-venv python3-pip

# RHEL / Rocky / AlmaLinux / Fedora

sudo dnf install python3 python3-pip

# Crear carpeta del monitor

sudo mkdir -p /opt/server-monitor
sudo mkdir -p /etc/server-monitor
sudo mkdir -p /var/lib/server-monitor
sudo mkdir -p /var/log/server-monitor

# Crear entorno virtual

cd /opt/server-monitor
sudo python3 -m venv venv
sudo /opt/server-monitor/venv/bin/pip install --upgrade pip
sudo /opt/server-monitor/venv/bin/pip install psutil

4. Crear el archivo de configuración

El archivo de configuración define umbrales, discos vigilados, servicios críticos y métodos de alerta. Para simplificar, usaremos JSON, soportado por la biblioteca estándar de Python mediante funciones como json.load y json.dump.

/etc/server-monitor/config.json

{
  "server_name": "web-01",
  "thresholds": {
    "cpu_percent": 85,
    "memory_percent": 90,
    "swap_percent": 50,
    "disk_percent": 85
  },
  "disk_paths": ["/", "/var", "/home"],
  "services": [
    "ssh.service",
    "nginx.service",
    "mariadb.service",
    "docker.service"
  ],
  "alerts": {
    "cooldown_minutes": 30,
    "email_enabled": true,
    "webhook_enabled": false
  }
}

Los secretos no deben ir en este JSON. Las credenciales de correo, tokens o URLs privadas deben almacenarse en variables de entorno o en un archivo protegido por permisos restrictivos.

5. Crear el script principal del monitor

Este script revisa CPU, RAM, swap, disco y servicios systemd. Usa psutil.cpu_percent, psutil.virtual_memory y psutil.disk_usage, funciones documentadas por psutil para consultar uso del sistema.

/opt/server-monitor/monitor.py

#!/usr/bin/env python3

import json
import logging
import os
import smtplib
import socket
import subprocess
import time
import urllib.request
from email.message import EmailMessage
from logging.handlers import RotatingFileHandler
from pathlib import Path

import psutil

CONFIG_FILE = Path("/etc/server-monitor/config.json")
STATE_FILE = Path("/var/lib/server-monitor/state.json")
LOG_FILE = Path("/var/log/server-monitor/monitor.log")

def setup_logging():
LOG_FILE.parent.mkdir(parents=True, exist_ok=True)
logger = logging.getLogger("server-monitor")
logger.setLevel(logging.INFO)

```
handler = RotatingFileHandler(
    LOG_FILE,
    maxBytes=1_000_000,
    backupCount=5,
    encoding="utf-8"
)

formatter = logging.Formatter(
    "%(asctime)s %(levelname)s %(message)s"
)

handler.setFormatter(formatter)
logger.addHandler(handler)
return logger
```

logger = setup_logging()

def load_json(path, default):
try:
if not path.exists():
return default
with path.open("r", encoding="utf-8") as f:
return json.load(f)
except Exception as exc:
logger.error("No se pudo leer %s: %s", path, exc)
return default

def save_json(path, data):
try:
path.parent.mkdir(parents=True, exist_ok=True)
tmp = path.with_suffix(".tmp")
with tmp.open("w", encoding="utf-8") as f:
json.dump(data, f, indent=2, ensure_ascii=False)
tmp.replace(path)
except Exception as exc:
logger.error("No se pudo escribir %s: %s", path, exc)

def run_command(command, timeout=8):
try:
result = subprocess.run(
command,
capture_output=True,
text=True,
timeout=timeout,
check=False
)
return result.returncode, result.stdout.strip(), result.stderr.strip()
except subprocess.TimeoutExpired:
return 124, "", "Tiempo de espera agotado"
except Exception as exc:
return 1, "", str(exc)

def check_service(service_name):
code, stdout, stderr = run_command(
["systemctl", "is-active", service_name],
timeout=5
)

```
return {
    "service": service_name,
    "active": stdout == "active",
    "status": stdout or stderr or "unknown",
    "returncode": code
}
```

def collect_metrics(config):
disk_paths = config.get("disk_paths", ["/"])
services = config.get("services", [])

```
metrics = {
    "hostname": socket.gethostname(),
    "timestamp": int(time.time()),
    "cpu_percent": psutil.cpu_percent(interval=1),
    "memory_percent": psutil.virtual_memory().percent,
    "swap_percent": psutil.swap_memory().percent,
    "disks": {},
    "services": []
}

for path in disk_paths:
    try:
        usage = psutil.disk_usage(path)
        metrics["disks"][path] = {
            "total_gb": round(usage.total / 1024**3, 2),
            "used_gb": round(usage.used / 1024**3, 2),
            "free_gb": round(usage.free / 1024**3, 2),
            "percent": usage.percent
        }
    except Exception as exc:
        metrics["disks"][path] = {
            "error": str(exc)
        }

for service in services:
    metrics["services"].append(check_service(service))

return metrics
```

def build_alerts(metrics, config):
thresholds = config.get("thresholds", {})
server_name = config.get("server_name", metrics["hostname"])

```
cpu_limit = thresholds.get("cpu_percent", 85)
mem_limit = thresholds.get("memory_percent", 90)
swap_limit = thresholds.get("swap_percent", 50)
disk_limit = thresholds.get("disk_percent", 85)

alerts = []

if metrics["cpu_percent"] >= cpu_limit:
    alerts.append({
        "key": "cpu_high",
        "level": "WARNING",
        "message": f"[{server_name}] CPU alta: {metrics['cpu_percent']}% >= {cpu_limit}%"
    })

if metrics["memory_percent"] >= mem_limit:
    alerts.append({
        "key": "memory_high",
        "level": "WARNING",
        "message": f"[{server_name}] RAM alta: {metrics['memory_percent']}% >= {mem_limit}%"
    })

if metrics["swap_percent"] >= swap_limit:
    alerts.append({
        "key": "swap_high",
        "level": "WARNING",
        "message": f"[{server_name}] Swap alta: {metrics['swap_percent']}% >= {swap_limit}%"
    })

for path, data in metrics["disks"].items():
    if "error" in data:
        alerts.append({
            "key": f"disk_error_{path}",
            "level": "ERROR",
            "message": f"[{server_name}] No se pudo revisar disco {path}: {data['error']}"
        })
        continue

    if data["percent"] >= disk_limit:
        alerts.append({
            "key": f"disk_high_{path}",
            "level": "WARNING",
            "message": f"[{server_name}] Disco alto en {path}: {data['percent']}% >= {disk_limit}%"
        })

for service in metrics["services"]:
    if not service["active"]:
        alerts.append({
            "key": f"service_down_{service['service']}",
            "level": "CRITICAL",
            "message": f"[{server_name}] Servicio caído: {service['service']} estado={service['status']}"
        })

return alerts
```

def filter_by_cooldown(alerts, config):
cooldown_minutes = config.get("alerts", {}).get("cooldown_minutes", 30)
cooldown_seconds = cooldown_minutes * 60
state = load_json(STATE_FILE, default={})
now = int(time.time())

```
filtered = []

for alert in alerts:
    key = alert["key"]
    last_sent = int(state.get(key, 0))

    if now - last_sent >= cooldown_seconds:
        filtered.append(alert)
        state[key] = now
    else:
        logger.info("Alerta en cooldown: %s", alert["message"])

save_json(STATE_FILE, state)
return filtered
```

def send_email(subject, body):
smtp_host = os.getenv("MONITOR_SMTP_HOST")
smtp_port = int(os.getenv("MONITOR_SMTP_PORT", "587"))
smtp_user = os.getenv("MONITOR_SMTP_USER")
smtp_password = os.getenv("MONITOR_SMTP_PASSWORD")
mail_from = os.getenv("MONITOR_MAIL_FROM")
mail_to = os.getenv("MONITOR_MAIL_TO")

```
if not all([smtp_host, smtp_user, smtp_password, mail_from, mail_to]):
    logger.error("Correo no enviado: faltan variables SMTP")
    return False

msg = EmailMessage()
msg["Subject"] = subject
msg["From"] = mail_from
msg["To"] = mail_to
msg.set_content(body)

try:
    with smtplib.SMTP(smtp_host, smtp_port, timeout=15) as server:
        server.starttls()
        server.login(smtp_user, smtp_password)
        server.send_message(msg)
    return True
except Exception as exc:
    logger.error("Error enviando correo: %s", exc)
    return False
```

def send_webhook(payload):
url = os.getenv("MONITOR_WEBHOOK_URL")

```
if not url:
    logger.error("Webhook no enviado: falta MONITOR_WEBHOOK_URL")
    return False

data = json.dumps(payload).encode("utf-8")
req = urllib.request.Request(
    url,
    data=data,
    headers={"Content-Type": "application/json"},
    method="POST"
)

try:
    with urllib.request.urlopen(req, timeout=15) as response:
        return 200 <= response.status < 300
except Exception as exc:
    logger.error("Error enviando webhook: %s", exc)
    return False
```

def notify(alerts, metrics, config):
if not alerts:
logger.info(
"OK cpu=%s ram=%s swap=%s",
metrics["cpu_percent"],
metrics["memory_percent"],
metrics["swap_percent"]
)
return

```
server_name = config.get("server_name", metrics["hostname"])
subject = f"[ALERTA] Monitor Linux - {server_name}"

lines = [
    f"Servidor: {server_name}",
    f"Hostname: {metrics['hostname']}",
    f"CPU: {metrics['cpu_percent']}%",
    f"RAM: {metrics['memory_percent']}%",
    f"Swap: {metrics['swap_percent']}%",
    "",
    "Alertas:"
]

for alert in alerts:
    lines.append(f"- {alert['level']}: {alert['message']}")
    logger.warning(alert["message"])

body = "\n".join(lines)

alert_config = config.get("alerts", {})

if alert_config.get("email_enabled", False):
    send_email(subject, body)

if alert_config.get("webhook_enabled", False):
    send_webhook({
        "subject": subject,
        "body": body,
        "alerts": alerts,
        "metrics": metrics
    })
```

def main():
config = load_json(CONFIG_FILE, default={})
metrics = collect_metrics(config)
alerts = build_alerts(metrics, config)
alerts_to_send = filter_by_cooldown(alerts, config)
notify(alerts_to_send, metrics, config)

if **name** == "**main**":
main()

El script usa RotatingFileHandler para evitar que el archivo de log crezca sin límite. Python documenta este manejador como parte de logging.handlers, con soporte para rotación de archivos en disco.

6. Proteger permisos y ejecutar una prueba

Una vez creado el script, asigna permisos adecuados. El monitor necesita leer métricas y consultar servicios, pero no debe tener permisos de administrador para modificar el servidor.

Permisos y prueba manual

sudo chmod +x /opt/server-monitor/monitor.py
sudo chmod 644 /etc/server-monitor/config.json

# Ejecutar una prueba

sudo /opt/server-monitor/venv/bin/python /opt/server-monitor/monitor.py

# Ver logs

sudo tail -n 50 /var/log/server-monitor/monitor.log

Recomendación: empieza con umbrales moderados y revisa varios días de comportamiento normal. No pongas alertas demasiado sensibles, porque terminarás ignorándolas.

7. Configurar alertas por correo

Python incluye smtplib, que permite crear una sesión cliente SMTP para enviar correos. La documentación oficial recomienda construir el mensaje con el paquete email y enviarlo con métodos como send_message.

Crea un archivo de variables de entorno separado. No guardes contraseñas dentro del script.

/etc/server-monitor/monitor.env

MONITOR_SMTP_HOST=smtp.tuempresa.com
MONITOR_SMTP_PORT=587
MONITOR_SMTP_USER=Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.
MONITOR_SMTP_PASSWORD=CAMBIAR_CONTRASENA
MONITOR_MAIL_FROM=Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.
MONITOR_MAIL_TO=Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.

Proteger credenciales

sudo chown root:root /etc/server-monitor/monitor.env
sudo chmod 600 /etc/server-monitor/monitor.env

8. Configurar alertas por webhook

El webhook permite enviar alertas a sistemas externos: ChatOps, un endpoint interno, n8n, Node-RED, Slack, Mattermost, Discord, Telegram mediante un puente o una API propia. En el script usamos urllib.request, módulo estándar de Python para abrir URLs y realizar solicitudes HTTP.

Activar webhook en configuración

{
  "alerts": {
    "cooldown_minutes": 30,
    "email_enabled": true,
    "webhook_enabled": true
  }
}

Agregar URL del webhook al archivo de entorno

MONITOR_WEBHOOK_URL=https://ejemplo.tuempresa.com/webhook/monitor-linux

9. Ejecutar el monitor automáticamente con systemd

En servidores Linux modernos, systemd permite crear un servicio y un temporizador. La idea es que el servicio ejecute el script una sola vez y el timer lo dispare cada cierto intervalo.

/etc/systemd/system/server-monitor.service

[Unit]
Description=Monitor de servidor Linux con Python
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/server-monitor/monitor.env
ExecStart=/opt/server-monitor/venv/bin/python /opt/server-monitor/monitor.py
Nice=5

/etc/systemd/system/server-monitor.timer

[Unit]
Description=Ejecutar monitor de servidor cada 5 minutos

[Timer]
OnBootSec=2min
OnUnitActiveSec=5min
Unit=server-monitor.service
Persistent=true

[Install]
WantedBy=timers.target

Activar timer

sudo systemctl daemon-reload
sudo systemctl enable --now server-monitor.timer

# Ver estado

systemctl status server-monitor.timer --no-pager
systemctl list-timers --all | grep server-monitor

# Ejecutar manualmente

sudo systemctl start server-monitor.service

# Ver logs del servicio

journalctl -u server-monitor.service --since "1 hour ago" --no-pager

journalctl permite consultar registros del journal de systemd y filtrar por unidad, tiempo y otros campos, lo que facilita revisar ejecuciones del monitor y diagnosticar fallos.

10. Umbrales recomendados para empezar

Los umbrales dependen del tipo de servidor. Un servidor de base de datos puede usar mucha RAM de forma normal; un servidor web puede tener picos breves de CPU; un servidor de backups puede llenar disco temporalmente durante una ventana de copia. Por eso, los valores iniciales deben ajustarse con observación real.

Métrica	Umbral inicial	Comentario
CPU	85 %	Alertar si se mantiene alta de forma repetida.
RAM	90 %	En Linux, parte de la memoria se usa como caché; interpreta con cuidado.
Swap	50 %	Swap alta puede indicar falta de RAM o procesos pesados.
Disco	85 %	En /var, /tmp y bases de datos conviene ser más estricto.
Servicio caído	Inmediato	nginx, ssh, mariadb, docker o aplicación crítica.

11. Qué servicios conviene vigilar

No todos los servicios tienen la misma importancia. El monitor debe centrarse en los componentes que sostienen la operación del servidor.

Servicios típicos por tipo de servidor

Servidor web: nginx.service, apache2.service, php-fpm.service.
Base de datos: mariadb.service, mysql.service, postgresql.service.
Contenedores: docker.service, containerd.service.
Acceso remoto: ssh.service o sshd.service.
Correo: postfix.service, dovecot.service.
Monitoreo: wazuh-agent.service, node_exporter.service, grafana-server.service.

12. Mejoras recomendadas para una versión empresarial

El script anterior es una base. Para una empresa, conviene evolucionarlo hacia una solución con inventario, etiquetas por servidor, niveles de criticidad, dashboards y centralización.

Mejora	Beneficio
Etiquetas por servidor	Identificar ambiente, área, criticidad y responsable.
Alertas por severidad	Separar avisos informativos, advertencias y críticos.
Histórico de métricas	Detectar tendencias antes de una caída.
Integración con tickets	Crear incidencias automáticamente para seguimiento.
Centralización	Enviar eventos a un servidor principal, SIEM o dashboard.

13. Seguridad del monitor

Un monitor también puede convertirse en riesgo si se administra mal. No debe guardar contraseñas sin protección, no debe ejecutar comandos arbitrarios, no debe reiniciar servicios automáticamente sin reglas claras y no debe exponer un webhook público sin autenticación.

Controles mínimos

No ejecutar como root si no es necesario: consultar métricas no requiere privilegios completos.
Proteger secretos: archivo monitor.env con permisos 600.
No permitir comandos libres: nada de ejecutar instrucciones recibidas por webhook.
Limitar alertas: usar cooldown para evitar spam.
Registrar todo: errores, alertas enviadas, fallos de correo y servicios caídos.
Validar servicios: solo revisar servicios definidos en configuración.

14. Diagnóstico cuando no llegan alertas

Si el monitor no alerta, revisa primero systemd, logs del script, variables de entorno y conectividad SMTP o webhook.

Comandos de diagnóstico

# Ver timer
systemctl status server-monitor.timer --no-pager

# Ver última ejecución

journalctl -u server-monitor.service --since "24 hours ago" --no-pager

# Ver log propio

sudo tail -n 100 /var/log/server-monitor/monitor.log

# Probar manualmente con variables de entorno

sudo systemctl start server-monitor.service

# Confirmar servicios vigilados

systemctl is-active nginx.service
systemctl is-active ssh.service

15. Checklist de implementación

Checklist técnico

Instalar Python 3 y psutil.
Crear carpetas: /opt/server-monitor, /etc/server-monitor, /var/lib/server-monitor y /var/log/server-monitor.
Definir umbrales: CPU, RAM, swap y disco.
Listar servicios críticos: web, base de datos, SSH, contenedores y aplicación principal.
Configurar correo o webhook: sin poner secretos dentro del código.
Probar ejecución manual: confirmar métricas, logs y alertas.
Crear servicio systemd: ejecución oneshot.
Crear timer systemd: intervalo de 5 minutos o según criticidad.
Verificar logs: journalctl y archivo propio del monitor.
Ajustar umbrales: según comportamiento real del servidor.
Documentar: responsable, servidor, servicios vigilados y correo de alertas.

16. Errores comunes

Poner umbrales demasiado bajos y generar alertas inútiles.
No usar cooldown y enviar cientos de correos por el mismo problema.
Guardar contraseñas directamente en el script.
No revisar el log del propio monitor.
Vigilar servicios con nombres incorrectos.
Ejecutar el monitor como root sin necesidad.
No probar manualmente antes de activar el timer.
No verificar que el correo SMTP realmente permite envío desde el servidor.
Olvidar particiones importantes como /var, /home o discos de base de datos.
Creer que un script simple reemplaza una plataforma completa de observabilidad.

17. Preguntas clave

¿Puedo monitorear un servidor Linux solo con Python?

Sí. Con Python y psutil puedes leer CPU, memoria, swap, disco y procesos. Para servicios systemd, puedes consultar systemctl is-active desde el script y generar alertas si un servicio crítico cae.

¿Cada cuánto debe ejecutarse el monitor?

Para un VPS o servidor pequeño, cada 5 minutos es razonable. Para sistemas críticos, puede ser cada minuto, pero cuidando el cooldown para evitar spam. Para métricas históricas y dashboards avanzados conviene usar herramientas especializadas.

¿Es mejor cron o systemd timer?

Ambos funcionan, pero systemd timer se integra mejor con servicios, logs y control de estado. Además, permite activar unidades en intervalos usando opciones como OnBootSec y OnUnitActiveSec.

¿Debo reiniciar servicios automáticamente?

No al inicio. Primero alerta y registra. El reinicio automático puede ser útil, pero solo con reglas claras, límites, evidencias y exclusiones para evitar bucles de caída.

¿Este monitor reemplaza a Zabbix, Prometheus o Wazuh?

No. Es una solución ligera para aprendizaje, VPS, laboratorios o alertas simples. En empresas con muchos servidores, lo ideal es centralizar métricas, logs, eventos y tableros en una plataforma de observabilidad o seguridad.

Recomendamos

En resumen

Crear un monitor de servidores con Python es una excelente forma de aprender administración Linux, automatización y observabilidad básica. Con psutil puedes medir CPU, RAM, swap y disco; con systemctl puedes revisar servicios; con smtplib o webhooks puedes enviar alertas; y con systemd timer puedes ejecutar el control cada pocos minutos de forma ordenada.

La clave está en hacerlo con criterio: umbrales razonables, logs, cooldown, secretos protegidos, servicios bien definidos y pruebas antes de producción. Un monitor simple no reemplaza a una plataforma empresarial, pero puede evitar muchas caídas silenciosas y dar al administrador una alerta temprana cuando el servidor empieza a fallar.

Cierre editorial

Python permite convertir una necesidad diaria de administración Linux en una herramienta real: medir, comparar, registrar y alertar. Un buen servidor no solo debe estar funcionando; debe avisarte antes de fallar. Ese es el primer paso hacia una operación más profesional, preventiva y segura.

08 Septiembre 2026

Visto: 21

Rating:

( 0 Rating )