Annonce de NGINX Plus R19

Liam CrillyDirecteur senior de la gestion des produits

Nous avons le plaisir d’annoncer la disponibilité de NGINX Plus Release 19 (R19). NGINX Plus est la seule solution tout-en-un combinant équilibreur de charge, cache de contenu, serveur web et passerelle API. Basé sur NGINX Open Source, NGINX Plus inclut des fonctionnalités avancées exclusives et une assistance primée. Cette version met principalement l’accent sur la surveillance, avec de nouvelles fonctionnalités qui la rendent plus granulaire et flexible afin d’améliorer la fiabilité 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 obtenir des informations plus détaillées et faciliter l’analyse de votre écosystème NGINX Plus, notamment la collecte séparée facultative des métriques pour les blocs location ainsi que de nouvelles métriques sur l’activité de recherche DNS et la prise en charge de l’exportation au format Prometheus en plus du format JSON. Le tableau de bord NGINX Plus affiche les nouvelles métriques par emplacement et comporte de nouveaux onglets pour les métriques DNS et celles relatives aux clusters NGINX Plus.
• Mode de simulation pour tester les limites de débit – Définir des limites de débit adaptées au trafic de production est une tâche difficile et très risquée : une erreur pourrait sérieusement nuire à l’expérience d’une grande partie de vos utilisateurs. Grâce au nouveau mode de simulation, vous pouvez évaluer l’effet de vos limites de débit sur le trafic de production sans les appliquer réellement.
• Améliorations apportées au magasin clé-valeur – Vous pouvez désormais stocker des plages d’adresses IP dans le magasin clé-valeur en plus des adresses individuelles, et définir une date d’expiration pour chaque entrée.
• 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 sous forme de variable, ce qui vous permet d’appliquer différentes limites en fonction de n’importe quel attribut du trafic entrant.

Modifications importantes du comportement

• API obsolètes – NGINX Plus R13 (publié en août 2017) a introduit la toute nouvelle API NGINX Plus pour la collecte de métriques et la reconfiguration dynamique des groupes de serveurs en amont, remplaçant les API Status et Upstream Conf qui assuraient auparavant ces fonctions. Comme annoncé à l’époque, les API obsolètes sont restées disponibles et prises en charge pendant une période prolongée, qui a pris fin avec NGINX Plus R16. Si votre configuration comprend 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 concernant la migration vers la nouvelle API NGINX Plus, consultez le guide de transition sur notre blog ou contactez 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 (« Cosmic »)

Pour plus d’informations sur les plateformes prises en charge, consultez les spécifications techniques de NGINX Plus et des modules dynamiques.

Présentation détaillée des nouvelles fonctionnalités

De nouvelles fonctionnalités rendent la surveillance encore plus flexible

NGINX Plus R19 rend la supervision encore plus flexible, en élargissant à la fois les types de métriques que vous pouvez collecter et les façons dont vous pouvez les analyser.

Métriques par emplacement

L’API NGINX Plus fournit un large éventail de métriques de surveillance en temps réel, notamment plusieurs compteurs relatifs à 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 chaque bloc « location », en complément (ou à la place) du bloc « server{} » parent, en ajoutant la directive « status_zone » à ces blocs « location ». Cette surveillance plus granulaire vous permet de repérer plus rapidement les parties précises de votre site web qui génèrent des erreurs, afin de résoudre les problèmes plus efficacement.

La configuration suivante permet de collecter des métriques pour l’ensemble d’un site web, ainsi que pour toutes les requêtes adressées à des URI commençant par « /admin/ ».

Chargement de l’exemple de code…

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

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

Il est également possible de placer la directive « status_zone » dans un bloc « if ». Notez toutefois que les métriques ne sont comptabilisées qu’une seule fois pour un emplacement donné, à partir de la dernière directive « status_zone » rencontrée lors du traitement de la requête. La configuration suivante complète l’exemple précédent en collectant des métriques distinctes chaque fois qu’une requête adressée à l’emplacement « /admin/ » contient une chaîne de requête.

Chargement de l’exemple de code…

Métriques du résolveur DNS

L’API NGINX Plus a également été enrichie de métriques permettant de suivre l’activité de résolution DNS, notamment les types de requêtes DNS et les états des réponses. Pour collecter des métriques sur un groupe de serveurs DNS que NGINX Plus interroge pour résoudre des noms, ajoutez le paramètre « status_zone » à la directive « resolver ».

Chargement de l’exemple de code…

Vous pouvez ensuite accéder aux métriques via le point de terminaison resolvers.

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

Mises à jour du tableau de bord de surveillance de l’activité en direct

Le tableau de bord de surveillance de l’activité en temps réel de NGINX Plus offre un emplacement centralisé pratique pour suivre les métriques collectées par l’API NGINX Plus. Dans NGINX Plus R19, le tableau de bord a été enrichi afin d’inclure les nouvelles métriques du résolveur et les métriques propres à chaque emplacement mentionnées ci-dessus. En outre, il présente désormais les métriques relatives au partage de l’état d’exécution au sein d’un cluster (activé à l’aide du module Zone Synchronization), qui n’étaient auparavant accessibles que par l’intermédiaire de l’API NGINX Plus.

Deux onglets ont été renommés et deux nouveaux onglets ont été ajoutés :

• Zones HTTP est le nouveau nom de l’onglet « Zones de serveurs ». Cet onglet affiche désormais des métriques sur les blocs location ainsi que sur les blocs server.
• Upstreams HTTP est le nouveau nom de l’onglet Upstreams. Cette appellation permet d’éviter toute ambiguïté lorsque les modules HTTP et TCP/UDP sont tous deux 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 métriques sur l’activité de recherche DNS.

Pour découvrir le nouveau tableau de bord, rendez-vous sur https://demo.nginx.com/.

Nouveau module de surveillance Prometheus

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

Le module Prometheus-njs expose les métriques Prometheus. Pour activer l’exportation des métriques :

1. Installez le module Prometheus-njs.
2. Configurez l’API NGINX Plus.
3. Configurez un emplacement dédié à la collecte des métriques Prometheus dans le fichier de configuration de NGINX Plus.

   Chargement de l’exemple de code…

4. Configurez Prometheus pour collecter les métriques de NGINX Plus en indiquant l’adresse réseau de l’instance NGINX Plus dans une section scrape_config du fichier de configuration de Prometheus.

Tester les limites de débit en mode simulation

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 de ces limites peut elle-même prendre cinq formes différentes, notamment le report des requêtes excessives, leur rejet pur et simple et l’autorisation d’une rafale de requêtes sans restriction avant l’application des limites, ainsi que diverses combinaisons de ces comportements. Pour une explication détaillée, consultez notre blog.

Si cette flexibilité permet de définir une limitation de débit très précise, comment déterminer au départ la limite appropriée pour votre trafic ? Comment savoir à l’avance si la limite de débit prévue est trop élevée (auquel cas vos serveurs risquent d’être saturés) ou trop basse (auquel cas l’expérience utilisateur risque d’en pâtir) ?

La meilleure source d’informations est le journal des erreurs de NGINX Plus, dans lequel une entrée détaillée comme celle qui suit est créée lorsque NGINX Plus retarde ou rejette une requête :

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"

Cette entrée fournit des informations utiles, comme le nombre de requêtes par milliseconde au-delà du taux configuré que représente cette requête (le champ « excess »), la limite précise qui a été dépassée (le champ « zone ») et l’adresse IP du client (le champ « client »). Toutefois, ces informations ne sont utiles à des fins de planification que si vous pouvez les obtenir avant d’appliquer effectivement les limites à votre trafic.

NGINX Plus R19 ajoute cette fonctionnalité prédictive grâce à un mode « simulation » 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 simulation, ajoutez 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, allant de 10 000 requêtes par seconde à 10 requêtes par seconde. Nous appliquons ces débits à l’aide des directives limit_req dans le bloc location racine (lignes 9 à 12), ainsi que de la directive limit_req_dry_run pour désactiver leur application.

Chargement de l’exemple de code…

NGINX Plus écrit une entrée de journal, clairement marquée par « dry run », pour chaque requête qui dépasserait une limite de débit donnée. Lors de l’analyse du journal, nous pouvons ensuite filtrer les entrées selon le champ zone afin de déterminer laquelle des limites de débit produit le comportement souhaité.

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"

Améliorations apportées au magasin clé-valeur

Grâce au magasin clé-valeur en mémoire de NGINX Plus, vous pouvez utiliser l’API NGINX Plus pour configurer dynamiquement la gestion du trafic en fonction des attributs de la requête. Voici quelques exemples d’utilisation : ajout dynamique d’adresses IP à une liste de blocage, limitation dynamique de la bande passante, et 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) à celle déjà existante des adresses IP individuelles. Ainsi, une seule entrée du 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 comprises entre 192.168.13.0 et 192.168.13.255. Les adresses et plages IPv4 et IPv6 sont prises en charge.

Pour activer les plages réseau, ajoutez le nouveau paramètre « type=ip » à la directive « keyval_zone », comme dans la configuration suivante permettant de gérer dynamiquement une liste de blocage d’adresses IP. Lorsque NGINX Plus effectue une recherche, toute adresse IP appartenant à une plage réseau stockée dans le magasin clé-valeur produit une correspondance.

Chargement de l’exemple de code…

La ligne 2 indique que la variable « $in_denylist » est évaluée en effectuant une recherche dans le magasin clé-valeur « denylist », en utilisant $remote_addr (l’adresse IP du client) comme clé. Le simple bloc if (lignes 8 à 10) rejette ensuite la requête lorsque l’adresse IP du client figure dans la liste de refus.

La commande curl suivante appelle l’API NGINX Plus afin de 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 » à la ligne 1 du fichier denylist.conf signifie que chaque entrée du magasin clé-valeur de la liste de blocage 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 différent pour chaque entrée. Les délais d’expiration individuels peuvent être supérieurs ou inférieurs à la valeur par défaut.

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

• value – Définissez la valeur souhaitée, dans ce cas 1 pour renseigner la variable $in_denylist variable
• expire – Définissez le nombre de millisecondes après lequel la valeur expire à compter de sa création

Le JSON suivant représente une entrée de liste de blocage pour localhost (127.0.0.1) qui expire au bout d’une heure (3 600 000 millisecondes).

{
  "127.0.0.1": {
    "value": "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":{"value":"1","expire":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, tandis que la directive limit_rate_after définit le nombre d’octets envoyés par NGINX Plus avant l’application de cette limite. Avec NGINX Plus R19, le paramètre de chaque directive peut être une variable plutôt qu’une valeur statique, ce qui permet de contrôler dynamiquement l’utilisation de la bande passante en fonction des attributs de la requête.

L’exemple de configuration suivant définit la bande passante en fonction de la version de TLS utilisée par le client, ce qui permet aux navigateurs plus récents de bénéficier de réponses plus rapides.

Chargement de l’exemple de code…

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 désormais d’utiliser cette méthode plus simple. Pour plus de détails, consultez la documentation relative à la directive « limit_rate ».

Les directives proxy_download_rate et proxy_upload_rate relatives au 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) afin d’implémenter une logique personnalisée avancé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 (cumulées depuis les versions précédentes) sont les suivantes :

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

Mettez à niveau ou essayez NGINX Plus

Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à NGINX Plus R19 dès que possible. Vous bénéficierez également de plusieurs correctifs et améliorations supplémentaires, ce qui permettra à NGINX de mieux vous aider lorsque vous aurez besoin d’ouvrir 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 encore essayé NGINX Plus, nous vous invitons à le faire, que ce soit pour la sécurité, l’équilibrage de charge et la passerelle d’API, ou comme serveur web entièrement pris en charge, doté d’API avancées de surveillance et de gestion. 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 à déployer vos applications et à les faire évoluer.

À propos de l’auteur

Liam CrillyDirecteur senior de la gestion des produits

Autres articles de Liam Crilly