Cómo monitorizar recursos de hardware del sistema: Parte VI – Cómo generar trazabilidad de eventos y detección de posibles problemas

por | May 16, 2026 | DevOps, Linux, Monitorizacion | 0 Comentarios

Introducción

Hola Fronters 👋

Llegamos al sexto y último artículo de nuestra serie sobre monitorización de recursos de hardware en Linux. Hemos cubierto CPU, RAM, red, disco y logs. Ahora toca el paso final: correlacionar todos esos datos, generar trazabilidad de eventos y configurar detección temprana de problemas.

Un buen sysadmin no reacciona cuando el servidor ya se cayó. Un buen sysadmin anticipa, mide y actúa antes de que el problema impacte a los usuarios. Eso es exactamente lo que vamos a construir aquí.

1. Correlacionando datos: la foto completa

Cada métrica aislada cuenta solo una parte de la historia. Cuando tu CPU está al 100%, puede ser por un pico legítimo de tráfico, un proceso en loop infinito, o un ataque DDoS. La diferencia la hace la correlación.

Qué cruzar con qué

# Alta CPU + mucha red = probablemente tráfico legítimo
# Alta CPU + poca red + muchos swaps = fuga de memoria/proceso zombi
# Alta red + baja CPU = ataque DDoS o bottleneck de CPU
# Errores en kern.log + latencia en disco = disco muriendo
# Fallos en auth.log + alta CPU = ataque de fuerza bruta (fail2ban trabajando)

Script de correlación simple

Este script bash cruza datos de CPU, RAM, disco y logs en un solo reporte:

#!/bin/bash
# reporte-correlacion.sh - Reporte de correlación de métricas

echo "=== REPORTE DE CORRELACIÓN $(date) ==="

echo ""
echo "--- TOP 5 PROCESOS POR CPU ---"
ps aux --sort=-%cpu | head -6

echo ""
echo "--- MEMORIA RAM ---"
free -h | grep -E "Mem|Swap"

echo ""
echo "--- ESPACIO EN DISCO ---"
df -h | grep -E "^/dev|tmpfs"

echo ""
echo "--- I/O EN DISCO (top 5) ---"
iotop -b -n 1 -o 2>/dev/null || iostat -x 1 1 | tail -10

echo ""
echo "--- ERRORES EN LOGS (última hora) ---"
journalctl --since "1 hour ago" -p err --no-pager | tail -20

echo ""
echo "--- INTENTOS SSH FALLIDOS (última hora) ---"
journalctl -u sshd --since "1 hour ago" --no-pager | grep "Failed password" | wc -l

2. Alertas básicas con scripts + cron

No necesitas herramientas complejas para empezar. Un script bash + cron pueden salvar tu servidor.

Script de alerta de recursos

#!/bin/bash
# alerta-recursos.sh
THRESHOLD_CPU=80
THRESHOLD_MEM=90
THRESHOLD_DISK=85
EMAIL="admin@example.com"

# CPU load (promedio 1 min)
CPU_LOAD=$(awk '{print $1 * 100}' /proc/loadavg | cut -d. -f1)
if [ "$CPU_LOAD" -gt "$THRESHOLD_CPU" ]; then
    echo "⚠️ ALERTA: CPU al ${CPU_LOAD}%" | mail -s "ALERTA CPU" $EMAIL
fi

# Memoria RAM
MEM_USED=$(free | grep Mem | awk '{print ($3/$2) * 100.0}' | cut -d. -f1)
if [ "$MEM_USED" -gt "$THRESHOLD_MEM" ]; then
    echo "⚠️ ALERTA: RAM al ${MEM_USED}%" | mail -s "ALERTA RAM" $EMAIL
fi

# Disco
DISK_USED=$(df / | tail -1 | awk '{print $5}' | sed 's/%//')
if [ "$DISK_USED" -gt "$THRESHOLD_DISK" ]; then
    echo "⚠️ ALERTA: Disco al ${DISK_USED}%" | mail -s "ALERTA DISCO" $EMAIL
fi

# Errores críticos en logs
ERRORS=$(journalctl -p err --since "5 min ago" --no-pager | wc -l)
if [ "$ERRORS" -gt 0 ]; then
    journalctl -p err --since "5 min ago" --no-pager | mail -s "ERRORES CRÍTICOS" $EMAIL
fi

Programar con cron

# /etc/cron.d/monitoreo
# Ejecutar cada 5 minutos
*/5 * * * * root /usr/local/bin/alerta-recursos.sh

# Reporte horario de correlación
0 * * * * root /usr/local/bin/reporte-correlacion.sh > /var/log/reporte-horario.log

# Reporte diario con logwatch
0 6 * * * root /usr/sbin/logwatch --detail High --range today --mailto admin@example.com

# Rotar reportes diarios
0 7 * * * root find /var/log/reportes -name "*.log" -mtime +30 -delete

3. Introducción a herramientas de monitorización enterprise

Cuando tienes más de un servidor, los scripts manuales se quedan cortos. Aquí entra la monitorización centralizada.

Nagios / Icinga

El clásico de la monitorización. Usa plugins para checkear CPU, disco, servicios y hasta páginas web. Envía alertas por email/SMS.

  • Arquitectura: servidor central + agentes NRPE en los clientes
  • Ventaja: maduro, muchísimos plugins
  • Desventaja: configuración manual, interfaz antigua

Zabbix

Monitorización moderna con agentes ligeros, auto-descubrimiento de hosts y dashboards visuales.

  • Arquitectura: servidor Zabbix + agentes en cada host
  • Ventaja: auto-descubrimiento, alertas configurables, gráficos integrados
  • Desventaja: curva de aprendizaje media, consume recursos en el servidor

Prometheus + Grafana

El stack moderno por excelencia. Prometheus recolecta métricas vía exporters, Grafana las visualiza.

  • Arquitectura: Prometheus server + exporters (node_exporter, blackbox_exporter) + Grafana
  • Ventaja: flexible, escalable, dashboards hermosos, alert manager potente
  • Desventaja: requiere conocimiento de PromQL
# Instalación rápida de node_exporter + Prometheus + Grafana
# 1. Node Exporter (en cada servidor)
wget https://github.com/prometheus/node_exporter/releases/latest/download/node_exporter-*.tar.gz
tar xzf node_exporter-*.tar.gz && sudo ./node_exporter/node_exporter &

# 2. Prometheus server
wget https://github.com/prometheus/prometheus/releases/latest/download/prometheus-*.tar.gz
tar xzf prometheus-*.tar.gz && cd prometheus-*
./prometheus --config.file=prometheus.yml &

# 3. Grafana (dashboard web)
sudo apt install -y grafana
sudo systemctl start grafana-server

4. Dashboard simple con Bash + HTML

Antes de saltar a herramientas complejas, puedes tener un dashboard funcional en 10 líneas:

#!/bin/bash
# dashboard.sh - Genera un dashboard HTML simple
OUTPUT="/var/www/html/dashboard.html"

cat > $OUTPUT << EOF
<!DOCTYPE html>
<html>
<head><title>Dashboard ITFrontech</title>
<meta http-equiv="refresh" content="60">
<style>
  body { font-family: monospace; background: #0a0a0a; color: #00ff00; padding: 20px; }
  .card { background: #1a1a2e; border: 1px solid #00ff00; padding: 15px; margin: 10px 0; }
  .ok { color: #00ff00; } .warn { color: #ffff00; } .crit { color: #ff0000; }
</style></head>
<body>
<h1>📊 Dashboard - $(date)</h1>
<div class="card">
<pre>$(uptime)</pre>
<pre>$(free -h)</pre>
<pre>$(df -h | grep -E "^/dev")</pre>
<pre>$(ss -tlnp | head -10)</pre>
</div></body></html>
EOF

echo "Dashboard generado: $OUTPUT"

Programa con cron para que se actualice cada minuto:

* * * * * root /usr/local/bin/dashboard.sh

5. Trazabilidad: el registro de eventos como evidencia

La trazabilidad no es solo para debugging. Es para auditoría, cumplimiento normativo y análisis forense.

Buenas prácticas de trazabilidad

  • Centraliza logs: Usa rsyslog para enviar logs de todos los servidores a un Logstash o servidor central
  • Timestamp en UTC: Evita confusiones con zonas horarias
  • Retención definida: 30-90 días según normativa
  • Firma de logs: Usa logger con tags personalizados para identificar eventos
  • Logs de aplicaciones: Formato JSON estructurado para facilitar parsing
# Ejemplo: registrar eventos personalizados con logger
logger -t "MONITOREO" -p local0.info "CPU al 95% en servidor web-01"
logger -t "MONITOREO" -p local0.warning "Disco /dev/sda1 al 88% - programar limpieza"

# Búsqueda posterior
journalctl -t "MONITOREO" --since "7 days ago"
grep "MONITOREO" /var/log/syslog

6. Detección temprana de problemas

La clave de un buen monitoreo no es detectar fallos, es detectar tendencias antes de que se conviertan en fallos.

Patrones de alerta temprana

# Tendencias de CPU (promedio móvil simple)
# Si el uso de CPU sube 10% cada día durante 3 días seguidos → escalar

# Crecimiento de logs
# Si /var/log crece 500MB/día → ajustar logrotate

# Errores incrementales
# Si los errores en journalctl suben 20% semanal → investigar

# Fragmentación de disco
# Tiempo de I/O creciente (iostat -x) → planear migración de disco

# Conexiones simultáneas crecientes
# ss -s mostrando增长 semanal → evaluar escalabilidad

Script de detección de tendencias

#!/bin/bash
# tendencias.sh - Detecta tendencias anómalas
LOG_FILE="/var/log/tendencias.log"
CPU_NOW=$(awk '{print $1 * 100}' /proc/loadavg | cut -d. -f1)

# Comparar con el promedio de la última semana
if [ -f "$LOG_FILE" ]; then
    AVG_WEEK=$(tail -1008 "$LOG_FILE" | awk '{sum+=$1} END{print sum/NR}')
    THRESHOLD=$(echo "$AVG_WEEK * 1.5" | bc | cut -d. -f1)
    if [ "$CPU_NOW" -gt "$THRESHOLD" ] 2>/dev/null; then
        echo "🚨 TENENCIA ANÓMALA: CPU actual $CPU_NOW% vs promedio semanal ${AVG_WEEK}%"
    fi
fi

echo "$(date +%s) $CPU_NOW" >> "$LOG_FILE"

Conclusión final de la serie

Hemos recorrido un camino completo: desde entender qué es la CPU y cómo medirla, pasando por memoria RAM, red, disco, logs, hasta llegar aquí: trazabilidad y detección temprana de problemas.

Lo más importante que debes llevarte:

  1. Monitorear no es opcional — es parte del trabajo de todo sysadmin
  2. Empieza simple — scripts bash + cron te llevan lejos
  3. Correlaciona — una métrica aislada no cuenta la historia completa
  4. Sé proactivo — detecta tendencias antes de que sean crisis
  5. Escala cuando crezcas — Prometheus + Grafana cuando tengas más de 5 servidores

La monitorización no es un proyecto, es una cultura. Implementa estos principios, ajústalos a tu realidad y verás cómo tus servidores te lo agradecen. 🚀

¡Nos vemos en el próximo artículo, Fronters! 💪