Wir freuen uns, Ihnen mitteilen zu können, dass NGINX Plus Release 19 (R19) jetzt verfügbar ist. NGINX Plus ist der einzige All-in-One- Load Balancer, Inhaltscache, Webserver und API-Gateway. NGINX Plus basiert auf NGINX Open Source und umfasst exklusive erweiterte Funktionen und preisgekrönten Support. Ein Hauptschwerpunkt der neuen Version ist die Überwachung mit neuen Funktionen, die sie detaillierter und flexibler machen und so die Zuverlässigkeit Ihrer Anwendungen im großen Maßstab verbessern.
Zu den neuen Funktionen in NGINX Plus R19 gehören:
Standortblöcke
, neue Metriken zur DNS-Lookup-Aktivität und Unterstützung für den Export im Prometheus-Format sowie JSON. Das NGINX Plus-Dashboard zeigt die neuen Metriken pro Standort an und verfügt über neue Registerkarten für die DNS-Metriken und Metriken zu NGINX Plus-Clustern.Veraltete APIs – NGINX Plus R13 (veröffentlicht im August 2017) führte die brandneue NGINX Plus-API für die Metrikerfassung und dynamische Neukonfiguration von Upstream-Gruppen ein und ersetzte die Status- und Upstream-Conf-APIs, die diese Funktionen zuvor implementiert hatten. Wie damals angekündigt, blieben die veralteten APIs für einen beträchtlichen Zeitraum weiterhin verfügbar und wurden unterstützt, der mit NGINX Plus R16 endete. Wenn Ihre Konfiguration die Anweisungen „status“
und/oder „upstream_conf“
enthält, müssen Sie diese im Rahmen des Upgrades auf R19 durch die Anweisung „api“
ersetzen.
Ratschläge und Hilfe zur Migration auf die neue NGINX Plus-API finden Sie im Übergangshandbuch in unserem Blog oder wenden Sie sich an unser Supportteam.
Neue Betriebssysteme werden unterstützt –
Ältere Betriebssysteme werden nicht mehr unterstützt –
Weitere Informationen zu unterstützten Plattformen finden Sie in den technischen Daten für NGINX Plus und dynamische Module .
NGINX Plus R19 macht die Überwachung noch flexibler und erweitert sowohl die Arten der Metriken, die Sie erfassen können, als auch die Möglichkeiten, diese zu analysieren.
Die NGINX Plus-API bietet eine breite Palette an Echtzeit-Überwachungsmetriken, darunter mehrere Zähler zu einem virtuellen Server, wenn Sie die Direktive status_zone
in den Server{}-
Block aufnehmen. Mit NGINX Plus R19 können Sie jetzt zusätzlich zum (oder anstelle des) übergeordneten Server{}-
Blocks Metriken für einzelne Standortblöcke
erfassen, indem Sie diesen Standortblöcken
die Direktive „status_zone“
hinzufügen. Durch diese feinere Überwachung können Sie schneller die genauen Teile Ihrer Website erkennen, die Fehler verursachen, und so die Fehlerbehebung effektiver durchführen.
Die folgende Konfiguration ermöglicht die Erfassung von Metriken für eine gesamte Website und zusätzlich für alle Anfragen an URIs, die mit /admin/ beginnen.
Sie können dann am Endpunkt http/location_zones auf die Metriken zugreifen.
$ curl http://localhost:8080/api/5/http/location_zones { "www_admin": { "Anfragen": 3393, "Antworten": { "1xx": 0, "2xx": 3307, "3xx": 81, "4xx": 5, „5xx“: 0, "gesamt": 3393 }, "verworfen": 0, "empfangen": 15403, "gesendet": 835227 } }
Es ist auch möglich, die Statuszone
-Direktive in einen If
-Block einzufügen. Beachten Sie jedoch, dass die Metriken für einen bestimmten Standort nur einmal und ab der letzten Statuszone-
Direktive gezählt werden, die während der Anforderungsverarbeitung angetroffen wurde. Die folgende Konfiguration erweitert das vorherige Beispiel, indem sie separate Metriken erfasst, wenn eine Anforderung an den Speicherort /admin/ eine Abfragezeichenfolge enthält.
Die NGINX Plus-API wurde außerdem um Metriken zur Verfolgung der DNS-Lookup-Aktivität erweitert, insbesondere zu DNS-Anforderungstypen und Antwortstatus. Um Messdaten zu einer Gruppe von DNS-Servern zu erfassen, die NGINX Plus für Namenssuchen abfragt, fügen Sie der Resolver-
Direktive den Parameter status_zone
hinzu.
Sie können dann am Resolver- Endpunkt auf die Metriken zugreifen.
$ curl http://localhost:8080/api/5/resolvers { "internal_dns": { "Anfragen": { "Name": 132, "srv": 0, "Adresse": 0 }, "Antworten": { "kein Fehler": 130, "formerr": 0, „Servfehler“: 0, "nxdomain": 0, "nichtimp": 0, "abgelehnt": 0, „Zeitüberschreitung“: 2, "unbekannt": 0 } } }
Das NGINX Plus-Dashboard zur Live-Aktivitätsüberwachung bietet einen praktischen zentralen Ort zum Verfolgen von Metriken, die von der NGINX Plus-API erfasst werden. Das Dashboard wurde in NGINX Plus R19 um die oben beschriebenen neuen Resolver- und Standortmetriken erweitert. Darüber hinaus meldet es jetzt Metriken im Zusammenhang mit der gemeinsamen Nutzung des Laufzeitstatus in einem Cluster (aktiviert mit dem Modul „Zonensynchronisierung“ ), auf die zuvor nur über die NGINX Plus-API zugegriffen werden konnte.
Es gibt zwei umbenannte Registerkarten und zwei neue Registerkarten:
Standort-
und Serverblöcken
angezeigt.Um das neue Dashboard zu erkunden, besuchen Sie https://demo.nginx.com/ .
Die NGINX Plus-API gibt Metriken im JSON-Format zurück, einem gängigen und praktischen Format für die Integration mit externen Überwachungs- und Application Performance Management (APM)-Lösungen. Sie können jetzt auch Metriken im Prometheus-Format exportieren, das insbesondere in Kubernetes-Umgebungen beliebt ist.
Das Modul Prometheus-njs stellt die Prometheus-Metriken bereit. So aktivieren Sie die exportierten Metriken:
Konfigurieren Sie in der NGINX Plus-Konfigurationsdatei einen dedizierten Speicherort für die Prometheus-Metrikerfassung.
Scrape_config-
Abschnitt in der Prometheus-Konfigurationsdatei angeben.NGINX Plus bietet einen sehr flexiblen Ansatz zur Ratenbegrenzung. Mehrere Ratenbegrenzungen können gleichzeitig verfolgt und erzwungen werden. Die Durchsetzung selbst kann auf fünf verschiedene Arten erfolgen – darunter die Verzögerung übermäßiger Anfragen, deren direkte Ablehnung und das Zulassen einer Reihe uneingeschränkter Anfragen vor der Durchsetzung – sowie Kombinationen dieser Verhaltensweisen. Eine ausführliche Erklärung finden Sie in unserem Blog .
Diese Flexibilität kann zwar zu einer äußerst verfeinerten Ratenbegrenzung führen, aber wie ermitteln Sie überhaupt die geeignete Ratenbegrenzung für Ihren Datenverkehr? Wie können Sie im Voraus erkennen, ob Ihr geplantes Ratenlimit zu hoch (in diesem Fall könnten Ihre Server überlastet sein) oder zu niedrig (in diesem Fall könnte das Benutzererlebnis beeinträchtigt werden) ist?
Die beste Informationsquelle ist das Fehlerprotokoll von NGINX Plus, wo ein detaillierter Eintrag wie der folgende erstellt wird, wenn NGINX Plus eine Anfrage verzögert oder ablehnt:
2019/09/03 11:42:12 [Fehler] 57#57: *339 Begrenzungsanforderungen, Überschuss: 0,600 nach Zone „my_limit“, Client: 172.17.0.1, Server: www.example.com, Anfrage: "GET / HTTP/1.1", Host: "www.example.com:80"
Der Eintrag enthält nützliche Informationen, z. B. wie viele Anfragen pro Millisekunde diese Anfrage über der konfigurierten Rate darstellt (das Überschussfeld
), welches bestimmte Limit überschritten wurde (das Zonenfeld
) und die IP-Adresse des Clients (das Clientfeld
). Für Planungszwecke sind die Informationen jedoch nur dann nützlich, wenn Sie sie erhalten, bevor Sie die Beschränkungen für Ihren Datenverkehr tatsächlich durchsetzen.
NGINX Plus R19 fügt diese Vorhersagefunktion mit einem „Dry-Run“-Modus zur Ratenbegrenzung hinzu. Protokolleinträge werden wie gewohnt erstellt, die Ratenbegrenzungen werden jedoch nicht erzwungen. Um den Probelaufmodus zu aktivieren, fügen Sie die neue Direktive „limit_req_dry_run“
in denselben Block wie die Direktive(n ) „limit_req“
ein.
Im folgenden Beispiel definieren die limit_req_zone
-Direktiven vier verschiedene Ratenbegrenzungen, von 10.000 Anfragen pro Sekunde bis hinunter zu 10 Anfragen pro Sekunde. Wir wenden diese Raten mit den limit_req
-Direktiven im Stammstandortblock
(Zeilen 9–12) zusammen mit der limit_req_dry_run
-Direktive an, um die Durchsetzung zu deaktivieren.
NGINX Plus schreibt für jede Anfrage, die eine bestimmte Ratenbegrenzung überschreiten würde, einen Protokolleintrag, der deutlich mit „dry
run“
gekennzeichnet ist. In unserer Analyse des Protokolls können wir dann die Einträge nach dem Zonenfeld
filtern, um zu bestimmen, welche der Ratenbegrenzungen das gewünschte Verhalten liefert.
03.09.2019 11:56:26 [Fehler] 142#142: *22282 Begrenzung der Anfragen, Probelauf , Überschuss: 1.000 nach Zone „1000rs“, Kunde: 172.17.0.1, Server: www.example.com, Anfrage: "GET / HTTP/1.1", Host: "www.example.com:80"
Mit dem In-Memory-Schlüssel-Wert-Speicher für NGINX Plus können Sie die NGINX Plus-API verwenden, um das Verkehrsmanagement basierend auf den Attributen der Anforderung dynamisch zu konfigurieren. Beispiele für Anwendungsfälle sind das dynamische Blockieren von IP-Adressen , die dynamische Bandbreitenbegrenzung und das Zwischenspeichern von Authentifizierungstoken .
NGINX Plus R19 erweitert den Schlüssel-Wert-Speicher, indem es zur vorhandenen Unterstützung für einzelne IP-Adressen auch Unterstützung für IP-Netzwerkbereiche (Subnetze) hinzufügt. Dies bedeutet, dass ein einzelner Eintrag im Schlüssel-Wert-Speicher mit allen IP-Adressen in einem Netzwerkbereich übereinstimmen kann. Dies vereinfacht die Konfiguration und spart Ihnen Zeit, da Sie die Adressen, aus denen ein Bereich besteht, nicht einzeln hinzufügen müssen. Der Schlüssel‑Wert‑Speicher verwendet die CIDR‑Notation zur Darstellung von Netzwerkbereichen. Beispielsweise steht 192.168.13.0/24 für die Adressen 192.168.13.0 bis 192.168.13.255. Es werden sowohl IPv4- als auch IPv6-Adressen und -Bereiche unterstützt.
Um Netzwerkbereiche zu aktivieren, fügen Sie der Direktive keyval_zone
den neuen Parameter type=ip
hinzu, wie in der folgenden Konfiguration für die dynamische Denylist von IP-Adressen. Wenn NGINX Plus eine Suche durchführt, gibt jede IP-Adresse innerhalb eines im Schlüssel-Wert-Speicher gespeicherten Netzwerkbereichs eine Übereinstimmung zurück.
Zeile 2 gibt an, dass die Variable $in_denylist
ausgewertet wird, indem eine Suche im Schlüssel-Wert-Speicher der Denylist durchgeführt wird, wobei $remote_addr
(die Client-IP-Adresse) als Schlüssel verwendet wird. Der einfache if-
Block (Zeilen 8–10) lehnt dann eine Anfrage ab, wenn sich die Client-IP-Adresse auf der Deny-Liste befindet.
Der folgende Curl
-Befehl ruft die NGINX Plus-API auf, um einen Eintrag im Schlüssel-Wert-Speicher für den oben genannten Netzwerkbereich zu erstellen.
$ curl -X POST -d '{"192.168.13.0/24":"1"}' http://localhost:8080/api/5/http/keyvals/denylist
Im vorherigen Abschnitt bedeutet der Parameter timeout=24h
für die Direktive keyval_zone
in Zeile 1 von denylist.conf , dass jeder Eintrag im Schlüssel-Wert-Speicher der Denylist 24 Stunden nach seiner Erstellung abläuft (und aus dem Speicher entfernt wird).
Mit NGINX Plus R19 können Sie das Standard-Timeout (das durch den Timeout-
Parameter für den gesamten Schlüssel-Wert-Speicher festgelegt wird) durch ein anderes Timeout für jeden einzelnen Eintrag überschreiben. Einzelne Timeouts können größer oder kleiner als der Standard sein.
Um einen Eintrag mit einem nicht standardmäßigen Timeout zu erstellen, geben Sie den Wert als JSON-Objekt mit zwei Feldern an:
Wert
– In diesem Fall auf den gewünschten Wert einstellen1
um die Variable $in_denylist
zu füllenexpire
– Auf die Anzahl der Millisekunden nach der Erstellung einstellen, nach der der Wert abläuftDas folgende JSON stellt einen Denylist-Eintrag für localhost (127.0.0.1) dar, der in 1 Stunde (3.600.000 Millisekunden) abläuft.
{
"127.0.0.1": {
"Wert": "1",
"ablauf": 3600000
}
}
Der folgende Curl
-Befehl erstellt diesen Eintrag im Schlüssel-Wert-Speicher:
$ curl -X POST -d '{"127.0.0.1":{"Wert":"1","Ablauf":3600000}}' http://localhost:8080/api/5/http/keyvals/denylist
Die Direktive „limit_rate“
legt die Rate (Anzahl der Bytes pro Sekunde) fest, mit der NGINX Plus die Antwort auf eine HTTP-Anfrage sendet, und die Direktive „limit_rate_after“
legt die Anzahl der Bytes fest, die NGINX Plus sendet, bevor dieses Limit angewendet wird. Mit NGINX Plus R19 kann der Parameter für jede Anweisung eine Variable statt eines statischen Werts sein, wodurch eine dynamische Steuerung der Bandbreitennutzung basierend auf den Attributen der Anforderung ermöglicht wird.
Die folgende Beispielkonfiguration legt die Bandbreite entsprechend der vom Client verwendeten TLS-Version fest und belohnt modernere Browser effektiv mit schnelleren Antworten.
In früheren Versionen von NGINX Plus konnten Sie die Bandbreite durch Festlegen der Variable $limit_rate
begrenzen. Wir empfehlen Ihnen, stattdessen diese einfachere Methode zu verwenden. Weitere Einzelheiten finden Sie in der Dokumentation zur Direktive „limit_rate“
.
Die Anweisungen proxy_download_rate
und proxy_upload_rate
für TCP/UDP-Verkehr akzeptieren jetzt auch einen variablen Parameter.
Für eine noch ausgefeiltere Bandbreitenbegrenzung können Sie Skripterweiterungen wie das NGINX JavaScript-Modul (njs) verwenden, um eine erweiterte, benutzerdefinierte Logik zur Bestimmung der geeigneten Bandbreitenbegrenzung für eine bestimmte Verbindung zu implementieren.
Das NGINX JavaScript-Modul (njs) wurde auf Version 0.3.5 aktualisiert. Die wichtigsten Verbesserungen (kumulativ gegenüber früheren Versionen) sind:
Prozessobjekt
(besonders nützlich zum Lesen von Umgebungsvariablen)String.prototype.trim
-FunktionenWenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich auf NGINX Plus R19 zu aktualisieren. Sie erhalten außerdem eine Reihe zusätzlicher Fehlerbehebungen und Verbesserungen und NGINX kann Ihnen helfen, wenn Sie ein Support-Ticket erstellen müssen.
Bitte überprüfen Sie die in diesem Blogbeitrag beschriebenen neuen Funktionen und Verhaltensänderungen sorgfältig, bevor Sie mit dem Upgrade fortfahren.
Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es auszuprobieren – für Sicherheit, Lastausgleich und API-Gateway oder als vollständig unterstützten Webserver mit erweiterten Überwachungs- und Verwaltungs-APIs. Sie können noch heute mit einer kostenlosen 30-Tage-Testversion beginnen. Überzeugen Sie sich selbst, wie NGINX Plus Ihnen bei der Bereitstellung und Skalierung Ihrer Anwendungen helfen kann.
„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."