How to Monitor NGINX with OpenTelemetry

Monitoring NGINX with OpenTelemetry means collecting connection and request metrics through the OpenTelemetry Collector's NGINX receiver, plus access logs, over OTLP, so your edge and proxy layer is fully observed.

What to observe in NGINX

NGINX sits in front of your services as a web server, reverse proxy and load balancer, so its signals are the first indication of user-facing trouble: request rate, response status codes (especially 4xx and 5xx), active and waiting connections, and upstream response time. A spike in 5xx at the NGINX layer almost always means a backend is failing, and NGINX is where you see it first.

The important nuance is that NGINX's built-in status endpoint reports connections and request counts but not per-status-code breakdowns, so the 4xx/5xx and upstream-latency detail comes from parsing the access log, which is where the real diagnostic value lives.

How OpenTelemetry collects it

The Collector's nginx receiver reads the stub_status endpoint and emits connection and request metrics over OTLP. Because stub_status does not break down status codes or upstream timing, you also collect the access and error logs with the filelog receiver and parse them into structured telemetry, which is where response codes and upstream latency come from.

The setup steps are enabling the stub_status endpoint and setting an access-log format that includes the status code and upstream response time, so the filelog parser can extract them. Recent NGINX and OpenTelemetry modules can additionally emit traces for requests passing through.

Receiver metric names follow the nginx receiver's conventions; status-code and upstream-latency detail come from access-log parsing.

Key metrics to watch

The signals that explain most NGINX incidents:

Signal	Source	What it tells you / watch for
`nginx.requests`	nginx receiver	Total request rate; the throughput baseline.
`nginx.connections_current (active/waiting)`	nginx receiver	Active and idle connections; saturation shows up here before requests fail.
`5xx rate (from access log)`	filelog	Server errors, almost always a failing or slow backend.
`4xx rate (from access log)`	filelog	Client errors; a spike can indicate a broken deploy or bad client.
`upstream response time (from access log)`	filelog	Backend latency as NGINX sees it; the number that separates edge from backend problems.
`connections accepted vs handled`	nginx receiver	A gap means NGINX is dropping connections, often a worker or file-descriptor limit.

What to put on a dashboard

An NGINX dashboard should let you decide instantly whether a problem is at the edge or in a backend. Row one: request rate and 5xx rate (the alarm). Row two: 4xx rate and upstream response time, which tells you whether NGINX is waiting on a slow backend. Row three: active and waiting connections against limits, to catch connection saturation.

# 5xx rate (parsed from access logs)
sum(rate(nginx_http_responses{status=~"5.."}[5m]))
  / sum(rate(nginx_http_responses[5m]))

# upstream latency: is NGINX waiting on a backend?
histogram_quantile(0.95, nginx_upstream_response_time)

# connection saturation
nginx.connections_current{state="active"}

Reading the signals: common failure modes

5xx from a failing backend

NGINX returns 5xx and upstream response time either spikes or the upstream returns errors, because a backend is unhealthy. The 5xx rate and upstream latency rising together point straight at the backend; investigate the upstream service, not NGINX itself.

Connection saturation

Requests start failing or queueing and active connections sit at the worker or file-descriptor limit, so NGINX cannot accept more. The gap between accepted and handled connections is the tell. Raise worker connections and file-descriptor limits, or add capacity.

Upstream latency, not NGINX

End-to-end latency is high but NGINX's own processing is fast and upstream response time is high, meaning the delay is in the backend. This distinction, cheap to see once you parse upstream timing, stops teams from tuning the proxy when the backend is the problem.

Example alert conditions

Starting thresholds to tune:

Condition	Signal	Meaning
5xx rate > 2% for 5m	errors	A backend is failing behind NGINX.
upstream p95 > SLO for 10m	backend	Backend latency, not the proxy.
active connections near worker limit	saturation	NGINX close to refusing connections.
accepted > handled connections	capacity	NGINX dropping connections.

From monitoring to autonomous resolution

Ops Singularity's TelemetryOps ingests NGINX telemetry over OpenTelemetry, and Sentinel AI correlates an edge error spike to the failing backend and resolves it through a governed Action Ticket. Explore TelemetryOps.

Frequently asked questions

How do I monitor NGINX with OpenTelemetry?

Use the OpenTelemetry Collector's nginx receiver for connection and request metrics from the stub-status endpoint, and the filelog receiver to parse access and error logs, exported over OTLP.

What NGINX metrics matter most?

Request rate, 4xx and 5xx error rates, upstream response time, and active and waiting connection counts.