NGINX monitoring: connections, requests, latency and errors

Why NGINX monitoring matters

NGINX is the front door for many applications: web server, reverse proxy, load balancer and TLS terminator. Every user request passes through it, which makes it the best place to measure what users actually experience. It is also a frequent place where problems become visible first, as 502 and 504 responses, even when the cause lies in an upstream service. NGINX monitoring therefore has two jobs: watch NGINX itself, and use it as a vantage point on the services behind it.

Obseria collects NGINX metrics with the nginx receiver of the OpenTelemetry Collector, parses access and error logs with the filelog receiver, and receives spans from the NGINX OpenTelemetry module.

The NGINX metrics that matter

stub_status metrics

The open source stub_status module exposes a small but useful set of counters. nginx.requests gives request throughput. nginx.connections_accepted and nginx.connections_handled should grow at the same rate; if handled falls behind accepted, NGINX ran into a limit such as worker_connections. nginx.connections_current splits open connections into reading, writing and waiting. A growing number of writing connections usually means slow upstreams, because NGINX holds the connection while it waits for the response.

Enable it on a local-only listener:

server {
    listen 127.0.0.1:8080;
    location /nginx_status {
        stub_status;
        allow 127.0.0.1;
        deny all;
    }
}

Access log signals

Latency and errors come from the access log. Add $request_time and $upstream_response_time to your log format. The difference between both tells you whether time is spent in NGINX and the client connection or in the backend. Status codes give the error rate: 5xx for server-side failures, 499 for clients that gave up before a response arrived.

log_format timed '$remote_addr "$request" $status $body_bytes_sent '
                 'rt=$request_time urt=$upstream_response_time';
access_log /var/log/nginx/access.log timed;

Common problems and how to detect them

• 502 Bad Gateway: the upstream refused the connection or closed it. Check the error log for "connect() failed" and the health of the upstream service.
• 504 Gateway Timeout: the upstream did not answer within proxy_read_timeout. Upstream response time approaching the timeout is the early warning.
• Connection limits: handled connections lag accepted connections, or the error log reports "worker_connections are not enough".
• Rising 499s: clients cancel requests, often because of slow responses or aggressive client timeouts.
• TLS and certificate issues: handshake errors in the error log; combine them with synthetic checks that test certificate expiry.

Best practices for NGINX monitoring

1. Keep stub_status on a local listener and never expose it publicly.
2. Use a structured or key-value access log format with timing fields, so logs parse reliably.
3. Define SLOs on request success rate and latency per virtual host or route, measured at NGINX.
4. Propagate W3C trace context from NGINX to upstreams so a slow request can be followed end to end.
5. Drop health check and static asset log lines in the pipeline if you do not need them, to control log volume.

How Obseria helps with NGINX monitoring

Obseria combines NGINX metrics, parsed access and error logs and traces in Obseria Lake. TopoGraph places NGINX in front of the services it proxies, so a 5xx spike points straight to the affected upstream. Obseria Intelligence correlates error and latency changes with deployments, upstream health and host metrics and explains the likely root cause with a chain of evidence. Obseria Pipeline can drop noisy log lines and mask IP addresses or query strings before storage, and filtered logs cost only ingestion. Dashboards, alerts and SLOs are included, and synthetic checks from 50+ locations add the outside view of your endpoints.

Start with stub_status and the access log on one host, add tracing for the routes that matter most, and roll the same Collector configuration out to every NGINX instance. Within a day you have request rate, error rate and latency per route, ready to turn into SLOs.