Las plataformas ADC y WAAP corporativas no se componen de un único proceso monolítico. Operan en conjunto los workers que recopilan estadísticas de tráfico, las operaciones de red, la gestión del firewall, los servicios CLI, los procesos de routing console y los recopiladores de log y RRD. Si uno de estos procesos se detiene en silencio o opera con un perfil de recursos incorrecto, el problema comienza en el plano de gestión y visibilidad antes que en el plano de tráfico.
En el enfoque clásico, el monitoreo de procesos se deja a agentes externos o a herramientas de process manager de propósito general. Estas herramientas pueden ver si el proceso está en ejecución o no; pero no conocen el rol del proceso dentro de TR7, con qué perfil de recursos debe operar ni si ante qué error se hará reload o restart. Como resultado, el monitoreo queda genérico y la acción se vuelve manual.
En los sistemas multiproceso basados en Node.js, los ajustes de recursos también son críticos. No es correcto dar a cada proceso el mismo límite de heap y el mismo valor de thread pool. Si el proceso CLI ligero y el RRD collector intensivo se ejecutan con el mismo perfil, o se produce un desperdicio de recursos o el proceso intensivo se ve presionado con límites insuficientes.
El comportamiento de restart también debe diseñarse con cuidado. Un restart demasiado frecuente oculta la causa raíz; un restart demasiado tardío hace que el proceso defectuoso siga teniendo efecto durante mucho tiempo. En los containers ADC que transportan el tráfico, primero debe intentarse un soft reload y, ante el fallo, hacerse el hard restart fallback.
TR7 Monitoreo de Procesos mantiene los procesos internos de la plataforma bajo control operativo con perfiles de rendimiento basados en el tipo de proceso, gestión de subprocesos basada en ForkManager, recopilación de estadísticas basada en RRD y flujo de restart soft-to-hard.
TR7 trata el monitoreo de procesos no solo como un control de "¿está el proceso en pie?", sino junto con el tipo de proceso, el perfil de recursos y el comportamiento de restart.
Cada tipo de proceso se ejecuta con uno de los perfiles default, light, heavy, worker o ioIntensive según su carga de trabajo. Los ajustes de heap, semi-space y UV thread pool se generan según este perfil.
Los procesos RRD collector recopilan los eventos de CPU, memoria, disco y red con la lógica de series temporales. Estos datos proporcionan la base para las pantallas de monitoreo, la lógica de alarmas y el análisis de operaciones.
Los procesos internos de TR7 se inician como child process y se siguen bajo el ForkManager registry. Si un proceso se cae, el manager puede gestionar el flujo de reinicio y el árbol de procesos se separa de forma operativa.
Cuando los errores de estadísticas del ADC alcanzan un determinado umbral, primero se intenta un soft reload. Si el soft reload falla, el container se reinicia de forma controlada con el hard restart fallback.
El Monitoreo de Procesos opera los componentes internos de TR7 con gestión de recursos basada en perfiles, restart automático y seguimiento de procesos central.
TR7 usa cinco perfiles de rendimiento: default, light, heavy, worker e ioIntensive. Cada perfil tiene diferentes ajustes de max-old-space-size, max-semi-space-size y UV thread pool. Mientras los procesos ligeros operan con menos heap, los procesos collector intensivos se inician con más recursos. Este modelo reduce el error de dar un límite de tipo único a todos los procesos.
El valor de UV_THREADPOOL_SIZE se calcula según el número de CPU del sistema. El valor se determina con la lógica del doble del número de núcleos de CPU, de modo que sea mínimo 4 y máximo 32. Esto evita que el thread pool quede demasiado pequeño en los procesos de I/O intensivo. Al mismo tiempo, limita el consumo innecesario de recursos por valores altos descontrolados.
Al iniciar los procesos Node.js, el valor de max-old-space-size se da a través del perfil. El perfil default puede operar con 1024 MB de heap, los perfiles light y worker con 512 MB, el perfil heavy con 2048 MB y el perfil ioIntensive con 1024 MB. Este ajuste limita el uso de memoria de los procesos según su tarea. Los procesos collector grandes y los procesos de gestión pequeños no se fuerzan al mismo perfil de memoria.
El valor de semi-space es un parámetro de operación importante que afecta el comportamiento del garbage collection. Pueden usarse valores como 8 MB en el perfil light, 16 MB en el default y 32 MB en el heavy. Esta distinción permite que los procesos que procesan datos de forma intensiva operen con más holgura y que los procesos ligeros permanezcan con un footprint pequeño. Los ajustes de recursos se vuelven más previsibles según el tipo de proceso.
Los procesos de datos intensivos como rrd-collector y rrd-websocket pueden vincularse al perfil heavy. pool-stats-worker puede ejecutarse con el perfil worker, network-fork con el perfil ioIntensive, frr-console y cli-server con el perfil light. Este mapping proporciona un estándar de operación y reduce el riesgo de selección de perfil incorrecto. Cuando se añade un nuevo proceso se define explícitamente a qué perfil se vincula.
El flujo buildExecArgv genera los argumentos de operación de Node.js necesarios al iniciar el proceso a partir de los valores del perfil. Parámetros como max-old-space-size y max-semi-space-size no se dejan a la edición manual de la línea de comandos. Esto aumenta la consistencia del deployment. Los diferentes entornos generan un comportamiento similar usando las mismas definiciones de perfil.
El flujo buildEnvVars genera ajustes de entorno como UV_THREADPOOL_SIZE según el perfil del proceso. Especialmente en los procesos de I/O intensivo, el valor correcto de thread pool es importante para el rendimiento y la estabilidad. Este enfoque reduce la necesidad del administrador del sistema de gestionar un archivo de environment separado para cada proceso. El comportamiento de recursos se vincula al modelo de perfil central.
Las familias de procesos como network_fork, firewall_fork y stat_fork se siguen bajo la infraestructura de ForkManager. Cada subproceso opera como un child process independiente. En caso de caída o salida inesperada, el manager puede ejecutar el flujo de reinicio y actualización de estado. Esta estructura evita que los servicios internos permanezcan invisibles dentro de un único proceso principal.
Los eventos de gestión de procesos pueden monitorearse a través de un canal de log separado. Los eventos de inicio, parada, error, restart e internal exception se registran de modo que el equipo de operaciones pueda examinarlos. Estos registros facilitan el análisis de causa raíz en los problemas de procesos recurrentes. El monitoreo no se limita al estado instantáneo, sino que también puede examinarse el comportamiento histórico.
Cuando los contadores de errores de stat del ADC alcanzan un determinado umbral, el sistema puede iniciar un flujo de recuperación automática. El primer paso es un soft reload; ante el fallo se aplica el hard restart fallback. Este comportamiento ayuda a recuperar las averías temporales de runtime sin esperar la intervención manual. Las situaciones que se repiten de forma continua requieren además un examen operativo.
El monitoreo de procesos opera junto con los valores de perfil, el mapping de tipo de proceso, los límites del UV thread pool, la gestión de fork y el comportamiento de restart.
El perfil default puede usarse con 1024 MB de heap y 16 MB de semi-space para los procesos de propósito general. El valor del UV thread pool sigue el valor predeterminado calculado según el número de CPU. Proporciona un punto de partida equilibrado para los procesos sin una necesidad especial definida.
El perfil light opera con valores de recursos más bajos como 512 MB de heap y 8 MB de semi-space. Es adecuado para procesos ligeros como FRR console y CLI server. Este perfil reduce el consumo innecesario de memoria.
El perfil heavy se reserva para los procesos collector intensivos con 2048 MB de heap y 32 MB de semi-space. Puede usarse en procesos que procesan más datos como rrd-collector y rrd-websocket. El límite superior del UV thread pool puede llegar hasta 32.
El perfil worker se usa con 512 MB de heap para procesos más acotados y orientados a tareas. El valor del UV thread pool puede ajustarse en un mínimo de 8 y en función del número de CPU, manteniendo el límite superior más controlado. Puede preferirse en procesos como pool-stats-worker.
El perfil ioIntensive se usa con 1024 MB de heap para procesos de carga de I/O. El UV thread pool se amplía según el número de núcleos de CPU y puede llegar hasta el límite superior de 32. Es adecuado para trabajos de carga de red e I/O como network-fork.
La estructura PROCESS_TYPE_PROFILES vincula los tipos de proceso al perfil de rendimiento correspondiente. rrd-collector puede mapearse a heavy, pool-stats-worker a worker, network-fork a ioIntensive, frr-console a light y cli-server a light. Este mapping proporciona un estándar de operación.
Si tras una nueva función el pool-stats-worker sufre presión de recursos, el perfil del proceso puede trasladarse de worker a un perfil más adecuado. Los valores de heap y UV thread pool se actualizan con el modelo de perfil central. El equipo de operaciones no tiene que editar uno por uno los argumentos de runtime.
Si los errores de estadísticas del ADC superan un determinado umbral, TR7 puede intentar un soft reload automático. Si el soft reload tiene éxito, el proceso se recupera reduciendo el impacto en el tráfico. En caso de fallo se aplica el hard restart fallback.
El equipo de operaciones de red puede evaluar la salud del proceso relevante en un único flujo de operación con el estado de procesos, los comandos del sistema y las salidas de monitoreo. El estado de los procesos network fork, firewall fork o collector acelera el examen del incidente.
Tras un failover o mantenimiento, qué procesos se reiniciaron y cuándo puede examinarse a partir de los registros de operación. Estos registros se usan para el análisis de interrupciones y los procesos de change management. Los restart de procesos individuales pueden relacionarse con el comportamiento general del sistema.
Límites de recursos basados en perfiles, flujo de restart automático y visibilidad de procesos central. Le hacemos un recorrido en una instalación en vivo en su propio entorno.