uWSGI stats server exposure limits for bottleneck measurement

uWSGI provides a built-in stats server and stats socket that can expose runtime metrics without application code changes. The interface is intended to support measuring load, request handling and worker health before tuning for a bottleneck.

The stats capability is disabled by default and requires an explicit configuration choice to enable. Enabling it involves a restart or reload, which itself changes process behavior and must be considered when interpreting baseline measurements. The endpoint exposes internal process and request information that can be sensitive.

An unresolved operational decision is how to expose the stats endpoint. A Unix socket limits access to local processes, while a TCP socket enables remote monitoring. The stats output format and available fields are version-sensitive, and aggregation behavior for per-worker versus master-level data is not uniform across releases.

What access controls are considered appropriate for a stats endpoint exposed via TCP in production? Does enabling the stats server alter worker scheduling or queue reporting enough to affect baseline measurements? Which metric fields can be relied upon for distinguishing CPU saturation from worker saturation across versions?