NGINX Monitoring: Verbindungen, Requests, Latenz und Fehler

Warum NGINX Monitoring wichtig ist

NGINX ist für viele Anwendungen die Eingangstür: Webserver, Reverse Proxy, Load Balancer und TLS-Terminierung. Jeder Nutzer-Request läuft hindurch, und genau deshalb lässt sich hier am besten messen, was Nutzer tatsächlich erleben. Gleichzeitig werden Probleme hier oft zuerst sichtbar, als 502- und 504-Antworten, selbst wenn die Ursache in einem Upstream-Service liegt. NGINX Monitoring hat daher zwei Aufgaben: NGINX selbst überwachen und es als Aussichtspunkt auf die Services dahinter nutzen.

Obseria erfasst NGINX-Metriken mit dem nginx-Receiver des OpenTelemetry Collectors, parst Access und Error Logs mit dem filelog-Receiver und empfängt Spans aus dem NGINX-OpenTelemetry-Modul.

Die NGINX-Metriken, auf die es ankommt

stub_status-Metriken

Das Open-Source-Modul stub_status liefert wenige, aber nützliche Zähler. nginx.requests ergibt den Request-Durchsatz. nginx.connections_accepted und nginx.connections_handled sollten im gleichen Tempo wachsen; bleibt handled hinter accepted zurück, hat NGINX ein Limit wie worker_connections erreicht. nginx.connections_current teilt offene Verbindungen in reading, writing und waiting auf. Eine wachsende Zahl von writing-Verbindungen bedeutet meist langsame Upstreams, denn NGINX hält die Verbindung, während es auf die Antwort wartet.

Aktivieren Sie das Modul auf einem nur lokal erreichbaren Listener:

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

Signale aus dem Access Log

Latenz und Fehler stammen aus dem Access Log. Ergänzen Sie $request_time und $upstream_response_time in Ihrem Log-Format. Die Differenz zeigt, ob die Zeit in NGINX und der Client-Verbindung oder im Backend vergeht. Statuscodes liefern die Fehlerrate: 5xx für serverseitige Fehler, 499 für Clients, die vor der Antwort aufgegeben haben.

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;

Typische Probleme und wie Sie sie erkennen

• 502 Bad Gateway: Der Upstream hat die Verbindung abgelehnt oder geschlossen. Suchen Sie im Error Log nach "connect() failed" und prüfen Sie den Zustand des Upstream-Service.
• 504 Gateway Timeout: Der Upstream hat nicht innerhalb von proxy_read_timeout geantwortet. Eine Upstream Response Time nahe am Timeout ist die Frühwarnung.
• Verbindungslimits: Bearbeitete Verbindungen bleiben hinter angenommenen zurück, oder das Error Log meldet "worker_connections are not enough".
• Steigende 499er: Clients brechen Requests ab, oft wegen langsamer Antworten oder knapper Client-Timeouts.
• TLS- und Zertifikatsprobleme: Handshake-Fehler im Error Log; kombinieren Sie sie mit synthetischen Checks, die den Ablauf von Zertifikaten prüfen.

Best Practices für NGINX Monitoring

1. Lassen Sie stub_status auf einem lokalen Listener und machen Sie es nie öffentlich erreichbar.
2. Nutzen Sie ein strukturiertes oder Key-Value-Format für Access Logs mit Zeitfeldern, damit Logs zuverlässig geparst werden.
3. Definieren Sie SLOs auf Erfolgsrate und Latenz pro Virtual Host oder Route, gemessen an NGINX.
4. Geben Sie den W3C-Trace-Context von NGINX an die Upstreams weiter, damit sich ein langsamer Request Ende zu Ende verfolgen lässt.
5. Verwerfen Sie Logzeilen von Health Checks und statischen Assets in der Pipeline, wenn Sie sie nicht brauchen, um das Logvolumen zu begrenzen.

So unterstützt Obseria Ihr NGINX Monitoring

Obseria führt NGINX-Metriken, geparste Access und Error Logs sowie Traces in Obseria Lake zusammen. TopoGraph platziert NGINX vor den Services, die es weiterleitet, sodass eine 5xx-Spitze direkt auf den betroffenen Upstream zeigt. Obseria Intelligence korreliert Änderungen bei Fehlern und Latenz mit Deployments, Upstream-Zustand und Host-Metriken und erklärt die wahrscheinliche Ursache mit einer Beweiskette. Die Obseria Pipeline verwirft verrauschte Logzeilen und maskiert IP-Adressen oder Query Strings vor der Speicherung; gefilterte Logs kosten nur den Ingest. Dashboards, Alerts und SLOs sind enthalten, und synthetische Checks von mehr als 50 Standorten ergänzen die Außensicht auf Ihre Endpunkte.

Beginnen Sie mit stub_status und dem Access Log auf einem Host, ergänzen Sie Tracing für die wichtigsten Routen und rollen Sie dieselbe Collector-Konfiguration auf jede NGINX-Instanz aus. So erhalten Sie Request-Rate, Fehlerrate und Latenz pro Route, die Sie direkt in SLOs überführen können.