As plataformas ADC e WAAP corporativas não consistem em um único processo monolítico. Workers que coletam estatística de tráfego, operações de rede, gestão de firewall, serviços de CLI, processos de routing console, coletores de log e RRD funcionam em conjunto. Se um desses processos para em silêncio ou roda com o perfil de recursos errado, o problema começa na camada de gestão e visibilidade antes mesmo do plano de tráfego.
Na abordagem clássica, o monitoramento de processos é deixado a cargo de agentes externos ou ferramentas de process manager de propósito geral. Essas ferramentas conseguem ver se o processo está ou não em execução; mas não conhecem o papel do processo dentro do TR7, com qual perfil de recursos ele deve rodar ou em qual situação de erro deve ser feito reload ou restart. Como resultado, o monitoramento permanece genérico e a ação torna-se manual.
Em sistemas multiprocesso baseados em Node.js, as configurações de recursos também são críticas. Não é correto dar a cada processo o mesmo limite de heap e o mesmo valor de thread pool. Se um processo CLI leve e um RRD collector intenso rodam com o mesmo perfil, ou se gera desperdício de recursos, ou o processo intenso é sufocado com limites insuficientes.
O comportamento de restart também deve ser projetado com cuidado. Restart frequente demais oculta a causa raiz; restart tardio demais leva o processo defeituoso a permanecer ativo por muito tempo. Já nos containers ADC que carregam o tráfego, deve-se tentar primeiro o soft reload e, em caso de falha, fazer o hard restart como fallback.
O TR7 Monitoramento de Processos mantém os processos internos da plataforma sob controle operacional com perfis de desempenho por tipo de processo, gestão de processos filhos baseada em ForkManager, coleta de estatística baseada em RRD e fluxo de restart soft-to-hard.
O TR7 trata o monitoramento de processos não apenas como uma verificação de "o processo está de pé?", mas junto com o tipo de processo, o perfil de recursos e o comportamento de restart.
Cada tipo de processo é executado, conforme sua carga de trabalho, com um dos perfis default, light, heavy, worker ou ioIntensive. As configurações de heap, semi-space e UV thread pool são geradas conforme esse perfil.
Os processos RRD collector coletam eventos de CPU, memória, disco e rede com lógica de série temporal. Esses dados fornecem a base para os painéis de monitoramento, a lógica de alarme e a análise de operação.
Os processos internos do TR7 são iniciados como child process e acompanhados sob o registry do ForkManager. Se um processo cai, o manager pode gerenciar o fluxo de reinício e a árvore de processos é separada operacionalmente.
Quando os erros de estatística do ADC atingem um determinado limiar, primeiro é tentado um soft reload. Se o soft reload falhar, o container é reiniciado de forma controlada com hard restart fallback.
O Monitoramento de Processos opera os componentes internos do TR7 com gestão de recursos baseada em perfis, restart automático e acompanhamento de processos centralizado.
O TR7 usa cinco perfis de desempenho: default, light, heavy, worker e ioIntensive. Cada perfil tem configurações distintas de max-old-space-size, max-semi-space-size e UV thread pool. Processos leves rodam com heap menor, enquanto processos collector intensos são iniciados com mais recursos. Esse modelo reduz o erro de dar um limite único a todos os processos.
O valor UV_THREADPOOL_SIZE é calculado conforme o número de CPUs do sistema. O valor é determinado com a lógica do dobro do número de núcleos de CPU, com mínimo de 4 e máximo de 32. Isso evita que o thread pool fique pequeno demais em processos com I/O intenso. Ao mesmo tempo, limita o consumo desnecessário de recursos por valores altos descontrolados.
Ao iniciar os processos Node.js, o valor max-old-space-size é fornecido via perfil. O perfil default pode rodar com 1024 MB, os perfis light e worker com 512 MB, o perfil heavy com 2048 MB e o perfil ioIntensive com 1024 MB de heap. Essa configuração limita o uso de memória dos processos conforme sua tarefa. Processos collector grandes e processos de gestão pequenos não são forçados ao mesmo perfil de memória.
O valor de semi-space é um parâmetro de execução importante que influencia o comportamento do garbage collection. Podem ser usados valores como 8 MB no perfil light, 16 MB no perfil default e 32 MB no perfil heavy. Essa distinção permite que processos que processam dados de forma intensa rodem com mais folga e que processos leves permaneçam com pequena footprint. As configurações de recursos tornam-se mais previsíveis conforme o tipo de processo.
Processos com dados intensos como rrd-collector e rrd-websocket podem ser vinculados ao perfil heavy. O pool-stats-worker pode rodar com o perfil worker, o network-fork com o perfil ioIntensive, e o frr-console e o cli-server com o perfil light. Esse mapping fornece um padrão de operação e reduz o risco de seleção de perfil errada. Quando um novo processo é adicionado, define-se claramente a qual perfil será vinculado.
O fluxo buildExecArgv gera, ao iniciar o processo, os argumentos de execução do Node.js necessários a partir dos valores do perfil. Parâmetros como max-old-space-size e max-semi-space-size não são deixados a cargo de edição manual da linha de comando. Isso aumenta a consistência de deployment. Ambientes distintos produzem comportamento semelhante usando as mesmas definições de perfil.
O fluxo buildEnvVars gera configurações de ambiente como UV_THREADPOOL_SIZE conforme o perfil do processo. Em especial nos processos com I/O intenso, o valor correto de thread pool é importante para o desempenho e a estabilidade. Essa abordagem reduz a necessidade de o administrador de sistema gerenciar um arquivo de environment separado para cada processo. O comportamento de recursos é vinculado ao modelo central de perfis.
Famílias de processos como network_fork, firewall_fork e stat_fork são acompanhadas sob a infraestrutura ForkManager. Cada processo filho roda como child process independente. Em situações de queda ou saída inesperada, o manager pode executar o fluxo de reinício e atualização de estado. Essa estrutura evita que os serviços internos fiquem invisíveis dentro de um único processo principal.
Os eventos de gestão de processos podem ser monitorados por um canal de log separado. Eventos de início, parada, erro, restart e internal exception são registrados de forma que a equipe de operações possa investigá-los. Esses registros facilitam a análise de causa raiz em problemas recorrentes de processo. O monitoramento não se limita ao estado instantâneo; o comportamento histórico também pode ser investigado.
Quando os contadores de erro de stat do ADC atingem um determinado limiar, o sistema pode iniciar um fluxo de recuperação automática. O primeiro passo é o soft reload; em caso de falha, é aplicado hard restart fallback. Esse comportamento ajuda na recuperação de falhas temporárias de runtime sem esperar intervenção manual. Situações que se repetem continuamente exigem, além disso, investigação operacional.
O monitoramento de processos é operado junto com valores de perfil, mapping de tipo de processo, limites de UV thread pool, gestão de fork e comportamento de restart.
O perfil default pode ser usado para processos de propósito geral com 1024 MB de heap e 16 MB de semi-space. O valor de UV thread pool segue o valor padrão calculado conforme o número de CPUs. Fornece um ponto de partida equilibrado para processos sem necessidade específica definida.
O perfil light roda com valores de recursos mais baixos, como 512 MB de heap e 8 MB de semi-space. É adequado para processos leves como FRR console e CLI server. Esse perfil reduz o consumo desnecessário de memória.
O perfil heavy é reservado para processos collector intensos com 2048 MB de heap e 32 MB de semi-space. Pode ser usado em processos que processam mais dados, como rrd-collector e rrd-websocket. O limite superior do UV thread pool pode chegar a 32.
O perfil worker é usado para processos mais enxutos e orientados a tarefa, com 512 MB de heap. O valor de UV thread pool pode ser ajustado com mínimo de 8 e conforme o número de CPUs, com o limite superior mantido de forma mais controlada. Pode ser preferido em processos como pool-stats-worker.
O perfil ioIntensive é usado para processos com carga de I/O, com 1024 MB de heap. O UV thread pool é ampliado conforme o número de núcleos de CPU e pode chegar ao limite superior de 32. É adequado para tarefas com carga de rede e I/O, como network-fork.
A estrutura PROCESS_TYPE_PROFILES vincula os tipos de processo ao perfil de desempenho correspondente. rrd-collector pode ser mapeado como heavy, pool-stats-worker como worker, network-fork como ioIntensive, frr-console como light e cli-server como light. Esse mapping fornece um padrão de operação.
Se, após uma nova funcionalidade, o pool-stats-worker sofre pressão de recursos, o perfil do processo pode ser movido do worker para um perfil mais adequado. Os valores de heap e UV thread pool são atualizados com o modelo central de perfis. A equipe de operações não precisa editar os argumentos de runtime um a um.
Se os erros de estatística do ADC ultrapassam um determinado limiar, o TR7 pode tentar um soft reload automático. Se o soft reload for bem-sucedido, o processo se recupera reduzindo o impacto no tráfego. Em caso de falha, é aplicado hard restart fallback.
A equipe de operações de rede pode avaliar a saúde do processo relevante em um único fluxo de operação, com estado de processo, comandos de sistema e saídas de monitoramento. O estado dos processos network fork, firewall fork ou collector acelera a investigação do incidente.
Após failover ou manutenção, quais processos reiniciaram e quando pode ser investigado nos registros de operação. Esses registros são usados para análise de interrupção e processos de change management. Os restarts de processo individuais podem ser correlacionados com o comportamento geral do sistema.
Limites de recursos baseados em perfis, fluxo de restart automático e visibilidade de processos centralizada. Vamos fazer um tour em uma instalação ao vivo no seu próprio ambiente.