Stress-ng: Simulación de carga para validar tu monitorización básica

Como especialista en sistemas Linux y observabilidad, una de las tareas más importantes es validar que nuestras herramientas de monitorización funcionan correctamente y que las alertas se disparan cuando deben hacerlo. Una validación completa requeriría pruebas a varios niveles: carga de infraestructura, problemas de red, pruebas de aplicación, inyección de fallos, etc. Sin embargo, stress-ng es una herramienta muy útil para dar los primeros pasos: nos permite simular carga a nivel de infraestructura (CPU, memoria, disco, I/O) y verificar que Dynatrace o Grafana/Prometheus detectan y alertan correctamente ante esas condiciones.

Instalación en Ubuntu Server

bash

sudo apt update
sudo apt install stress-ng -y

Casos de Uso Prácticos

1. Saturar CPU al 100%

bash

# Estresar todos los cores durante 5 minutos
stress-ng --cpu 0 --cpu-load 100 --timeout 5m

# Estresar 4 cores específicos
stress-ng --cpu 4 --cpu-load 100 --timeout 2m

Qué observar en Grafana/Dynatrace:

  • Métrica node_cpu_seconds_total (Prometheus) o CPU usage en Dynatrace
  • El porcentaje debe acercarse al 100%
  • Las alertas de CPU > 80% deberían dispararse

2. Consumir Memoria RAM

bash

# Consumir 2GB de RAM
stress-ng --vm 1 --vm-bytes 2G --timeout 3m

# Consumir el 80% de la RAM disponible
stress-ng --vm 2 --vm-bytes 80% --timeout 5m

Qué observar:

  • Métrica node_memory_MemAvailable_bytes bajando
  • Swap usage aumentando si se agota la RAM
  • Alertas de memoria > 85% utilizadas

3. Estresar I/O de disco

bash

# Estresar I/O de disco
stress-ng --hdd 2 --hdd-bytes 1G --timeout 3m

Qué observar:

  • Métrica node_disk_io_time_seconds_total (Prometheus) o Disk I/O en Dynatrace
  • Latencia de escritura aumentando
  • Alertas de I/O si están configuradas

4. Aumentar el Load Average

bash

# Generar carga combinada que eleva el load
stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 1G --timeout 5m

Qué observar:

  • Métricas node_load1, node_load5, node_load15
  • El load promedio debería superar el número de cores
  • Alerta cuando load > número de cores × 1.5

5. Simular un Escenario Crítico Completo

bash

stress-ng --cpu 0 --cpu-load 95 \
          --vm 2 --vm-bytes 75% \
          --io 4 \
          --timeout 10m \
          --metrics-brief

Validación en Prometheus/Grafana

Mientras ejecutas stress-ng, verifica estas queries en Prometheus:

promql

# CPU usage
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[1m])) * 100)

# Memoria disponible
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100

# Load average 1 minuto
node_load1

Verificación en Dynatrace

  1. Navega a Infrastructure → Hosts → selecciona tu servidor
  2. Observa en tiempo real los gráficos de CPU, Memory y Load
  3. Verifica en Problems si se generan eventos críticos
  4. Revisa Settings → Anomaly Detection → Infrastructure → Hosts para ajustar umbrales si es necesario

Buenas Prácticas

  • Ejecuta las pruebas fuera de horario productivo para evitar afectar servicios reales
  • Documenta los umbrales que deberían generar alertas antes de la prueba
  • Verifica que las notificaciones lleguen correctamente (email, Slack, PagerDuty)
  • Usa siempre --timeout para que el stress termine automáticamente

Conclusión

stress-ng es esencial para validar que tu stack de observabilidad funciona correctamente. No esperes a un incidente real para descubrir que tus alertas no funcionan. Con pruebas controladas y periódicas, garantizas que cuando surja un problema real, tu equipo será notificado a tiempo.

bash

# Comando recomendado para prueba completa
stress-ng --cpu 0 --vm 2 --vm-bytes 70% --io 2 --timeout 5m --metrics

Autor

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.