Mantén el listener de caídas en Node.js corriendo con pm2

El listener de caídas del quickstart de Node.js es un proceso de larga vida, y los procesos de larga vida mueren: el VPS se reinicia, el proceso se rompe, el despliegue lo barre. Una pestaña de navegador o una sesión de screen no es la respuesta para algo en lo que confías. pm2, el pequeño gestor de procesos para Node, lo es: reinicia el listener tras una caída, lo arranca en el boot y mantiene sus logs ordenados.

El listener, supervisado

El listener del quickstart mantiene una conexión abierta con el stream de caídas y la lee para siempre, como la página de Node.js lo monta. Bajo pm2, el mismo script se convierte en un servicio gestionado:

pm2 start listen.js -n drops
pm2 save
pm2 startup

La primera línea arranca el script bajo supervisión, la segunda lo recuerda, la tercera lo engancha al arranque del sistema. Una caída ahora significa un reinicio en segundos, no un feed muerto hasta que alguien lo note.

Lo que el reinicio cubre, y lo que no

pm2 reinicia el proceso cuando sale, lo que cubre roturas, muertes por memoria y reinicios. No arregla un stream que se quedó callado: una conexión que sigue abierta pero no dice nada necesita la lógica de reconexión del propio listener, que el quickstart incorpora. Las dos capas trabajan juntas: el listener maneja una conexión muerta, pm2 maneja un proceso muerto.

Ajusta un retraso de reinicio para que un bucle de roturas no martillee el endpoint del stream: un listener que reconecta en un bucle apretado es un problema para el stream, y la opción de retraso de reinicio de pm2 espacia los reintentos.

Logs sin niñera

La salida de consola del listener se convierte en el registro de diagnóstico, y pm2 la escribe en archivos con rotación en lugar de un terminal que cerraste la semana pasada. Una línea por lote de alertas y una por reconexión basta; el comportamiento del stream de caídas, mensajes de control incluidos, que la página de Python documenta; es la referencia cuando el log muestre algo raro.

pm2 logs drops

sigue el registro en vivo cuando quieres mirarlo, y lo deja en paz cuando no.

Cuando creces más allá de un proceso

pm2 puede correr el mismo script dos veces para dos máquinas, pero el stream de caídas mantiene una conexión por clave, así que un segundo listener en vivo con la misma clave cierra el primero. La redundancia en este stream significa un standby en otro host, no un clúster en uno solo. Para un solo lector, sin embargo, pm2 más la lógica de reconexión es toda la historia de fiabilidad.

Arráncalo una vez, guárdalo, engánchalo al boot. El listener sigue escuchando, y el fin de semana deja de ser un riesgo.