Ankündigung von NGINX Plus R19

NGINX | 03. September 2019

Liam CrillySenior Director, Produktmanagement

Wir freuen uns, Ihnen mitteilen zu können, dass NGINX Plus Release 19 (R19) ab sofort verfügbar ist. NGINX Plus ist der einzige All-in-One-Load-Balancer, Content-Cache, Webserver und API-Gateway. NGINX Plus basiert auf NGINX Open Source und bietet exklusive erweiterte Funktionen sowie preisgekrönten Support. Ein Schwerpunkt dieses Releases liegt auf dem Monitoring. Neue Funktionen ermöglichen eine detailliertere und flexiblere Überwachung und erhöhen so die Zuverlässigkeit Ihrer Anwendungen bei der Skalierung.

Zu den neuen Funktionen in NGINX Plus R19 gehören:

Flexiblere Überwachung – Wir haben neue Funktionen hinzugefügt, die detailliertere Einblicke und eine einfachere Analyse Ihres NGINX Plus-Ökosystems ermöglichen. Dazu gehören die optionale separate Erfassung von Metriken für location-Blöcke, neue Metriken zur DNS-Lookup-Aktivität sowie die Unterstützung für den Export im Prometheus-Format und als JSON. Das NGINX Plus-Dashboard zeigt die neuen Metriken pro Location an und verfügt über neue Registerkarten für DNS-Metriken und Metriken zu NGINX Plus-Clustern.
Testmodus zum Prüfen von Ratenbegrenzungen – Die richtigen Ratenbegrenzungen für den Produktivdatenverkehr festzulegen, ist schwierig und sehr riskant – bei einer falschen Konfiguration könnte die Benutzererfahrung eines großen Teils Ihrer Benutzer erheblich beeinträchtigt werden. Mit dem neuen Testmodus können Sie nachvollziehen, wie sich Ihre Ratenbegrenzungen auf den Produktivdatenverkehr auswirken würden, ohne sie tatsächlich anzuwenden.
Verbesserungen am Schlüssel-Wert-Speicher – Sie können jetzt neben einzelnen IP-Adressen auch IP-Adressbereiche im Schlüssel-Wert-Speicher ablegen und für einzelne Einträge Ablaufzeiten festlegen.
Dynamische Bandbreitensteuerung – Beim Konfigurieren von Bandbreitenbegrenzungen können Sie die Rate jetzt als Variable festlegen. So lassen sich je nach Attribut des eingehenden Datenverkehrs unterschiedliche Grenzwerte anwenden.

Wichtige Verhaltensänderungen

Veraltete APIs – Mit NGINX Plus R13 (veröffentlicht im August 2017) wurde die völlig neue NGINX Plus API zur Erfassung von Metriken und zur dynamischen Neukonfiguration von Upstream-Gruppen eingeführt. Sie ersetzte die Status- und Upstream-Conf-APIs, die diese Funktionen zuvor bereitgestellt hatten. Wie seinerzeit angekündigt, blieben die veralteten APIs noch über einen längeren Zeitraum verfügbar und wurden weiterhin unterstützt. Dieser Zeitraum endete mit NGINX Plus R16. Wenn Ihre Konfiguration die Direktiven status und/oder upstream_conf enthält, müssen Sie diese im Rahmen des Upgrades auf R19 durch die Direktive api ersetzen. Hinweise und Unterstützung bei der Migration zur neuen NGINX Plus API finden Sie im Migrationsleitfaden in unserem Blog. Alternativ können Sie sich an unser Supportteam wenden.
Neue unterstützte Betriebssysteme –
- Alpine 3.10
- Debian 10 („Buster“)
- Ubuntu 19.04 („Disco“)
Ältere Betriebssysteme werden nicht mehr unterstützt –
- Debian 8 („Jessie“)
- Ubuntu 14.04 („Trusty“)
- Ubuntu 18.10 („Cosmic“)

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

Neue Funktionen im Detail

Neue Funktionen machen das Monitoring noch flexibler

NGINX Plus R19 macht das Monitoring noch flexibler und erweitert sowohl die Arten von Metriken, die Sie erfassen können, als auch die Möglichkeiten zu deren Analyse.

Metriken pro Location

Die NGINX Plus API bietet eine Vielzahl von Echtzeit-Überwachungsmetriken, darunter mehrere Zähler für einen virtuellen Server, wenn Sie die status_zone-Direktive in dessen server{}-Block einfügen. Mit NGINX Plus R19 können Sie nun zusätzlich zum (oder anstelle des) übergeordneten location-Block Metriken für einzelne server{}-Block erfassen, indem Sie diesen status_zone-Blöcken die location-Direktive hinzufügen. Dank dieser detaillierteren Überwachung können Sie schneller genau die Bereiche Ihrer Website ermitteln, die Fehler verursachen, und Probleme so effektiver beheben.

Die folgende Konfiguration ermöglicht die Erfassung von Metriken für eine gesamte Website sowie für alle Anfragen an URIs, die mit /admin/ beginnen.

Codebeispiel wird geladen…

Anschließend können Sie die Metriken über den Endpunkt http/location_zones abrufen.

$ curl http://localhost:8080/api/5/http/location_zones{
  "www_admin": {
    "requests": 3393,
    "responses": {
      "1xx": 0,
      "2xx": 3307,
      "3xx": 81,
      "4xx": 5,
      "5xx": 0,
      "total": 3393
    },
    "discarded": 0,
    "received": 15403,
    "sent": 835227
  }
}

Es ist auch möglich, die Direktive „status_zone“ innerhalb eines „if“-Blocks zu platzieren. Beachten Sie jedoch, dass Metriken für einen bestimmten Standort nur einmal gezählt werden, und zwar anhand der letzten während der Anfrageverarbeitung gefundenen Direktive „status_zone“. Die folgende Konfiguration erweitert das vorherige Beispiel, indem separate Metriken erfasst werden, wenn eine Anfrage an den Standort „/admin/“ eine Abfragezeichenfolge enthält.

Codebeispiel wird geladen…

Metriken des DNS-Resolvers

Die NGINX Plus-API wurde außerdem um Metriken zur Überwachung der DNS-Lookup-Aktivität erweitert, insbesondere in Bezug auf DNS-Anfragetypen und Antwortstatus. Um Metriken zu einer Gruppe von DNS-Servern zu erfassen, die NGINX Plus für Namensauflösungen abfragt, fügen Sie der Direktive status_zone den Parameter resolver hinzu.

Codebeispiel wird geladen…

Anschließend können Sie über den Endpunkt resolvers auf die Metriken zugreifen.

$ curl http://localhost:8080/api/5/resolvers{
  "internal_dns": {
    "requests": {
      "name": 132,
      "srv": 0,
      "addr": 0
    },
    "responses": {
      "noerror": 130,
      "formerr": 0,
      "servfail": 0,
      "nxdomain": 0,
      "notimp": 0,
      "refused": 0,
      "timedout": 2,
      "unknown": 0
    }
  }
}

Aktualisierungen am Dashboard zur Überwachung der Live-Aktivität

Das Dashboard zur Überwachung der Live-Aktivitäten von NGINX Plus bietet eine praktische zentrale Anlaufstelle für die Nachverfolgung der von der NGINX Plus API erfassten Metriken. Das Dashboard wurde in NGINX Plus R19 um die oben beschriebenen neuen Resolver- und standortspezifischen Metriken erweitert. Darüber hinaus zeigt es nun Metriken zur gemeinsamen Nutzung des Laufzeitstatus in einem Cluster an (wie durch das Modul „Zone Synchronization“ ermöglicht), die zuvor nur über die NGINX Plus API zugänglich waren.

Zwei Registerkarten wurden umbenannt und zwei neue hinzugefügt:

HTTP-Zonen ist der neue Name für die Registerkarte „Serverzonen“. Die Registerkarte zeigt jetzt Metriken zu location-Blöcken sowie zu server-Blöcken an.
HTTP-Upstreams ist der neue Name für die Registerkarte „Upstreams“. Dies sorgt für mehr Klarheit, wenn sowohl HTTP- als auch TCP/UDP-Module konfiguriert sind.
Die neue Registerkarte „Cluster“ zeigt Metriken zur gemeinsamen Nutzung von Zustandsinformationen in NGINX Plus-Clustern an.
Die neue Registerkarte „Resolver“ zeigt Metriken zur DNS-Abfrageaktivität an.

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

Screenshot des Dashboards zur Live-Aktivitätsüberwachung von NGINX Plus

Neues Modul für die Prometheus-Überwachung

Die NGINX Plus-API gibt Metriken im JSON-Format zurück, einem gängigen und praktischen Format für die Integration in externe Monitoring- und Application-Performance-Management-Lösungen (APM). Sie können Metriken jetzt auch im Prometheus-Format exportieren, das insbesondere in Kubernetes-Umgebungen beliebt ist.

Das Prometheus-njs-Modul stellt die Prometheus-Metriken bereit. So aktivieren Sie den Export der Metriken:

Installieren Sie das Prometheus-njs-Modul.
Konfigurieren Sie die NGINX Plus-API.
Konfigurieren Sie in der NGINX Plus-Konfigurationsdatei einen dedizierten Location-Block für die Erfassung von Prometheus-Metriken.
Codebeispiel wird geladen…
Konfigurieren Sie Prometheus so, dass Metriken von NGINX Plus abgerufen werden, indem Sie die Netzwerkadresse der NGINX Plus-Instanz in einem Abschnitt vom Typ „scrape_config“ in der Prometheus-Konfigurationsdatei angeben.

Testen von Ratenbegrenzungen im Probelaufmodus

NGINX Plus bietet einen äußerst flexiblen Ansatz zur Ratenbegrenzung. Mehrere Ratenbegrenzungen können gleichzeitig überwacht und durchgesetzt werden. Für die Durchsetzung selbst stehen fünf verschiedene Varianten zur Verfügung – darunter das Verzögern übermäßiger Anfragen, deren sofortige Ablehnung und das Zulassen einer kurzzeitigen Folge uneingeschränkter Anfragen vor der Durchsetzung – sowie Kombinationen dieser Verhaltensweisen. Eine ausführliche Erläuterung finden Sie in unserem Blog.

Diese Flexibilität ermöglicht zwar eine sehr differenzierte Ratenbegrenzung, doch wie ermitteln Sie überhaupt das passende Ratenlimit für Ihren Datenverkehr? Wie können Sie im Voraus feststellen, ob das geplante Ratenlimit zu hoch ist (sodass Ihre Server überlastet werden könnten) oder zu niedrig (sodass die Benutzererfahrung beeinträchtigt werden könnte)?

Die beste Informationsquelle ist das Fehlerprotokoll von NGINX Plus. Dort wird ein detaillierter Eintrag wie der folgende erstellt, wenn NGINX Plus eine Anfrage verzögert oder ablehnt:

2019/09/03 11:42:12 [error] 57#57: *339 limiting requests, excess: 0.600 by zone "my_limit", client: 172.17.0.1, server: www.example.com, request: "GET / HTTP/1.1", host: "www.example.com:80"

Der Eintrag liefert Ihnen nützliche Informationen, etwa um wie viele Anfragen pro Millisekunde diese Anfrage die konfigurierte Rate überschreitet (das Feld „excess“), welcher konkrete Grenzwert überschritten wurde (das Feld „zone“) und wie die IP-Adresse des Clients lautet (das Feld „client“). Für Planungszwecke sind diese Informationen jedoch nur dann hilfreich, wenn Sie sie erhalten können, bevor Sie die Begrenzungen für Ihren Datenverkehr tatsächlich durchsetzen.

NGINX Plus R19 bietet diese Vorhersagefunktion mit einem „Dry-Run“-Modus für die Ratenbegrenzung. Protokolleinträge werden wie gewohnt erstellt, die Ratenbegrenzungen werden jedoch nicht durchgesetzt. Um den Dry-Run-Modus zu aktivieren, fügen Sie die neue Direktive limit_req_dry_run in denselben Block wie die Direktive bzw. Direktiven limit_req ein.

Im folgenden Beispiel definieren die limit_req_zone-Direktiven vier verschiedene Ratenbegrenzungen, die von 10.000 Anfragen pro Sekunde bis hinunter zu 10 Anfragen pro Sekunde reichen. Wir wenden diese Raten mit den limit_req-Direktiven im Stamm-location-Block (Zeilen 9–12) an und verwenden zusätzlich die limit_req_dry_run-Direktive, um die Durchsetzung zu deaktivieren.

Codebeispiel wird geladen…

NGINX Plus schreibt für jede Anfrage, die ein bestimmtes Ratenlimit überschreiten würde, einen deutlich mit „dry run“ gekennzeichneten Protokolleintrag. Bei der Analyse des Protokolls können wir die Einträge dann nach dem Feld „zone“ filtern, um festzustellen, welches der Ratenlimits das gewünschte Verhalten liefert.

2019/09/03 11:56:26 [error] 142#142: *22282 limiting requests, dry run, excess: 1.000 by zone "1000rs", client: 172.17.0.1, server: www.example.com, request: "GET / HTTP/1.1", host: "www.example.com:80"

Verbesserungen am Schlüssel-Wert-Speicher

Mit dem In-Memory-Schlüssel-Wert-Speicher für NGINX Plus können Sie die NGINX Plus API verwenden, um die Datenverkehrssteuerung anhand von Attributen der Anfrage dynamisch zu konfigurieren. Beispiele für Anwendungsfälle sind das dynamische Sperren 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 um die Unterstützung von IP-Netzwerkbereichen (Subnetzen), zusätzlich zur bereits vorhandenen Unterstützung einzelner IP-Adressen. Dadurch kann ein einzelner Eintrag im Schlüssel-Wert-Speicher allen IP-Adressen in einem Netzwerkbereich entsprechen. Dies vereinfacht die Konfiguration und spart Zeit, da Sie die Adressen, aus denen sich ein Bereich zusammensetzt, 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 von 192.168.13.0 bis 192.168.13.255. Es werden sowohl IPv4- als auch IPv6-Adressen und -Adressbereiche unterstützt.

Um Netzwerkbereiche zu aktivieren, fügen Sie der Direktive type=ip den neuen Parameter keyval_zone hinzu, wie in der folgenden Konfiguration für die dynamische Sperrlistung von IP-Adressen gezeigt. Wenn NGINX Plus eine Suche durchführt, wird für jede IP-Adresse innerhalb eines im Schlüssel-Wert-Speicher gespeicherten Netzwerkbereichs eine Übereinstimmung gefunden.

Codebeispiel wird geladen…

Zeile 2 gibt an, dass die Variable $in_denylist durch eine Suche im Schlüssel-Wert-Speicher denylist ausgewertet wird, wobei $remote_addr (die IP-Adresse des Clients) als Schlüssel verwendet wird. Der einfache if-Block (Zeilen 8–10) lehnt dann eine Anfrage ab, wenn die IP-Adresse des Clients in der Sperrliste enthalten ist.

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

Ablaufzeitlimits 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 Sperrliste 24 Stunden nach seiner Erstellung abläuft (und aus dem Speicher entfernt wird).

Mit NGINX Plus R19 können Sie das Standard-Timeout (das für den gesamten Schlüssel-Wert-Speicher durch den Parameter timeout festgelegt wird) für jeden einzelnen Eintrag durch ein anderes Timeout überschreiben. Individuelle Timeouts können länger oder kürzer als der Standardwert sein.

Um einen Eintrag mit einem vom Standard abweichenden Timeout zu erstellen, geben Sie den Wert als JSON-Objekt mit zwei Feldern an:

value – Auf den gewünschten Wert setzen, in diesem Fall 1, um die Variable $in_denylist zu befüllen
expire – Legen Sie die Anzahl der Millisekunden fest, nach denen der Wert ab seiner Erstellung abläuft.

Das folgende JSON stellt einen Sperrlisteneintrag für localhost (127.0.0.1) dar, der nach 1 Stunde (3.600.000 Millisekunden) abläuft.

{
  "127.0.0.1": {
    "value": "1",
    "expire": 3600000
  }
}

Der folgende curl-Befehl erstellt diesen Eintrag im Schlüssel-Wert-Speicher:

$ curl -X POST -d '{"127.0.0.1":{"value":"1","expire":3600000}}' http://localhost:8080/api/5/http/keyvals/denylist

Dynamische Bandbreitensteuerung

Die Direktive „limit_rate“ legt die Übertragungsrate (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 diese Begrenzung angewendet wird. Ab NGINX Plus R19 kann der Parameter jeder Direktive eine Variable anstelle eines statischen Werts sein. Dadurch lässt sich die Bandbreitennutzung anhand von Attributen der Anfrage dynamisch steuern.

Die folgende Beispielkonfiguration legt die Bandbreite entsprechend der vom Client verwendeten TLS-Version fest, sodass modernere Browser schnellere Antworten erhalten.

Codebeispiel wird geladen…

In früheren Versionen von NGINX Plus konnten Sie die Bandbreite begrenzen, indem Sie die Variable $limit_rate festlegten. Wir empfehlen jedoch, stattdessen diese einfachere Methode zu verwenden. Weitere Informationen finden Sie in der Dokumentation zur Direktive limit_rate.

Die Direktiven proxy_download_rate und proxy_upload_rate für TCP/UDP-Datenverkehr 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 Ermittlung der geeigneten Bandbreitenbegrenzung für eine bestimmte Verbindung zu implementieren.

Aktualisierungen im NGINX Plus-Ökosystem

NGINX-JavaScript-Modul

Das NGINX-JavaScript-Modul (njs) wurde auf Version 0.3.5 aktualisiert. Zu den wichtigsten Verbesserungen (einschließlich der Verbesserungen aus früheren Versionen) gehören:

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

NGINX Plus upgraden oder testen

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich ein Upgrade auf NGINX Plus R19 durchzuführen. Dadurch erhalten Sie außerdem eine Reihe zusätzlicher Fehlerbehebungen und Verbesserungen, und NGINX kann Sie besser unterstützen, wenn Sie ein Support-Ticket erstellen müssen.

Bitte lesen Sie sich vor dem Upgrade sorgfältig die in diesem Blogbeitrag beschriebenen neuen Funktionen und Verhaltensänderungen durch.

Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es selbst zu testen – für Sicherheit, Lastverteilung und als API-Gateway oder als vollständig unterstützten Webserver mit erweiterten Überwachungs- und Verwaltungs-APIs. Starten Sie noch heute mit einer kostenlosen 30‑Tage-Testversion. Überzeugen Sie sich selbst davon, wie NGINX Plus Sie bei der Bereitstellung und Skalierung Ihrer Anwendungen unterstützen kann.

Ausgewählte Blogbeiträge

Aktuelle Trends bei Cloud-nativen Technologien, Platform Engineering und KI

Vollständiges Lifecycle-Management für die Bereitstellung von Apps und APIs mit F5 NGINX One

Moderne Anwendungsbereitstellung vereinfachen: Neun Monate F5 NGINX One

Schlagwörter: DNS