Enterprise ADC and WAAP platforms are not a single monolithic process. Workers that collect traffic statistics, network operations, firewall management, CLI services, routing console processes, and log and RRD collectors all run together. If one of these processes silently stops or runs under the wrong resource profile, the problem begins in the management and visibility plane before it reaches the traffic plane.
The classic approach delegates process supervision to external agents or general-purpose process manager tools. These tools can see whether a process is running, but they do not know the process's role inside TR7, the resource profile it should run under, or whether a given failure calls for a reload or a restart. The result is a monitoring layer that stays generic and actions that stay manual.
Resource settings are equally critical in multi-process Node.js-based systems. Giving every process the same heap limit and the same thread pool value is not correct. If a lightweight CLI process and a high-load RRD collector run under the same profile, either resource waste accumulates or the heavy process is throttled by insufficient limits.
Restart behaviour also requires careful design. Restarting too frequently hides the root cause; restarting too late leaves a faulty process in effect for too long. For ADC containers that carry live traffic, a soft reload should be attempted first, with a hard restart fallback applied only on failure.
TR7 Process Monitoring keeps internal platform processes under operational control through per-process-type performance profiles, ForkManager-based subprocess management, RRD-based metric collection and a soft-to-hard restart flow.
TR7 treats process monitoring not just as a "is the process alive?" check, but as a discipline that combines process type, resource profile and restart behaviour.
Each process type runs under one of the default, light, heavy, worker or ioIntensive profiles, selected according to its workload. Heap, semi-space and UV thread pool settings are derived from that profile.
RRD collector processes gather CPU, memory, disk and network events in a time-series model. This data provides the foundation for monitoring dashboards, alert logic and operational analysis.
TR7 internal processes are started as child processes and tracked under the ForkManager registry. When a process crashes, the manager can handle the restart flow; the process tree is operationally isolated from the parent.
When ADC stat errors reach a defined threshold, a soft reload is attempted. If the soft reload fails, a hard restart fallback restarts the container in a controlled manner.
Process Monitoring operates TR7 internal components with profile-based resource management, automatic restart and centralised process tracking.
TR7 uses five performance profiles: default, light, heavy, worker and ioIntensive. Each profile carries distinct max-old-space-size, max-semi-space-size and UV thread pool settings. Lightweight processes run with lower heap values while high-throughput collector processes start with wider resources. This model reduces the error of applying a one-size-fits-all limit across all processes.
UV_THREADPOOL_SIZE is derived from the system CPU count, with a minimum of 4 and a maximum of 32 — following a logic of twice the number of CPU cores. This prevents the thread pool from being too small for I/O-intensive processes while also capping the value to avoid unnecessary resource consumption at uncontrolled high settings.
When Node.js processes are started, max-old-space-size is supplied from the profile. The default profile uses 1024 MB, light and worker profiles 512 MB, the heavy profile 2048 MB and the ioIntensive profile 1024 MB. This constrains each process's memory use to match its role. Large collector processes and small management processes are not forced into the same memory profile.
The semi-space value is an important runtime parameter that affects garbage collection behaviour. Values such as 8 MB for the light profile, 16 MB for default and 32 MB for heavy can be applied. This distinction lets data-intensive processes operate with more headroom while lightweight processes maintain a small footprint. Resource settings become more predictable per process type.
Data-intensive processes such as rrd-collector and rrd-websocket can be bound to the heavy profile. pool-stats-worker runs under the worker profile, network-fork under ioIntensive, and frr-console and cli-server under light. This mapping establishes an operational standard and reduces the risk of incorrect profile selection. When a new process is added, its profile assignment is explicitly declared.
The buildExecArgv flow derives the required Node.js runtime arguments from profile values when a process is started. Parameters such as max-old-space-size and max-semi-space-size are not left to manual command-line editing. This increases deployment consistency. Different environments produce comparable behaviour because they share the same profile definitions.
The buildEnvVars flow produces environment settings such as UV_THREADPOOL_SIZE from the process profile. For I/O-intensive processes in particular, the correct thread pool value matters for both performance and stability. This approach reduces the need for system administrators to maintain separate environment files for each process. Resource behaviour is anchored to the central profile model.
Process families such as network_fork, firewall_fork and stat_fork are tracked under the ForkManager infrastructure. Each subprocess runs as an independent child process. On crash or unexpected exit, the manager can execute the restart and status-update flow. This structure prevents internal services from remaining invisible inside a single parent process.
Process management events are observable on a dedicated log channel. Start, stop, error, restart and internal exception events are recorded in a form that operations teams can review. These records make root-cause analysis easier when process problems recur. Monitoring is not limited to current state — historical behaviour can also be examined.
When ADC stat error counters reach a defined threshold, the system can initiate an automatic recovery flow. The first step is a soft reload; if that fails, a hard restart fallback is applied. This behaviour helps transient runtime faults recover without waiting for manual intervention. Conditions that recur persistently require separate operational investigation.
Process monitoring is operated together with profile values, process type mappings, UV thread pool limits, fork management and restart behaviour.
The default profile can be used for general-purpose processes with a 1024 MB heap and a 16 MB semi-space. The UV thread pool follows the calculated default derived from CPU count. It provides a balanced starting point for processes that have no specific profile requirement.
The light profile operates with lower resource values such as a 512 MB heap and an 8 MB semi-space. It is suited for lightweight processes such as FRR console and CLI server. This profile reduces unnecessary memory consumption.
The heavy profile is reserved for intensive collector processes with a 2048 MB heap and a 32 MB semi-space. It can be used for processes that handle larger data volumes, such as rrd-collector and rrd-websocket. The UV thread pool upper limit can reach 32.
The worker profile is used for narrower, task-focused processes with a 512 MB heap. The UV thread pool can be set with a minimum of 8 and tied to CPU count, keeping the upper limit more controlled. It is a candidate for processes such as pool-stats-worker.
The ioIntensive profile is used for I/O-heavy processes with a 1024 MB heap. The UV thread pool grows with CPU core count and can reach an upper limit of 32. It is suited for network- and I/O-heavy workloads such as network-fork.
The PROCESS_TYPE_PROFILES structure binds process types to their assigned performance profile. rrd-collector maps to heavy, pool-stats-worker to worker, network-fork to ioIntensive, and frr-console and cli-server to light. This mapping provides a hard-coded operational standard.
If pool-stats-worker experiences resource pressure after a new feature ships, the process profile can be moved to a more appropriate profile. Heap and UV thread pool values are updated through the central profile model. The operations team does not need to edit individual runtime arguments.
If ADC stat errors exceed the defined threshold, TR7 can attempt an automatic soft reload. If the soft reload succeeds, the process recovers with minimal traffic impact. If it fails, a hard restart fallback is applied.
The network operations team can assess process health alongside system commands and monitoring output in a single operational flow. The status of network fork, firewall fork or collector processes speeds up event investigation.
After a failover or maintenance window, the operational log shows which processes restarted and when. These records are used for outage analysis and change management. Individual process restarts can be correlated with overall system behaviour.
Profile-based resource limits, automatic restart flow and centralised process observability. Let's walk through a live setup in your own environment.