uWSGI stats server exposure limits for bottleneck measurement

Direct answer

For production TCP exposure, treat the uWSGI stats endpoint as an unauthenticated internal management interface. Appropriate controls are network isolation only: bind to localhost or a private management network, restrict reachability with host firewall rules, and prefer a Unix socket for local access. Do not expose the TCP stats port to untrusted networks.

Enabling the stats server does not change core worker scheduling logic, but it adds a listening socket and periodic aggregation work. Baseline measurements are therefore post-enable measurements. Take baselines after warm-up and interpret them as the enabled-state behavior, not a pre-enable baseline.

CPU saturation vs worker saturation cannot be distinguished from uWSGI metrics alone. Use uWSGI worker busy/idle and queue signals together with external system CPU/load monitoring. Field names and aggregation are version-sensitive; verify the exact fields present in your build before relying on them.

Confirmed facts

• The stats server and stats socket are disabled by default and require explicit configuration. Enabling requires restart or reload, which changes process state.
• The stats interface exposes internal process and request information that is sensitive.
• The stats interface has no built-in authentication or authorization.
• Stats output format and available fields are version-sensitive, and per-worker versus master-level aggregation is not uniform across releases.

Likely explanation and operational limits

Access controls for TCP in production. The interface provides no auth. Likely appropriate controls are network-level only: bind to 127.0.0.1 or a management VLAN, firewall the stats port to monitoring hosts only, place behind a TLS terminating proxy that adds authentication, or use a Unix socket to limit access to local processes. Raw TCP exposure to the internet is not appropriate.

Measurement impact. Likely the stats listener does not alter scheduling or queue reporting semantics, but the added socket and aggregation add a small overhead. Baseline measurements should be taken after enablement and warm-up, and compared consistently under the same enabled configuration.

Version-stable metric guidance. Likely usable concepts across builds are per-worker request counts, worker status busy/idle, request timing aggregates, and master queue length. Exact JSON keys differ by version. Do not assume field stability. Verify locally which fields exist in your build and use them consistently for trend analysis.

Distinguishing saturation. Likely worker saturation is indicated by sustained high busy worker count with growing queue and rising average request time. CPU saturation is inferred by correlating those uWSGI signals with external CPU utilization. Low CPU with high busy workers and growing queue suggests I/O or application wait rather than CPU saturation.

Verification steps for this case

• Check running configuration for stats server/socket options and bound address/port.
• Inspect stats JSON output locally to confirm which fields are present in your build.
• Compare uWSGI worker busy/idle and queue metrics against external CPU and load monitoring during a controlled load test.
• Review firewall and network reachability for the stats port from untrusted networks.

Assumption and uncertainty: field names and aggregation behavior are build-dependent. The recommendation above assumes you can enforce network isolation. One missing diagnostic detail that changes the recommendation is your current uWSGI build version and the exact stats bind address/port in use, to confirm field names and reachability.