PM2 Master and Worker Processes: IPC Overhead During High-Frequency Metric Emission

When running Node.js applications in PM2 cluster mode, the master process coordinates worker instances and receives telemetry such as logs and custom metrics via an internal IPC channel.

The goal is to understand whether the volume of IPC messages generated by high-frequency logging or metric emission introduces measurable event-loop lag in the individual workers, even when overall CPU usage stays below saturation thresholds.

Constraints include the default round-robin load balancer, the inability to disable IPC without losing real-time monitoring, and the lack of a documented knob to throttle or batch these messages.

How does the IPC message rate correlate with observed event-loop delay in a worker under concurrent request load? Is there a configuration option to limit or batch IPC traffic while preserving essential process visibility? Are there known work-arounds that separate telemetry transport from the request-handling path?