Inspección de Procesos

Q: ¿lsof no encontrado en el contenedor Alpine?

Usa ss -tlnp o instala lsof solo en la imagen de depuración - no en el Dockerfile de producción a menos que esté aprobado.

Q: ¿Es seguro terminar el PID 1 en el contenedor?

No. Kubernetes reinicia el pod. Reduce la réplica o kubectl delete pod para un reinicio limpio después del drenaje.

top, htop y lsof para diagnosticar conflictos de puertos, procesos Node descontrolados y presión de recursos en hosts Linux que ejecutan APIs de Node.js.

Receta

Tarjeta de receta de referencia rápida - lista para copiar y pegar.

# Puerto en uso (EADDRINUSE)
lsof -i :3000
# o
ss -tlnp 'sport = :3000'
 
# Parada elegante
kill -TERM <PID>
sleep 5
kill -KILL <PID>   # solo si sigue ejecutándose
 
# Instantánea de CPU/memoria
top -b -n 1 | head -20
ps aux | grep node

Cuándo usarlo:

Desarrollo local: Error: listen EADDRINUSE: address already in use :::3000
Producción: estrangulamiento de CPU del pod o límites de memoria que causan terminaciones
Sospecha de proceso Node zombie después de una ejecución de prueba fallida
Múltiples trabajadores y API en la misma VM - ¿quién es dueño de qué puerto?

Ejemplo de trabajo

Conflicto de puertos en el portátil del desarrollador

$ npm run dev
Error: listen EADDRINUSE: address already in use :::3000
 
$ lsof -i :3000
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
node    48291  dev   23u  IPv6 0t...      0t0  TCP *:3000 (LISTEN)
 
$ kill -TERM 48291
$ npm run dev   # tiene éxito

Prefiere kill -TERM (SIGTERM) para que se ejecuten los hooks de apagado de Fastify/Express
kill -9 solo cuando el proceso ignora SIGTERM después de 10s

Inspección de pod de producción (Kubernetes)

# Encontrar pod
kubectl get pods -l app=orders-api
 
# Razón de OOM y reinicio
kubectl describe pod orders-api-7f8b9c-xyz | grep -A5 "Last State"
 
# Top dentro del contenedor (si la imagen tiene procps)
kubectl exec -it orders-api-7f8b9c-xyz -- top -b -n 1 | head -15
 
# Lista de procesos
kubectl exec orders-api-7f8b9c-xyz -- ps aux

# Extracto típico de describe
Last State:     Terminated
  Reason:       OOMKilled
  Exit Code:    137

El código de salida 137 a menudo significa terminación por OOM (128 + 9)
Compara memory.limit del contenedor con --max-old-space-size de Node si está configurado

Procesos de API y trabajador separados

ps aux | grep node
# node dist/server.js          ← API puerto 3000
# node dist/workers/email.js   ← sin puerto de escucha, CPU alta durante el lote

Los trabajadores sin HTTP no deberían aparecer en lsof -i :3000
CPU alta del trabajador: verifica la concurrencia de BullMQ y el tamaño de la carga útil del trabajo

Consejos de htop

htop
# F5 vista de árbol - ver PID 1 del contenedor padre
# F6 ordenar por MEM% o CPU%
# Filtrar: F4 escribir "node"

Una CPU de un solo hilo al 100% en un núcleo puede ser un bloqueo del bucle de eventos (trabajo síncrono)
El aumento de memoria sin aumento de tráfico sugiere una fuga - consulta Habilidad de Triaje de Incidentes

Comparación

Herramienta	Mejor para
lsof	Qué PID posee el puerto 3000
ss	Resumen de sockets sin instalar lsof
top	Instantánea rápida de CPU/memoria (todos los servidores)
htop	Ordenación interactiva y vista de árbol
kubectl describe	OOMKilled, recuento de reinicios, límites

Preguntas frecuentes

¿lsof no encontrado en el contenedor Alpine?

Usa ss -tlnp o instala lsof solo en la imagen de depuración - no en el Dockerfile de producción a menos que esté aprobado.

Node muestra muchos hilos en top - ¿normal?

Sí. El pool de hilos de libuv y los trabajadores de V8 crean hilos. Preocúpate por el RSS de memoria y el retraso del bucle de eventos, no solo por el recuento de hilos.

¿Es seguro terminar el PID 1 en el contenedor?

No. Kubernetes reinicia el pod. Reduce la réplica o kubectl delete pod para un reinicio limpio después del drenaje.

Relacionado

Conceptos básicos de CLI para Node - curl, jq, ss
Mejores prácticas de CLI de Linux - SIGTERM antes de SIGKILL
Respuesta del OOM Killer - heap vs RSS
Conceptos básicos de operaciones en tiempo de ejecución - apagado elegante

Versiones de la pila: Esta página fue escrita para Node.js 24.18.0 (LTS activa), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 y NestJS 11.

Receta

Tarjeta de receta de referencia rápida - lista para copiar y pegar.

# Puerto en uso (EADDRINUSE)
lsof -i :3000
# o
ss -tlnp 'sport = :3000'
 
# Parada elegante
kill -TERM <PID>
sleep 5
kill -KILL <PID>   # solo si sigue ejecutándose
 
# Instantánea de CPU/memoria
top -b -n 1 | head -20
ps aux | grep node

Cuándo usarlo:

Desarrollo local: Error: listen EADDRINUSE: address already in use :::3000
Producción: estrangulamiento de CPU del pod o límites de memoria que causan terminaciones
Sospecha de proceso Node zombie después de una ejecución de prueba fallida
Múltiples trabajadores y API en la misma VM - ¿quién es dueño de qué puerto?

Ejemplo de trabajo

Conflicto de puertos en el portátil del desarrollador

$ npm run dev
Error: listen EADDRINUSE: address already in use :::3000
 
$ lsof -i :3000
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
node    48291  dev   23u  IPv6 0t...      0t0  TCP *:3000 (LISTEN)
 
$ kill -TERM 48291
$ npm run dev   # tiene éxito

Prefiere kill -TERM (SIGTERM) para que se ejecuten los hooks de apagado de Fastify/Express
kill -9 solo cuando el proceso ignora SIGTERM después de 10s

Inspección de pod de producción (Kubernetes)

# Encontrar pod
kubectl get pods -l app=orders-api
 
# Razón de OOM y reinicio
kubectl describe pod orders-api-7f8b9c-xyz | grep -A5 "Last State"
 
# Top dentro del contenedor (si la imagen tiene procps)
kubectl exec -it orders-api-7f8b9c-xyz -- top -b -n 1 | head -15
 
# Lista de procesos
kubectl exec orders-api-7f8b9c-xyz -- ps aux

# Extracto típico de describe
Last State:     Terminated
  Reason:       OOMKilled
  Exit Code:    137

El código de salida 137 a menudo significa terminación por OOM (128 + 9)
Compara memory.limit del contenedor con --max-old-space-size de Node si está configurado

Procesos de API y trabajador separados

ps aux | grep node
# node dist/server.js          ← API puerto 3000
# node dist/workers/email.js   ← sin puerto de escucha, CPU alta durante el lote

Los trabajadores sin HTTP no deberían aparecer en lsof -i :3000
CPU alta del trabajador: verifica la concurrencia de BullMQ y el tamaño de la carga útil del trabajo

Consejos de htop

htop
# F5 vista de árbol - ver PID 1 del contenedor padre
# F6 ordenar por MEM% o CPU%
# Filtrar: F4 escribir "node"

Una CPU de un solo hilo al 100% en un núcleo puede ser un bloqueo del bucle de eventos (trabajo síncrono)
El aumento de memoria sin aumento de tráfico sugiere una fuga - consulta Habilidad de Triaje de Incidentes

Comparación

Herramienta	Mejor para
lsof	Qué PID posee el puerto 3000
ss	Resumen de sockets sin instalar lsof
top	Instantánea rápida de CPU/memoria (todos los servidores)
htop	Ordenación interactiva y vista de árbol
kubectl describe	OOMKilled, recuento de reinicios, límites

Preguntas frecuentes

¿lsof no encontrado en el contenedor Alpine?

Usa ss -tlnp o instala lsof solo en la imagen de depuración - no en el Dockerfile de producción a menos que esté aprobado.

Node muestra muchos hilos en top - ¿normal?

Sí. El pool de hilos de libuv y los trabajadores de V8 crean hilos. Preocúpate por el RSS de memoria y el retraso del bucle de eventos, no solo por el recuento de hilos.

¿Es seguro terminar el PID 1 en el contenedor?

No. Kubernetes reinicia el pod. Reduce la réplica o kubectl delete pod para un reinicio limpio después del drenaje.

Relacionado

Conceptos básicos de CLI para Node - curl, jq, ss
Mejores prácticas de CLI de Linux - SIGTERM antes de SIGKILL
Respuesta del OOM Killer - heap vs RSS
Conceptos básicos de operaciones en tiempo de ejecución - apagado elegante

Versiones de la pila: Esta página fue escrita para Node.js 24.18.0 (LTS activa), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 y NestJS 11.

Inspección de Procesos

Buscar en la documentación

Inspección de Procesos