Die Einrichtung eines Monitoring-Tools für NGINX ist ein wichtiger Bestandteil der Aufrechterhaltung des Website-Betriebs. Ein ordnungsgemäßes NGINX-Monitoring kann viele nützliche Informationen über die Performance der zugrunde liegenden Anwendung liefern. Es gibt eine ganze Reihe von Monitoring-Systemen, die sich für diese Aufgabe eignen. Der erste Schritt besteht jedoch darin, die Erfassung von Metriken in NGINX zu aktivieren.
Verwendung des stub_status-Moduls
Für NGINX Open Source gibt es ein Modul namens „ngx_http_stub_status_module“ (oder einfach „stub_status“), das einige wichtige Messwerte zur NGINX-Aktivität bereitstellt.
Um zu prüfen, ob Ihr NGINX-Build über das Modul „stub_status“ verfügt, führen Sie nginx -V aus:
$ nginx -V 2>&1 | grep --color -- --with-http_stub_status_moduleAlle unsere NGINX-Builds enthalten das Modul stub_status auf allen unterstützten Plattformen.
Wenn Ihr NGINX-Build das Modul stub_status nicht enthält, müssen Sie NGINX aus dem Quellcode neu erstellen und dabei dem Skript --with-http_stub_status_module als Parameter übergeben: configure.
Aktivieren Sie im nächsten Schritt das Modul in Ihrer NGINX-Konfiguration, indem Sie die Direktive stub_status in einen location-Block aufnehmen. Sie können den Block jederzeit zu einer vorhandenen server-Konfiguration hinzufügen. Alternativ können Sie einen separaten server-Block mit einem einzigen, speziell dafür vorgesehenen location-Block für die Direktive stub_status hinzufügen, wie hier gezeigt:
server {
listen 127.0.0.1:80;
server_name 127.0.0.1;
location /nginx_status {
stub_status;
}
}Geeignete server-Blöcke für die Direktive stub_status befinden sich manchmal außerhalb der Hauptkonfigurationsdatei (nginx.conf). Wenn Sie in dieser Datei keinen geeigneten Block finden, suchen Sie nach zusätzlichen Konfigurationsdateien, die üblicherweise in nginx.conf eingebunden werden.
Wir empfehlen außerdem, den Zugriff auf die Metriken auf autorisierte Benutzer zu beschränken, beispielsweise indem Sie die Direktiven „allow“ und „deny“ in den Block „location“ oder „server“ aufnehmen.
Nachdem das Modul „stub_status“ konfiguriert wurde, vergessen Sie nicht, die NGINX-Konfiguration neu zu laden (zum Beispiel mit dem Befehl „service nginx reload“). Weitere Informationen zu NGINX-Steuerungssignalen finden Sie hier.
Um die stub_status-Metriken anzuzeigen, führen Sie eine curl-Abfrage aus. Für die oben gezeigte Konfiguration eignet sich der folgende Befehl:
$ curl http://127.0.0.1/nginx_statusActive connections: 2
server accepts handled requests
841845 841845 1631067
Reading: 0 Writing: 1 Waiting: 1Wenn dies nicht funktioniert, überprüfen Sie, wohin die Anfragen an /nginx_status weitergeleitet werden. In vielen Fällen kann ein anderer server-Block der Grund dafür sein, dass Sie nicht auf die stub_status-Metriken zugreifen können. Weitere Informationen zu diesen instanzweiten NGINX-Metriken finden Sie in der Referenzdokumentation.
Wenn das stub_status-Modul in NGINX aktiviert ist und funktioniert, können Sie mit der Installation und Konfiguration des Überwachungssystems Ihrer Wahl fortfahren.
Protokolldateien und syslog
Das NGINX-Zugriffsprotokoll und das Fehlerprotokoll enthalten viele nützliche Informationen, die sich für die Erfassung von Metriken eignen. Mithilfe von NGINX-Variablen können Sie das Format des Zugriffsprotokolls vollständig anpassen. Bestimmte Überwachungstools können NGINX-Protokolldateien zur Erfassung von Metriken nutzen.
Um verschiedene Leistungs- und Sicherheitsanforderungen zu erfüllen, sollten Sie die syslog-Funktion von NGINX verwenden. Während Protokolldateien auf die Festplatte geschrieben werden, ermöglicht syslog NGINX, Protokolldaten über ein Netzwerkprotokoll zu senden. Sie können beispielsweise ein dediziertes Linux-System einrichten, das sämtliche Protokolldaten von verschiedenen NGINX-Instanzen erfasst.
Weitere Informationen zur Protokollierung finden Sie im NGINX Plus-Administratorhandbuch.
NGINX mit Amplify überwachen
Wir bieten ein natives Tool für das Monitoring von NGINX an. Es heißt NGINX Amplify und ist ein SaaS-Tool, mit dem Sie bis zu fünf Server kostenlos überwachen können (für eine größere Anzahl von Servern sind Abonnements verfügbar).
Der Einstieg in NGINX Amplify ist ganz einfach. In weniger als zehn Minuten erhalten Sie sofort einsatzbereite Diagramme für alle wichtigen NGINX-Metriken. NGINX Amplify verwendet automatisch Metriken aus stub_status und aus Zugriffsprotokollen und kann außerdem verschiedene Betriebssysteminformationen erfassen.
Mit NGINX Amplify können Sie die Leistung Ihrer NGINX-Instanz visualisieren und das Betriebssystem, PHP‑FPM, Docker-Container und vieles mehr überwachen. Eine einzigartige Funktion von Amplify ist ein statischer Analysator für Ihre NGINX-Konfiguration, der Empfehlungen zur Verbesserung der Sicherheit und Effizienz der Konfiguration gibt.
Erfahren Sie hier mehr über NGINX Amplify und testen Sie es kostenlos.

Zusätzliches API-Modul in NGINX Plus
NGINX Plus bietet eine bessere Möglichkeit, Leistungsmetriken über ein spezialisiertes API-Modul abzurufen.
Das API-Modul bietet einen detaillierten Satz von Metriken, wobei der Schwerpunkt auf dem Load-Balancing und den Statistiken virtueller Server liegt. So wird beispielsweise für 1xx, 2xx, 3xx, 4xx, 5xx eine Aufschlüsselung aller HTTP-Statuscodes für server-Blöcke angezeigt. Informationen zum Integritätsstatus sind sowohl für HTTP- als auch für TCP/UDP-Upstream-Server verfügbar. Cache-Metriken umfassen Treffer und Fehlschläge für jede Cache-Zone.
Neben der Erfassung eines erweiterten Satzes von Metriken ermöglicht Ihnen die API auch, HTTP- und TCP/UDP-Upstream-Servergruppen neu zu konfigurieren und Schlüssel-Wert-Variablen zu verwalten, ohne die Konfiguration neu zu laden oder NGINX Plus neu zu starten.
NGINX Plus verfügt außerdem über ein integriertes Dashboard, das die zusätzlichen Metriken nutzt. Die zusätzlichen Metriken können auch in NGINX Amplify verwendet werden.
Weitere Monitoring-Lösungen
Eine Reihe weiterer Monitoring-Produkte kann NGINX-Metriken erfassen und darstellen. Die folgenden Links beschreiben die gängigsten Integrationsszenarien:
- Die NGINX-Monitoring-Erweiterung für AppDynamics
- Datadog‑NGINX Integration
- NGINX-Monitoring mit Dynatrace
- Das NGINX-Plug-in für New Relic
- Das NGINX-Plug-in für Pingdom Server Monitor
- Prometheus HTTP-Exporter und -Integrationen
Über die Autoren
Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.