Setup completo para capturar autom\u00e1ticamente qu\u00e9 est\u00e1 causando %wa alto en un servidor Linux, con evidencia forense de cada pico.<\/p>\n\n\n\n
bash<\/p>\n\n\n\n
apt install -y sysstat iotop iptables-persistent<\/code><\/pre>\n\n\n\nsysstat<\/code> trae iostat<\/code>, vmstat<\/code>. iotop<\/code> para I\/O por proceso.<\/p>\n\n\n\n
\n\n\n\nPaso 1: Script del monitor principal<\/h3>\n\n\n\n
Crea \/usr\/local\/bin\/wa_monitor.sh<\/code>:<\/p>\n\n\n\nbash<\/p>\n\n\n\n
#!\/bin\/bash\n# Monitor de %iowait \u2014 captura evidencia cuando supera el umbral\n# Uso: wa_monitor.sh [umbral_wa] [intervalo_seg]\n\nTHRESHOLD=${1:-15}\nINTERVAL=${2:-5}\nLOG_DIR=\"\/var\/log\/wa_monitor\"\nCOOLDOWN=60\n\nmkdir -p \"$LOG_DIR\"\nLAST_CAPTURE=0\n\necho \"[$(date '+%F %T')] Monitor iniciado. Umbral=%wa>${THRESHOLD}, intervalo=${INTERVAL}s\"\n\nwhile true; do\n WA=$(top -bn2 -d1 | grep -E '^%Cpu' | tail -1 | awk -F'wa' '{print $1}' | awk '{print $NF}' | tr ',' '.')\n WA_INT=$(printf \"%.0f\" \"$WA\" 2>\/dev\/null || echo 0)\n NOW=$(date +%s)\n\n if [ \"$WA_INT\" -ge \"$THRESHOLD\" ]; then\n if [ $((NOW - LAST_CAPTURE)) -lt $COOLDOWN ]; then\n sleep \"$INTERVAL\"\n continue\n fi\n\n TS=$(date '+%Y%m%d_%H%M%S')\n OUT=\"$LOG_DIR\/pico_${TS}_wa${WA_INT}.log\"\n LAST_CAPTURE=$NOW\n\n {\n echo \"===== PICO DE IOWAIT =====\"\n echo \"Timestamp: $(date '+%F %T')\"\n echo \"%wa detectado: ${WA}%\"\n echo \"Uptime: $(uptime)\"\n echo\n echo \"===== TOP -bn1 (procesos activos) =====\"\n top -bn1 | head -30\n echo\n echo \"===== PROCESOS EN ESTADO D (esperando I\/O) =====\"\n ps -eo pid,stat,user,command | awk '$2 ~ \/D\/'\n echo\n echo \"===== IOSTAT -xz 2 3 (uso de disco) =====\"\n iostat -xz 2 3\n echo\n echo \"===== IOTOP -boPn3 (top de I\/O) =====\"\n iotop -boPqqqn3 2>\/dev\/null | head -40\n echo\n echo \"===== VMSTAT 2 5 =====\"\n vmstat 2 5\n echo\n echo \"===== WAZUH \/ NESSUS STATUS =====\"\n ps -ef | grep -E 'wazuh-syscheck|nessus' | grep -v grep\n echo\n echo \"===== TOP 10 PROCESOS POR MEMORIA =====\"\n ps -eo pid,user,%cpu,%mem,rss,command --sort=-%mem | head -11\n } > \"$OUT\" 2>&1\n\n # Dispara el snapshot de contexto en paralelo (opcional)\n [ -x \/usr\/local\/bin\/ws_snapshot.sh ] && \/usr\/local\/bin\/ws_snapshot.sh \"ws_snapshot\" > \/dev\/null 2>&1 &\n\n echo \"[$(date '+%F %T')] \u26a0 Pico capturado (wa=${WA}%) \u2192 $OUT\"\n fi\n\n sleep \"$INTERVAL\"\ndone<\/code><\/pre>\n\n\n\nbash<\/p>\n\n\n\n
chmod +x \/usr\/local\/bin\/wa_monitor.sh<\/code><\/pre>\n\n\n\nQu\u00e9 captura<\/strong>: en cada pico, un archivo pico_YYYYMMDD_HHMMSS_waN.log<\/code> con top, procesos bloqueados en I\/O, iostat, iotop, vmstat, estado de agentes de seguridad y top procesos por RAM.<\/p>\n\n\n\n
\n\n\n\nPaso 2: Script de snapshot complementario (contexto de aplicaci\u00f3n)<\/h3>\n\n\n\n
Crea \/usr\/local\/bin\/ws_snapshot.sh<\/code>. Este es un ejemplo para VS Code Remote \u2014 adaptalo al software que est\u00e9s investigando<\/strong> (procesos Java, contenedores Docker, workers de una app, etc.):<\/p>\n\n\n\nbash<\/p>\n\n\n\n
#!\/bin\/bash\n# Snapshot de contexto de aplicaci\u00f3n al momento del pico\n# Uso: ws_snapshot.sh [prefijo_archivo]\n\nPREFIX=\"${1:-workspaces}\"\nOUT=\"\/var\/log\/wa_monitor\/${PREFIX}_$(date +%Y%m%d_%H%M%S).log\"\n\n{\n echo \"===== Snapshot $(date '+%F %T') =====\"\n echo\n\n echo \"--- JDT Language Servers activos (adaptar patr\u00f3n seg\u00fan tu caso) ---\"\n ps -eo pid,rss,user,command | grep 'jdt_ws' | grep -v grep | while read pid rss user rest; do\n ws=$(echo \"$rest\" | grep -oP 'workspaceStorage\/\\K[a-f0-9-]+' | head -1)\n gb=$(awk \"BEGIN {printf \\\"%.2f\\\", $rss\/1024\/1024}\")\n printf \"PID %-7s | %5s GB | user=%s | ws=%s\\n\" \"$pid\" \"$gb\" \"$user\" \"$ws\"\n done\n echo\n\n echo \"--- Total RAM por procesos de inter\u00e9s ---\"\n ps -eo rss,command | grep 'jdt_ws' | grep -v grep | \\\n awk '{sum+=$1} END {printf \" %.2f GB\\n\", sum\/1024\/1024}'\n echo\n\n echo \"--- Estado de RAM y swap ---\"\n free -h\n echo\n\n echo \"--- Top 15 procesos por RAM residente ---\"\n ps -eo pid,user,%mem,rss,command --sort=-rss | head -16\n} > \"$OUT\" 2>&1\n\necho \"$OUT\"<\/code><\/pre>\n\n\n\nbash<\/p>\n\n\n\n
chmod +x \/usr\/local\/bin\/ws_snapshot.sh<\/code><\/pre>\n\n\n\nPersonalizaci\u00f3n<\/strong>: cambi\u00e1 el patr\u00f3n grep 'jdt_ws'<\/code> por lo que quieras trackear. Ejemplos:<\/p>\n\n\n\n\n- Contenedores Docker:
grep 'docker' | grep -v 'grep'<\/code> + agregar docker stats --no-stream<\/code><\/li>\n\n\n\n- Java apps:
grep 'java' | grep -v grep<\/code><\/li>\n\n\n\n- Procesos de un usuario:
ps -u <usuario><\/code><\/li>\n\n\n\n- PostgreSQL workers:
grep 'postgres'<\/code><\/li>\n<\/ul>\n\n\n\n
\n\n\n\nPaso 3: Servicio systemd (persistencia entre reboots)<\/h3>\n\n\n\n
Crea \/etc\/systemd\/system\/wa-monitor.service<\/code>:<\/p>\n\n\n\nini<\/p>\n\n\n\n
[Unit]\nDescription=I\/O Wait Monitor\nAfter=multi-user.target\n\n[Service]\nType=simple\nExecStart=\/usr\/local\/bin\/wa_monitor.sh 15 5\nRestart=on-failure\nStandardOutput=append:\/var\/log\/wa_monitor\/monitor.log\nStandardError=append:\/var\/log\/wa_monitor\/monitor.log\n\n[Install]\nWantedBy=multi-user.target<\/code><\/pre>\n\n\n\nLos dos n\u00fameros en ExecStart<\/code> son umbral %wa<\/strong> y intervalo de muestreo en segundos<\/strong>. Ajust\u00e1 seg\u00fan sensibilidad deseada (t\u00edpico: 15 5<\/code> para detecci\u00f3n temprana, 25 5<\/code> si hay ruido de fondo de scans de seguridad).<\/p>\n\n\n\nbash<\/p>\n\n\n\n
mkdir -p \/var\/log\/wa_monitor\nsystemctl daemon-reload\nsystemctl enable --now wa-monitor\nsystemctl status wa-monitor<\/code><\/pre>\n\n\n\n
\n\n\n\nPaso 4: Cron de limpieza autom\u00e1tica<\/h3>\n\n\n\n
bash<\/p>\n\n\n\n
crontab -e<\/code><\/pre>\n\n\n\nAgregar:<\/p>\n\n\n\n
0 3 * * * find \/var\/log\/wa_monitor -name 'pico_*.log' -mtime +7 -delete\n5 3 * * * find \/var\/log\/wa_monitor -name 'ws_snapshot_*.log' -mtime +7 -delete<\/code><\/pre>\n\n\n\nCorre a las 3 AM, borra archivos de m\u00e1s de 7 d\u00edas. Ajust\u00e1 +7<\/code> seg\u00fan cu\u00e1nto historial quieras conservar.<\/p>\n\n\n\n
\n\n\n\nComandos \u00fatiles para analizar<\/h3>\n\n\n\n
bash<\/p>\n\n\n\n
# Listar picos capturados, m\u00e1s recientes primero\nls -lth \/var\/log\/wa_monitor\/pico_*.log | head\n\n# Ver el pico m\u00e1s reciente\nsudo cat \"$(ls -t \/var\/log\/wa_monitor\/pico_*.log | head -1)\"\n\n# Ver un pico espec\u00edfico y su snapshot correspondiente (por timestamp)\nTS=20260921_1019\nsudo cat \/var\/log\/wa_monitor\/pico_${TS}*.log\nsudo cat \/var\/log\/wa_monitor\/ws_snapshot_${TS}*.log\n\n# Ordenar picos por valor de wa (los peores primero)\nls \/var\/log\/wa_monitor\/pico_*.log | sort -t'wa' -k2 -n -r | head\n\n# Ver heartbeat del monitor\ntail -f \/var\/log\/wa_monitor\/monitor.log\n\n# Espacio consumido\ndu -sh \/var\/log\/wa_monitor\/<\/code><\/pre>\n\n\n\n
\n\n\n\nGlosario de programas que consumen recursos<\/h3>\n\n\n\n
Sospechosos frecuentes cuando ves %wa<\/code> alto o carga inexplicable en un servidor Linux:<\/p>\n\n\n\nKernel \/ sistema<\/strong><\/p>\n\n\n\n\nkswapd0<\/code><\/strong> \u2014 daemon de swap del kernel. Si aparece al 100% de CPU, es swap thrashing<\/strong>: RAM llena, kernel paginando entre disco y memoria. La causa ra\u00edz es siempre falta de RAM.<\/li>\n\n\n\nkworker\/*<\/code><\/strong> \u2014 threads de trabajo del kernel. Actividad alta suele indicar drivers de disco\/red trabajando duro.<\/li>\n\n\n\njbd2\/dm-0-8<\/code><\/strong> \u2014 journal de ext4. Si genera mucho I\/O, hay muchas escrituras en el filesystem.<\/li>\n<\/ul>\n\n\n\nAgentes de seguridad (muy comunes en empresas)<\/strong><\/p>\n\n\n\n\npmd<\/code><\/strong> \u2014 Palo Alto Cortex XDR<\/strong> (endpoint protection). Usa fanotify<\/code> para monitorear cada archivo tocado. Puede consumir 100%+ CPU cuando otro proceso est\u00e1 haciendo I\/O intensivo.<\/li>\n\n\n\nwazuh-syscheckd<\/code><\/strong> \u2014 Wazuh File Integrity Monitoring. Recorre el filesystem peri\u00f3dicamente calculando hashes.<\/li>\n\n\n\nwazuh-modulesd:syscollector<\/code><\/strong> \u2014 inventario de paquetes, procesos, puertos, hardware. Corre por defecto cada 1h.<\/li>\n\n\n\nwazuh-agentd<\/code>, wazuh-logcollector<\/code>, wazuh-modulesd<\/code><\/strong> \u2014 otros componentes de Wazuh.<\/li>\n\n\n\nnessus-service<\/code>, nessus-agent-module<\/code>, nessusd<\/code><\/strong> \u2014 agente de Tenable Nessus para escaneo de vulnerabilidades.<\/li>\n\n\n\nsandboxd<\/code> (cortexus)<\/strong> \u2014 an\u00e1lisis de archivos con YARA de Cortex XDR.<\/li>\n\n\n\nfail2ban-server<\/code><\/strong> \u2014 puede generar I\/O leyendo logs cuando hay muchos intentos.<\/li>\n<\/ul>\n\n\n\nDesarrollo (VS Code Remote \/ Java)<\/strong><\/p>\n\n\n\n\njava ... jdt_ws<\/code><\/strong> \u2014 JDT Language Server<\/strong> de Red Hat (extensi\u00f3n Java para VS Code). Indexa proyectos. Configurado con -Xmx5G<\/code> por defecto \u2014 un solo workspace puede pedir 5 GB.<\/li>\n\n\n\nnode ... vscode-server<\/code><\/strong> \u2014 servidor de VS Code Remote. Usa bootstrap-fork<\/code> para extensionHost, fileWatcher, ptyHost.<\/li>\n\n\n\njava ... oracle.dbtools<\/code><\/strong> \u2014 extensi\u00f3n Oracle SQL Developer, arranca un JDK propio por conexi\u00f3n.<\/li>\n\n\n\nnode ...\/.vscode-server\/<\/code><\/strong> con --type=extensionHost<\/code> \u2014 cada extensi\u00f3n que corre en su propio process host.<\/li>\n<\/ul>\n\n\n\nContenedores \/ servicios<\/strong><\/p>\n\n\n\n\ndockerd<\/code>, containerd<\/code><\/strong> \u2014 daemons de Docker. docker ps<\/code>, docker events<\/code> generan lecturas.<\/li>\n\n\n\nsnapd<\/code><\/strong> \u2014 daemon de snap packages. Refresca autom\u00e1ticamente snaps de vez en cuando (I\/O importante).<\/li>\n<\/ul>\n\n\n\nSistema operativo \/ escritorio<\/strong><\/p>\n\n\n\n\nsystemd-journald<\/code><\/strong> \u2014 recolector de logs de systemd. Si est\u00e1 en estado D, hay presi\u00f3n sobre \/var\/log\/journal\/<\/code>.<\/li>\n\n\n\ntracker-miner-fs-3<\/code><\/strong> \u2014 indexador de archivos de GNOME. En servidores no tiene sentido, se puede desactivar.<\/li>\n\n\n\ngnome-shell<\/code>, gsd-*<\/code><\/strong> \u2014 shell y daemons de GNOME. No deber\u00edan correr en un server sin GUI.<\/li>\n\n\n\nvmtoolsd<\/code><\/strong> \u2014 VMware Tools. Se comunica con el hypervisor, actividad ligera pero constante.<\/li>\n<\/ul>\n\n\n\nBackups \/ replicaci\u00f3n<\/strong><\/p>\n\n\n\n\nrsync<\/code>, borg<\/code>, restic<\/code><\/strong> \u2014 herramientas de backup, cuando corren generan I\/O masivo.<\/li>\n\n\n\nvgauth<\/code>, procesos de snapshot<\/strong> \u2014 cuando el hypervisor toma un snapshot de la VM, el I\/O del guest sufre.<\/li>\n<\/ul>\n\n\n\n
\n\n\n\nInterpretaci\u00f3n r\u00e1pida del pico_*.log<\/code><\/h3>\n\n\n\nCuando abr\u00e1s un pico, mir\u00e1 en este orden:<\/p>\n\n\n\n
\n%Cpu(s)<\/code> line en top<\/code><\/strong>: \u00bfqu\u00e9 proporci\u00f3n es us<\/code>, sy<\/code>, wa<\/code>?\n\nwa<\/code> alto + sy<\/code> alto = kernel bloqueado en I\/O<\/li>\n\n\n\nwa<\/code> alto + us<\/code> bajo = procesos esperando disco, no CPU<\/li>\n<\/ul>\n<\/li>\n\n\n\nkswapd0<\/code> al 100%<\/strong> en top \u2192 falta RAM, revis\u00e1 free -h<\/code> en el snapshot<\/li>\n\n\n\n- Procesos en estado D<\/strong>: son los que est\u00e1n esperando I\/O. El culpable directo.<\/li>\n\n\n\n
iostat<\/code><\/strong>: mir\u00e1 %util<\/code> del dispositivo sda<\/code> (o el que corresponda) y w_await<\/code> \/ r_await<\/code>. Latencia > 20ms = disco saturado.<\/li>\n\n\n\niotop<\/code><\/strong>: qui\u00e9n est\u00e1 leyendo\/escribiendo. Ojo con los ?dif<\/code> que a veces significan waiting for I\/O<\/code>.<\/li>\n\n\n\n- Swap usage en
free -h<\/code><\/strong>: si Inter usado<\/code> est\u00e1 cerca del 100% \u2192 swap thrashing.<\/li>\n<\/ol>\n\n\n\nCombinaci\u00f3n cl\u00e1sica del thrashing por RAM: kswapd0<\/code> al 100% + swap casi lleno + %wa<\/code> > 50% + iotop mostrando lecturas de swap.<\/p>\n\n\n\nCombinaci\u00f3n cl\u00e1sica del scan de seguridad: pmd<\/code> al 100% + procesos wazuh\/nessus activos + %wa<\/code> moderado (15-25%) + duraci\u00f3n corta (< 2 min).<\/p>\n\n\n\nCombinaci\u00f3n cl\u00e1sica del backup del hypervisor: %wa<\/code> alto, pero ning\u00fan proceso interno explica el I\/O<\/strong> \u2014 hay que mirar m\u00e9tricas del datastore en vCenter.<\/p>\n","protected":false},"excerpt":{"rendered":"Setup completo para capturar autom\u00e1ticamente qu\u00e9 est\u00e1 causando %wa alto en un servidor Linux, con evidencia forense de cada pico. Requisitos previos bash sysstat trae iostat, vmstat. iotop para I\/O por proceso. Paso 1: Script del monitor principal Crea \/usr\/local\/bin\/wa_monitor.sh: bash bash Qu\u00e9 captura: en cada pico, un archivo pico_YYYYMMDD_HHMMSS_waN.log con top, procesos bloqueados en […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-25656","post","type-post","status-publish","format-standard","hentry","category-sin-categoria"],"blocksy_meta":[],"_links":{"self":[{"href":"https:\/\/sada.services\/index.php?rest_route=\/wp\/v2\/posts\/25656","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sada.services\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sada.services\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sada.services\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/sada.services\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=25656"}],"version-history":[{"count":1,"href":"https:\/\/sada.services\/index.php?rest_route=\/wp\/v2\/posts\/25656\/revisions"}],"predecessor-version":[{"id":25657,"href":"https:\/\/sada.services\/index.php?rest_route=\/wp\/v2\/posts\/25656\/revisions\/25657"}],"wp:attachment":[{"href":"https:\/\/sada.services\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=25656"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sada.services\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=25656"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sada.services\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=25656"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}