Cómo crear un sistema de alertas para servidores Linux: recibe avisos cuando falle un servicio, se llene el disco o aumente la CPU

Idea central: no basta con mirar el servidor cuando algo falla. Debes automatizar alertas para servicios caídos, disco lleno, CPU alta, memoria crítica, puertos cerrados, errores HTTP y backups que no se ejecutaron.

#!/usr/bin/env bash
set -Eeuo pipefail

UMBRAL="${1:-85}"
HOST="$(hostname -f 2>/dev/null || hostname)"
FECHA="$(date '+%Y-%m-%d %H:%M:%S')"

df -hP | awk -v u="$UMBRAL" 'NR>1 {
uso=$5
gsub("%","",uso)
if (uso >= u) {
print $6 " está al " uso "% (" $4 " libre)"
}
}' | while read -r linea; do
MENSAJE="ALERTA DISCO - $HOST - $FECHA - $linea"
echo "$MENSAJE"
logger "$MENSAJE"
done

Precaución: guarda tokens, chat IDs y webhooks en archivos con permisos restringidos. No subas credenciales a GitHub, tickets, capturas o documentación pública.

TELEGRAM_BOT_TOKEN="123456:CAMBIAR_TOKEN"
TELEGRAM_CHAT_ID="123456789"

#!/usr/bin/env bash
set -Eeuo pipefail

source /etc/alertas-linux.conf

enviar_telegram() {
local mensaje="$1"

curl -fsS -m 10 
-X POST "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" 
-d "chat_id=${TELEGRAM_CHAT_ID}" 
--data-urlencode "text=${mensaje}" 
>/dev/null
}

#!/usr/bin/env bash
set -Eeuo pipefail

source /etc/alertas-linux.conf

enviar_telegram() {
curl -fsS -m 10 
-X POST "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" 
-d "chat_id=${TELEGRAM_CHAT_ID}" 
--data-urlencode "text=$1" 
>/dev/null
}

UMBRAL="${1:-85}"
HOST="$(hostname -f 2>/dev/null || hostname)"

df -hP | awk -v u="$UMBRAL" 'NR>1 {
uso=$5
gsub("%","",uso)
if (uso >= u) print $6 " está al " uso "%, libre: " $4
}' | while read -r alerta; do
enviar_telegram "🚨 Disco crítico en $HOST: $alerta"
done

#!/usr/bin/env bash
set -Eeuo pipefail

UMBRAL="${1:-85}"
HOST="$(hostname -f 2>/dev/null || hostname)"

CPU_USO=$(LC_ALL=C top -bn2 -d 1 | awk -F'id,' '/Cpu/ {split($1,a,","); idle=a[length(a)]; gsub(/[^0-9.]/,"",idle)} END {printf "%.0f", 100-idle}')

if (( CPU_USO >= UMBRAL )); then
echo "ALERTA CPU: $HOST está usando ${CPU_USO}% de CPU"
ps aux --sort=-%cpu | head -n 10
fi

sudo nano /usr/local/sbin/alerta-systemd.sh

#!/usr/bin/env bash
set -Eeuo pipefail

UNIDAD="${1:-desconocida}"
HOST="$(hostname -f 2>/dev/null || hostname)"
FECHA="$(date '+%Y-%m-%d %H:%M:%S')"

MENSAJE="🚨 Servicio falló en $HOST: $UNIDAD - $FECHA"

logger "$MENSAJE"

# Opcional: enviar por Telegram usando la función anterior

if [[ -f /etc/alertas-linux.conf ]]; then
source /etc/alertas-linux.conf
curl -fsS -m 10 
-X POST "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" 
-d "chat_id=${TELEGRAM_CHAT_ID}" 
--data-urlencode "text=${MENSAJE}" 
>/dev/null || true
fi

sudo chmod +x /usr/local/sbin/alerta-systemd.sh
sudo nano /etc/systemd/system/[email protected]

[Unit]
Description=Enviar alerta por fallo de servicio %i

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/alerta-systemd.sh %i

sudo systemctl edit nginx

[Unit]
OnFailure=alerta-fallo@%n.service

[Service]
Restart=on-failure
RestartSec=10s

sudo systemctl daemon-reload
sudo systemctl restart nginx
systemctl status nginx --no-pager

sudo crontab -e

*/5 * * * * /usr/local/sbin/alerta-disco-telegram.sh 85 >> /var/log/alertas-linux.log 2>&1
*/5 * * * * /usr/local/sbin/alerta-cpu.sh 85 >> /var/log/alertas-linux.log 2>&1

30 2 * * * /usr/local/sbin/backup.sh && curl -fsS -m 10 --retry 5 -o /dev/null https://hc-ping.com/UUID-CAMBIAR

# Debian / Ubuntu
sudo apt update
sudo apt install monit

# RHEL / Rocky / AlmaLinux

sudo dnf install monit

check process nginx with pidfile /run/nginx.pid
  start program = "/bin/systemctl start nginx"
  stop program  = "/bin/systemctl stop nginx"
  if failed port 80 protocol http then restart
  if 3 restarts within 5 cycles then alert

check filesystem rootfs with path /
if space usage > 85% then alert
if space usage > 95% then exec "/usr/local/sbin/alerta-disco-telegram.sh 95"

check system servidor
if cpu usage > 85% for 5 cycles then alert
if memory usage > 90% for 5 cycles then alert

services:
  prometheus:
    image: prom/prometheus
    container_name: prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - ./alertas.yml:/etc/prometheus/alertas.yml:ro
    ports:
      - "9090:9090"
    restart: unless-stopped

alertmanager:
image: prom/alertmanager
container_name: alertmanager
volumes:
- ./alertmanager.yml:/etc/alertmanager/alertmanager.yml:ro
ports:
- "9093:9093"
restart: unless-stopped

node-exporter:
image: prom/node-exporter
container_name: node-exporter
network_mode: host
pid: host
restart: unless-stopped

global:
  scrape_interval: 15s
  evaluation_interval: 30s

rule_files:

* /etc/prometheus/alertas.yml

alerting:
alertmanagers:
- static_configs:
- targets:
- alertmanager:9093

scrape_configs:

* job_name: "linux"
  static_configs:

  * targets:

    * "localhost:9100"

groups:
  - name: alertas-linux
    rules:
      - alert: ServidorNoResponde
        expr: up == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Servidor no responde"
          description: "Prometheus no puede recolectar métricas de {{ $labels.instance }}."

```
  - alert: DiscoCasiLleno
    expr: (1 - (node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"})) * 100 > 85
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "Disco casi lleno"
      description: "Filesystem {{ $labels.mountpoint }} en {{ $labels.instance }} supera 85% de uso."

  - alert: DiscoCritico
    expr: (1 - (node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"})) * 100 > 95
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Disco crítico"
      description: "Filesystem {{ $labels.mountpoint }} en {{ $labels.instance }} supera 95% de uso."

  - alert: CPUAlta
    expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "CPU alta"
      description: "CPU superior a 85% durante 10 minutos en {{ $labels.instance }}."

global:
  resolve_timeout: 5m

route:
receiver: "webhook-alertas"
group_by: ["alertname", "instance"]
group_wait: 30s
group_interval: 5m
repeat_interval: 2h

receivers:

* name: "webhook-alertas"
  webhook_configs:

  * url: "http://servidor-alertas.local:8080/alertas"
    send_resolved: true

Paneles recomendados en Grafana

1. CPU: uso promedio, carga y procesos principales.
2. Memoria: RAM disponible, swap y presión de memoria.
3. Disco: uso por filesystem, I/O y crecimiento.
4. Red: tráfico entrante/saliente, errores y paquetes descartados.
5. Servicios: disponibilidad de endpoints y estado de aplicaciones.
6. Alertas: estado actual, severidad, historial y responsables.

docker volume create uptime-kuma

docker run -d 
--restart=always 
-p 127.0.0.1:3001:3001 
-v uptime-kuma:/app/data 
--name uptime-kuma 
louislam/uptime-kuma:2

# Ver servicios fallidos
systemctl --failed

# Revisar logs recientes del servicio

sudo journalctl -u nginx --since "30 minutes ago" --no-pager

# Ver errores del boot actual

sudo journalctl -p err -b --no-pager

# Ver puertos y procesos

sudo ss -tulpen

# Ver procesos que consumen más CPU

ps aux --sort=-%cpu | head -n 15

# Ver espacio por directorio

sudo du -xh /var | sort -h | tail -n 20

Buenas reglas para reducir ruido

1. Usa duración: CPU alta durante 10 minutos, no por 5 segundos.
2. Agrupa alertas: varias alertas del mismo servidor deben llegar juntas.
3. Define severidad: warning, critical y emergency no deben tratarse igual.
4. Agrega contexto: servidor, métrica, valor, umbral y comando de diagnóstico.
5. Evita repetición: usa repeat_interval o archivo de estado.
6. Envía al responsable correcto: no todas las alertas deben ir a todos.

Checklist técnico

1. Inventariar servicios críticos: web, base de datos, SSH, Docker, colas, backups y APIs.
2. Definir umbrales: disco, CPU, memoria, red, latencia y errores.
3. Elegir canal: correo, Telegram, Slack, webhook, SMS o sistema de guardia.
4. Crear alertas básicas: servicio caído, disco lleno y CPU alta.
5. Agregar logs: cada alerta debe dejar registro local.
6. Evitar repetición: agrupar, silenciar o espaciar alertas.
7. Probar fallos: detener un servicio de prueba y verificar aviso.
8. Documentar respuesta: qué hacer ante cada tipo de alerta.
9. Escalar arquitectura: pasar de Bash a Prometheus/Grafana cuando crezca el entorno.
10. Revisar mensualmente: ajustar umbrales y eliminar alertas inútiles.

• Configurar alertas que nadie recibe o nadie revisa.
• Enviar demasiados mensajes por el mismo problema.
• No diferenciar warning de critical.
• Alertar por picos breves de CPU sin duración mínima.
• No monitorear el propio sistema de monitoreo.
• No probar los avisos después de configurarlos.
• Guardar tokens de Telegram, Slack o SMTP en archivos públicos.
• Reiniciar servicios automáticamente sin investigar la causa.
• Medir solo disponibilidad y no recursos internos.
• No documentar el procedimiento de respuesta.

¿Cuál es la forma más simple de crear alertas en Linux?

La forma más simple es usar scripts Bash con cron y enviar mensajes por correo, Telegram o webhook. Es suficiente para empezar con alertas de disco, CPU y servicios básicos.

¿Qué uso para alertar cuando falla un servicio?

systemd permite usar OnFailure= para disparar una unidad cuando un servicio falla, y Restart=on-failure para reiniciar servicios bajo determinadas condiciones de error.

¿Prometheus sirve para monitorear servidores Linux?

Sí. Prometheus puede recolectar métricas de Node Exporter, y Node Exporter expone métricas de CPU, disco, red y filesystem útiles para alertas de infraestructura.

¿Monit puede reiniciar servicios automáticamente?

Sí. Monit puede monitorear procesos locales y tomar acciones ante errores, como reiniciar servicios o enviar alertas.

¿Uptime Kuma reemplaza a Prometheus?

No necesariamente. Uptime Kuma es muy útil para monitoreo de disponibilidad y notificaciones visuales; Prometheus es más fuerte para métricas internas, series de tiempo, alertas por umbrales y análisis histórico.

• Comandos básicos que debes aprender para administrar tu servidor Linux
• Guía completa de redes en Linux: comandos, diagnóstico, configuración y solución de problemas
• Cómo saber qué procesos se ejecutan en Linux: guía completa para identificar, controlar, detener procesos sospechosos
• Cómo saber qué programa está usando un puerto en Linux y solucionar conflictos de red paso a paso
• Cómo saber si tu Linux está bien protegido: 30 comprobaciones de seguridad que puedes realizar ahora mismo
• Cómo proteger un servidor Linux contra ataques DDoS: configuración, monitoreo y medidas de mitigación

Cierre editorial

Un servidor sin alertas es un servidor administrado a ciegas. Linux ofrece todas las piezas para evitarlo: scripts, systemd, logs, métricas, exporters, paneles y notificaciones. La diferencia entre una caída silenciosa y una respuesta profesional está en haber preparado las alertas antes del incidente.