Si vous êtes responsable d’un service en production comptant un certain nombre d’utilisateurs, vous savez probablement à quel point il est pénible que les clients découvrent les problèmes avant vous. Chez Akita, nous voulons résoudre ce problème – c’est pourquoi nous avons créé notre nouveau module certifié NGINX Plus.
Dans cet article, nous aborderons les principaux aspects du module, notamment l’intérêt de prendre du recul par rapport aux journaux, les moyens de détecter et de corriger rapidement les problèmes dans l’ensemble de votre système, ainsi que la façon dont le nouveau module Akita rend cette fonctionnalité facilement accessible aux utilisateurs de NGINX.
Prendre du recul sur les journaux pour examiner les points de terminaison d’API
Aujourd’hui, d’innombrables développeurs se retrouvent dans une situation regrettable où leurs clients font de fait office de système de surveillance.
Ce n’est pas que les équipes de développement logiciel ne consignent pas les erreurs. Par exemple, si vous utilisez NGINX comme proxy inverse, vos journaux NGINX contiennent toutes sortes d’informations : horodatages, longueur et durée de traitement des requêtes, ainsi que codes d’état des réponses. Si vous avez le temps et la patience de les chercher, ces informations sont bien là.
Cependant, dans les systèmes qui traitent de nombreuses requêtes et réponses différentes, il est facile de se perdre dans un océan de journaux ! À moins d’avoir mis en place de manière proactive des tableaux de bord ou un autre type d’outil pour exploiter ces journaux, vous risquez de devoir parcourir des milliers, voire des millions, de lignes de journal afin d’identifier les problèmes potentiels et leur origine. Or, la mise en place de méthodes adaptées de visualisation et de surveillance peut prendre des semaines, des mois, voire des trimestres entiers. De plus, elles doivent souvent être mises à jour en même temps que le code.
Chez Akita, nous pensons qu’il est essentiel de prendre du recul par rapport aux journaux pour se concentrer sur les points de terminaison d’API. Les équipes logicielles peuvent ainsi obtenir rapidement une vue d’ensemble des problèmes et des points sensibles, tout en conservant le niveau de détail nécessaire pour en déterminer précisément la cause. Nous remédions à la surcharge d’informations liée à la supervision grâce à une solution de métriques prête à l’emploi, qui surveille automatiquement les indicateurs de latence et les erreurs, sans nécessiter de modification du code ni de création de tableaux de bord. Notre solution observe passivement le trafic des API et l’analyse automatiquement afin de fournir une supervision et des alertes pour chaque point de terminaison. Et surtout, les utilisateurs peuvent commencer à l’utiliser dans les 15 minutes suivant leur inscription.
Présentation du module certifié NGINX Plus d’Akita
Nous sommes ravis de vous présenter le module Akita, désormais disponible pour les utilisateurs de NGINX. Si vous utilisez NGINX comme serveur d’applications web, proxy inverse ou passerelle API, vous pouvez désormais envoyer votre trafic API à Akita pour analyse. Créez un compte Akita gratuit, installez le module et l’agent Akita, puis apportez une légère modification à votre fichier de configuration NGINX.
En quelques minutes, vous pourrez accéder à la console Akita pour consulter vos points de terminaison d’API, identifier les ralentissements et repérer les erreurs.

Le module certifié NGINX Plus d’Akita permet aux utilisateurs de NGINX de profiter des nombreux avantages d’Akita en complément de leur configuration NGINX existante. Akita capture le trafic issu de vos requêtes HTTP et en mesure la latence et les erreurs, tout en vous donnant une vue sur ce qui se passe en production grâce à des tableaux de bord prédéfinis.
Fonctionnement du module certifié NGINX Plus d’Akita
Examinons en détail le fonctionnement du module et le moment où il intervient. Tout d’abord, les requêtes sont traitées par NGINX en plusieurs « phases » : le processus commence par la lecture de la requête depuis le réseau, se poursuit par les réécritures et les contrôles d’accès, puis se termine par la génération de la réponse et des éventuelles entrées de journal. Le NGINX Plus Certified Module d’Akita intervient tardivement dans ce processus (lors de la pré-contenu phase, après des fonctionnalités telles que la réécriture des en-têtes), afin de voir la requête sous une forme aussi proche que possible de celle reçue par l’application. Akita vérifie chaque requête entrante pour déterminer si elle est marquée comme devant être surveillée, en fonction du serveur et de l’emplacement définis dans la configuration NGINX.
Remarque: comme pour les autres fonctionnalités et modules NGINX, vous pouvez activer Akita uniquement pour une partie de votre service web ou l’appliquer par défaut à tout ce que NGINX dessert.
Lors de la phase suivante, le module enregistre le corps de la requête et l’envoie à l’agent Akita dès que la requête a été entièrement reçue. Ce comportement est similaire à celui du module ngx_http_mirror, puisque les mêmes données sont transmises en parallèle à l’application et à l’agent Akita.
Lorsque NGINX ou un serveur en amont dispose d’une réponse prête, le module Akita enregistre cette réponse (jusqu’à 1 Mo) pendant qu’elle est retransmise au client. La réponse n’est pas retardée par cette mise en mémoire tampon, qui s’effectue dans un « filtre de contenu » NGINX capable de traiter chaque fragment du corps de la réponse dès qu’il devient disponible.
Une fois le temps de réponse du serveur connu et si la réponse est valide, celle-ci est alors répliquée vers l’agent Akita. L’agent associe la requête à la réponse, puis tente d’analyser le contenu de leur corps respectif. Ces données sont masquées localement par l’agent avant d’être envoyées à Akita pour analyse. Ainsi, Akita voit la structure du trafic de votre API, mais pas les valeurs précises envoyées par vos utilisateurs ou qui leur sont destinées.
Le module certifié NGINX Plus d’Akita déduit automatiquement vos points de terminaison à partir de cette trace du trafic applicatif, créant ainsi un modèle de votre API consultable et téléchargeable, et affichant automatiquement les informations relatives à la latence et aux erreurs. Il vous permet de définir des alertes en fonction du taux d’erreurs par point de terminaison, d’une latence élevée pour un point de terminaison spécifique ou même d’un volume d’appels anormalement élevé.
Pour chaque point de terminaison, le module certifié NGINX Plus d’Akita vous permet de consulter les éléments suivants :
- Le nombre d’appels d’API
- Répartition des codes de réponse HTTP
- Temps de réponse de votre serveur
Vous trouverez plus d’informations sur la configuration du module certifié NGINX Plus d’Akita ici.
Premiers pas avec le module certifié NGINX Plus d’Akita
Akita est actuellement en bêta ouverte. Vous pouvez vous inscrire à la bêta et obtenir des résultats en moins de 30 minutes.
À propos de l’auteur
Articles de blog associés

Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.

Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.