Annonce de NGINX Plus R19

Nous sommes heureux d'annoncer que NGINX Plus Release 19 (R19) est désormais disponible. NGINX Plus est le seul équilibreur de charge, cache de contenu, serveur Web et passerelle API tout-en-un . Basé sur NGINX Open Source, NGINX Plus inclut des fonctionnalités améliorées exclusives et un support primé. L’objectif principal de cette version est la surveillance, avec de nouvelles fonctionnalités qui la rendent plus granulaire et flexible, pour une fiabilité améliorée de vos applications à grande échelle.

Les nouvelles fonctionnalités de NGINX Plus R19 incluent :

• Surveillance plus flexible – Nous avons ajouté de nouvelles fonctionnalités pour une analyse plus précise et plus facile de votre écosystème NGINX Plus, notamment la collecte facultative de mesures distinctes pour les blocs d'emplacement , de nouvelles mesures sur l'activité de recherche DNS et la prise en charge de l'exportation au format Prometheus ainsi qu'au format JSON. Le tableau de bord NGINX Plus affiche les nouvelles mesures par emplacement et comporte de nouveaux onglets pour les mesures DNS et les mesures sur les clusters NGINX Plus.
• Mode d'exécution à sec pour tester les limites de débit – Définir les limites de débit correctes pour le trafic de production est difficile et très risqué – si vous vous trompez, vous pourriez avoir un impact sérieux sur l'expérience utilisateur d'une grande partie de vos utilisateurs. Avec le nouveau mode d’exécution à sec, vous pouvez comprendre l’effet de vos limites de débit sur le trafic de production sans les appliquer réellement.
• Améliorations apportées au magasin de clés-valeurs : vous pouvez désormais stocker des plages d’adresses IP dans le magasin de clés-valeurs avec des adresses individuelles et définir des délais d’expiration sur des entrées individuelles.
• Contrôle dynamique de la bande passante – Lors de la configuration des limites de bande passante, vous pouvez désormais définir le débit en tant que variable, ce qui vous permet d’appliquer différentes limites en fonction de n’importe quel attribut du trafic entrant.

Changements importants dans le comportement

• API obsolètes – NGINX Plus R13 (sorti en août 2017) a introduit la toute nouvelle API NGINX Plus pour la collecte de métriques et la reconfiguration dynamique des groupes en amont, remplaçant les API Status et Upstream Conf qui implémentaient auparavant ces fonctions. Comme annoncé à l'époque, les API obsolètes ont continué à être disponibles et prises en charge pendant une période significative, qui a pris fin avec NGINX Plus R16 . Si votre configuration inclut les directives status et/ou upstream_conf , vous devez les remplacer par la directive api dans le cadre de la mise à niveau vers R19.

  Pour obtenir des conseils et de l'aide sur la migration vers la nouvelle API NGINX Plus , veuillez consulter le guide de transition sur notre blog ou contacter notre équipe d'assistance.

• Nouveaux systèmes d’exploitation pris en charge –

  • Alpine 3.10
  • Debian 10 (« Buster »)
  • Ubuntu 19.04 (« Disco »)

• Les anciens systèmes d’exploitation ne sont plus pris en charge –

  • Debian 8 (« Jessie »)
  • Ubuntu 14.04 (« Trusty »)
  • Ubuntu 18.10 (« Cosmique »)

Pour plus d'informations sur les plates-formes prises en charge, consultez les spécifications techniques de NGINX Plus et des modules dynamiques .

Nouvelles fonctionnalités en détail

Les nouvelles fonctionnalités rendent la surveillance encore plus flexible

NGINX Plus R19 rend la surveillance encore plus flexible, en étendant à la fois les types de mesures que vous pouvez collecter et les façons dont vous pouvez les analyser.

Mesures par emplacement

L' API NGINX Plus fournit une large gamme de mesures de surveillance en temps réel, y compris plusieurs compteurs sur un serveur virtuel lorsque vous incluez la directive status_zone dans son bloc server{} . Avec NGINX Plus R19, vous pouvez désormais collecter des métriques pour des blocs d'emplacement individuels en plus (ou à la place) du bloc parent server{} , en ajoutant la directive status_zone à ces blocs d'emplacement . Cette surveillance plus fine vous permet de détecter plus rapidement les parties exactes de votre site Web qui génèrent des erreurs, pour un dépannage plus efficace.

La configuration suivante permet la collecte de métriques pour un site Web entier, ainsi que pour toutes les demandes adressées aux URI commençant par /admin/ .

Vous pouvez ensuite accéder aux métriques au point de terminaison http/location_zones .

$ curl http://localhost:8080/api/5/http/location_zones { "www_admin": { "requests": 3393, "réponses": { "1xx": 0, « 2xx » : 3307, « 3xx » : 81, « 4xx » : 5, « 5xx » : 0, "totale" : 3393 }, "rejeté": 0, "reçu" : 15403, « envoyé » : 835227 } }

Il est également possible de placer la directive status_zone dans un bloc if , mais notez que les métriques ne sont comptées qu'une seule fois pour un emplacement donné, et à partir de la dernière directive status_zone rencontrée pendant le traitement de la requête. La configuration suivante étend l'exemple précédent en collectant des métriques distinctes chaque fois qu'une demande à l'emplacement /admin/ inclut une chaîne de requête.

Mesures du résolveur DNS

L' API NGINX Plus a également été étendue avec des mesures permettant de suivre l'activité de recherche DNS, en particulier sur les types de requêtes DNS et les statuts de réponse. Pour collecter des métriques sur un groupe de serveurs DNS que NGINX Plus interroge pour les recherches de noms, ajoutez le paramètre status_zone à la directive resolver .

Vous pouvez ensuite accéder aux métriques au niveau du point de terminaison des résolveurs .

$ curl http://localhost:8080/api/5/resolvers { "internal_dns": { "requests": { "name": 132, « srv » : 0, "adresse": 0 }, "réponses": { "noerror": 130, "ancien": 0, « servfail » : 0, "nxdomaine": 0, "non imp": 0, "refusé" : 0, « expiration du délai » : 2, « inconnu » : 0 } } }

Mises à jour du tableau de bord de surveillance des activités en direct

Le tableau de bord de surveillance des activités en direct de NGINX Plus fournit un emplacement centralisé pratique pour le suivi des mesures collectées par l' API NGINX Plus . Le tableau de bord a été étendu dans NGINX Plus R19 pour inclure le nouveau résolveur et les mesures par emplacement décrites ci-dessus. En outre, il signale désormais des métriques relatives au partage de l'état d'exécution dans un cluster (comme activé avec le module de synchronisation de zone ), qui n'étaient auparavant accessibles que via l' API NGINX Plus .

Il y a deux onglets renommés et deux nouveaux onglets :

• Zones HTTP est le nouveau nom de l’onglet Zones du serveur . L'onglet affiche désormais des mesures sur les blocs d'emplacement ainsi que sur les blocs de serveur .
• HTTP Upstreams est le nouveau nom de l’onglet Upstreams . Cela apporte de la clarté lorsque les modules HTTP et TCP/UDP sont configurés.
• Le nouvel onglet Cluster affiche des métriques sur le partage d’état dans les clusters NGINX Plus.
• Le nouvel onglet Résolveurs affiche des mesures sur l’activité de recherche DNS.

Pour explorer le nouveau tableau de bord, visitez https://demo.nginx.com/ .

Nouveau module pour la surveillance de Prometheus

L' API NGINX Plus renvoie des métriques au format JSON, qui est un format courant et pratique pour l'intégration avec des solutions de surveillance externe et de gestion des performances des applications (APM). Vous pouvez désormais également exporter des métriques au format Prometheus, particulièrement populaire dans les environnements Kubernetes.

Le module Prometheus-njs expose les métriques Prometheus. Pour activer les métriques exportées :

1. Installez le module Prometheus-njs .
2. Configurer l' API NGINX Plus .

3. Configurez un emplacement dédié pour la collecte des métriques Prometheus dans le fichier de configuration NGINX Plus.

4. Configurez Prometheus pour obtenir des métriques de NGINX Plus en spécifiant l'adresse réseau de l'instance NGINX Plus dans une section scrape_config du fichier de configuration Prometheus.

Test des limites de débit en mode d'exécution à sec

NGINX Plus offre une approche très flexible de la limitation du débit. Plusieurs limites de débit peuvent être suivies et appliquées simultanément. L’application elle-même se décline en cinq formes différentes – notamment le report des demandes excessives, leur rejet pur et simple et l’autorisation d’une série de demandes sans restriction avant l’application – ainsi que des combinaisons de ces comportements. Pour une explication détaillée, consultez notre blog .

Bien que cette flexibilité puisse permettre une limitation de débit très précise, comment déterminer en premier lieu la limite de débit appropriée pour votre trafic ? Comment pouvez-vous savoir à l’avance si votre limite de débit prévue est trop élevée (auquel cas vos serveurs peuvent être surchargés) ou trop basse (auquel cas l’expérience utilisateur peut être affectée) ?

La meilleure source d'informations est le journal des erreurs NGINX Plus, où une entrée détaillée comme celle-ci est créée lorsque NGINX Plus retarde ou rejette une demande :

2019/09/03 11:42:12 [erreur] 57#57 : *339 limitation des demandes, excès : 0,600 par zone "my_limit", client : 172.17.0.1, serveur : www.exemple.com, requête : "GET / HTTP/1.1", hôte : "www.exemple.com:80"

L'entrée vous indique des informations utiles telles que le nombre de requêtes par milliseconde au-dessus du taux configuré que représente cette requête (le champ excédentaire ), la limite particulière qui a été dépassée (le champ zone ) et l'adresse IP du client (le champ client ). Mais ces informations ne sont utiles à des fins de planification que si vous pouvez les obtenir avant d'appliquer les limites de votre trafic.

NGINX Plus R19 ajoute cette capacité prédictive avec un mode « dry-run » pour la limitation du débit. Les entrées de journal sont créées normalement, mais les limites de débit ne sont pas appliquées. Pour activer le mode d’exécution à sec, incluez la nouvelle directive limit_req_dry_run dans le même bloc que la ou les directives limit_req .

Dans l'exemple suivant, les directives limit_req_zone définissent quatre limites de débit différentes, de 10 000 requêtes par seconde à 10 requêtes par seconde. Nous appliquons ces tarifs avec les directives limit_req dans le bloc d’emplacement racine (lignes 9 à 12), ainsi que la directive limit_req_dry_run pour désactiver l’application.

NGINX Plus écrit une entrée de journal, clairement marquée avec un run à sec , pour chaque demande qui dépasserait une limite de débit donnée. Dans notre analyse du journal, nous pouvons ensuite filtrer les entrées par le champ de zone pour déterminer laquelle des limites de débit nous donne le comportement souhaité.

2019/09/03 11:56:26 [erreur] 142#142 : *22282 requêtes de limitation, exécution à sec , excès : 1.000 par zone "1000rs", client : 172.17.0.1, serveur : www.exemple.com, requête : "GET / HTTP/1.1", hôte : "www.exemple.com:80"

Améliorations apportées au magasin de valeurs clés

Avec le magasin clé-valeur en mémoire pour NGINX Plus, vous pouvez utiliser l’ API NGINX Plus pour configurer dynamiquement la gestion du trafic en fonction des attributs de la demande. Les exemples de cas d’utilisation incluent la liste de refus dynamique des adresses IP , la limitation dynamique de la bande passante et la mise en cache des jetons d’authentification .

Prise en charge des plages réseau

NGINX Plus R19 étend le magasin clé-valeur en ajoutant la prise en charge des plages de réseaux IP (sous-réseaux) à la prise en charge existante des adresses IP individuelles. Cela signifie qu'une seule entrée dans le magasin clé-valeur peut correspondre à toutes les adresses IP d'une plage réseau, ce qui simplifie la configuration et vous fait gagner du temps car vous n'avez pas à ajouter individuellement les adresses qui composent une plage. Le magasin clé-valeur utilise la notation CIDR pour représenter les plages réseau. Par exemple, 192.168.13.0/24 représente les adresses 192.168.13.0 à 192.168.13.255. Les adresses et plages IPv4 et IPv6 sont prises en charge.

Pour activer les plages réseau, incluez le nouveau paramètre type=ip à la directive keyval_zone , comme dans la configuration suivante pour la liste de refus dynamique des adresses IP. Lorsque NGINX Plus effectue une recherche, toute adresse IP dans une plage réseau stockée dans le magasin clé-valeur renvoie une correspondance.

La ligne 2 spécifie que la variable $in_denylist est évaluée en effectuant une recherche dans le magasin de clés-valeurs de la liste de refus , en utilisant $remote_addr (l'adresse IP du client) comme clé. Le bloc if simple (lignes 8 à 10) rejette alors une demande lorsque l’adresse IP du client est dans la liste de refus.

La commande curl suivante appelle l’ API NGINX Plus pour créer une entrée dans le magasin clé-valeur pour la plage réseau mentionnée ci-dessus.

$ curl -X POST -d '{"192.168.13.0/24":"1"}' http://localhost:8080/api/5/http/keyvals/denylist

Délais d'expiration par entrée

Dans la section précédente, le paramètre timeout=24h de la directive keyval_zone sur la ligne 1 de denylist.conf signifie que chaque entrée dans le magasin de clés-valeurs de la liste de refus expire (et est supprimée du magasin) 24 heures après sa création.

Avec NGINX Plus R19 , vous pouvez remplacer le délai d'expiration par défaut (défini pour l'ensemble du magasin clé-valeur par le paramètre timeout ) par un délai d'expiration différent pour chaque entrée individuelle. Les délais d'expiration individuels peuvent être plus grands ou plus petits que la valeur par défaut.

Pour créer une entrée avec un délai d’expiration autre que celui par défaut, fournissez la valeur sous forme d’objet JSON avec deux champs :

• valeur – Régler sur la valeur souhaitée, dans ce cas1 pour remplir la variable $in_denylist
• expire – Définit le nombre de millisecondes après la création duquel la valeur expire

Le JSON suivant représente une entrée de liste de refus pour localhost (127.0.0.1) qui expire dans 1 heure (3 600 000 millisecondes).

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

La commande curl suivante crée cette entrée dans le magasin clé-valeur :

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

Contrôle dynamique de la bande passante

La directive limit_rate définit le débit (nombre d'octets par seconde) auquel NGINX Plus envoie la réponse à une requête HTTP, et la directive limit_rate_after définit le nombre d'octets que NGINX Plus envoie avant que cette limite ne soit appliquée. Avec NGINX Plus R19 , le paramètre de chaque directive peut être une variable plutôt qu'une valeur statique, permettant un contrôle dynamique de l'utilisation de la bande passante en fonction des attributs de la demande.

L'exemple de configuration suivant définit la bande passante en fonction de la version de TLS utilisée par le client, récompensant ainsi efficacement les navigateurs plus modernes avec des réponses plus rapides.

Dans les versions précédentes de NGINX Plus, vous pouviez limiter la bande passante en définissant la variable $limit_rate ; nous vous recommandons plutôt d'utiliser cette méthode plus simplifiée. Pour plus de détails, consultez la documentation de la directive limit_rate .

Les directives proxy_download_rate et proxy_upload_rate pour le trafic TCP/UDP acceptent désormais également un paramètre variable.

Pour une limitation de bande passante encore plus sophistiquée, vous pouvez utiliser des extensions de script telles que le module JavaScript NGINX (njs) pour implémenter une logique avancée et personnalisée permettant de déterminer la limite de bande passante appropriée pour une connexion donnée.

Mises à jour de l'écosystème NGINX Plus

Module JavaScript NGINX

Le module JavaScript NGINX (njs) a été mis à jour vers la version 0.3.5 . Les améliorations les plus notables (cumulatives des versions précédentes) sont :

• Prise en charge des fonctions fléchées (merci à 洪志道 [Hong Zhi Dao] et Artem S. Povalyukhin)
• Un objet de processus global (particulièrement utile pour lire les variables d'environnement)
• Fonctions String.prototype.trim

Mettre à niveau ou essayer NGINX Plus

Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer une mise à niveau vers NGINX Plus R19 dès que possible. Vous bénéficierez également d'un certain nombre de correctifs et d'améliorations supplémentaires, et cela aidera NGINX à vous aider lorsque vous aurez besoin de créer un ticket d'assistance.

Veuillez examiner attentivement les nouvelles fonctionnalités et les changements de comportement décrits dans cet article de blog avant de procéder à la mise à niveau.

Si vous n'avez pas essayé NGINX Plus, nous vous encourageons à l'essayer - pour la sécurité, l'équilibrage de charge et la passerelle API, ou en tant que serveur Web entièrement pris en charge avec des API de surveillance et de gestion améliorées. Vous pouvez commencer dès aujourd’hui avec une évaluation gratuite de 30 jours . Découvrez par vous-même comment NGINX Plus peut vous aider à fournir et à faire évoluer vos applications.