Ankündigung von NGINX Plus R19

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:

• Flexiblere Überwachung – Wir haben neue Funktionen für genauere Einblicke und einfachere Analysen Ihres NGINX Plus-Ökosystems hinzugefügt, darunter eine optionale separate Metrikerfassung für 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.
• Probelaufmodus zum Testen von Ratenbegrenzungen – Das Festlegen der richtigen Ratenbegrenzungen für den Produktionsverkehr ist schwierig und sehr riskant – wenn Sie es falsch machen, kann dies die Benutzererfahrung eines großen Teils Ihrer Benutzer ernsthaft beeinträchtigen. Mit dem neuen Probelaufmodus können Sie die Auswirkungen Ihrer Ratenbegrenzungen auf den Produktionsverkehr verstehen, ohne sie tatsächlich anzuwenden.
• Verbesserungen am Schlüssel-Wert-Speicher – Sie können jetzt IP-Adressbereiche zusammen mit einzelnen Adressen im Schlüssel-Wert-Speicher speichern und Ablaufzeiten für einzelne Einträge festlegen.
• Dynamische Bandbreitenkontrolle – Beim Konfigurieren von Bandbreitenbegrenzungen können Sie die Rate jetzt als Variable festlegen und so je nach Attribut des eingehenden Datenverkehrs unterschiedliche Begrenzungen anwenden.

Wichtige Verhaltensänderungen

• 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 –

  • Alpine 3.10
  • Debian 10 („Buster“)
  • Ubuntu 19.04 („Disco“)

• Ältere Betriebssysteme werden nicht mehr unterstützt –

  • Debian 8 („Jessie“)
  • Ubuntu 14.04 („Vertrauenswürdig“)
  • Ubuntu 18.10 („Kosmisch“)

Weitere Informationen zu unterstützten Plattformen finden Sie in den technischen Daten für NGINX Plus und dynamische Module .

Neue Features im Detail

Neue Funktionen machen die Überwachung noch flexibler

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.

Metriken pro Standort

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.

DNS-Resolver-Metriken

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 } } }

Aktualisierungen am Dashboard zur Live-Aktivitätsüberwachung

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:

• „HTTP-Zonen“ ist der neue Name der Registerkarte „Serverzonen“ . Auf der Registerkarte werden jetzt Kennzahlen zu Standort- und Serverblöcken angezeigt.
• „HTTP-Upstreams“ ist der neue Name der Registerkarte „Upstreams“ . Dies sorgt für Übersichtlichkeit, wenn sowohl HTTP- als auch TCP/UDP-Module konfiguriert sind.
• Die neue Registerkarte „Cluster“ zeigt Metriken zur Statusfreigabe in NGINX Plus-Clustern an.
• Auf der neuen Registerkarte „Resolver“ werden Kennzahlen zur DNS-Lookup-Aktivität angezeigt.

Um das neue Dashboard zu erkunden, besuchen Sie https://demo.nginx.com/ .

Neues Modul für Prometheus-Monitoring

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:

1. Installieren Sie das Prometheus-njs -Modul .
2. Konfigurieren Sie die NGINX Plus API .

3. Konfigurieren Sie in der NGINX Plus-Konfigurationsdatei einen dedizierten Speicherort für die Prometheus-Metrikerfassung.

4. Konfigurieren Sie Prometheus so, dass es Metriken von NGINX Plus erhält, indem Sie die Netzwerkadresse der NGINX Plus-Instanz in einem Scrape_config- Abschnitt in der Prometheus-Konfigurationsdatei angeben.

Testen von Ratenbegrenzungen im Dry-Run-Modus

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"

Verbesserungen am Key-Value-Store

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 .

Unterstützung für Netzwerkbereiche

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

Ablauf-Timeouts pro Eintrag

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üllen
• expire – Auf die Anzahl der Millisekunden nach der Erstellung einstellen, nach der der Wert abläuft

Das 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

Dynamische Bandbreitenkontrolle

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.

Updates für das NGINX Plus-Ökosystem

NGINX JavaScript-Modul

Das NGINX JavaScript-Modul (njs) wurde auf Version 0.3.5 aktualisiert. Die wichtigsten Verbesserungen (kumulativ gegenüber früheren Versionen) sind:

• Unterstützung für Pfeilfunktionen (danke an 洪志道 [Hong Zhi Dao] und Artem S. Povalyukhin)
• Ein globales Prozessobjekt (besonders nützlich zum Lesen von Umgebungsvariablen)
• String.prototype.trim -Funktionen

Upgrade oder Testen von NGINX Plus

Wenn 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.