Como especialista en sistemas Linux y observabilidad, una de las tareas más importantes es validar que nuestras herramientas de monitorización (Dynatrace, Grafana/Prometheus) funcionan correctamente y que las alertas se disparan cuando deben hacerlo. Para esto, stress-ng es la herramienta perfecta.
Instalación en Ubuntu Server
sudo apt update
sudo apt install stress-ng -y
Casos de Uso Prácticos
1. Saturar CPU al 100%
# 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 - El porcentaje debe acercarse al 100%
- Las alertas de CPU > 80% deberían dispararse
2. Consumir Memoria RAM
# 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_bytesbajando - Swap usage aumentando si se agota la RAM
- Alertas de memoria > 85% utilizadas
3. Aumentar el Load Average
# Generar carga combinada que eleva el load
stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 1G --timeout 5m
Qué observar:
- Métrica
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
4. Simular un Escenario Crítico Completo
# Este comando es ideal para pruebas de alertas críticas
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:
# 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
En Dynatrace, navega a:
- Infrastructure → Hosts → Selecciona tu servidor
- Observa en tiempo real los gráficos de CPU, Memory y Load
- Verifica en Problems si se generan eventos críticos
- Revisa Settings → Anomaly detection 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
- Verifica que las notificaciones lleguen (email, Slack, PagerDuty)
- Usa
--timeoutsiempre 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 estas pruebas controladas, garantizas que cuando surja un problema real, tu equipo será notificado a tiempo.
# Comando recomendado para prueba completa
stress-ng --cpu 0 --vm 2 --vm-bytes 70% --io 2 --timeout 5m --metrics
¿El resultado? Confianza total en tu monitorización y alertas bien calibradas.
Deja una respuesta