Enregistrement du trafic entre NGINX et les serveurs en amont sur CDN77

Quelle que soit la plateforme que vous utilisez, la journalisation est souvent une exigence essentielle pour le traitement des Big Data, les statistiques, les audits, les rapports clients et les transactions, ainsi que pour le débogage de la communication client-serveur et des problèmes éventuels.

Dans ce blog, nous abordons le rôle de la journalisation dans le débogage, où elle fournit l'outil ultime pour localiser les différents problèmes si courants dans les communications Internet.

La journalisation des communications client-serveur Web aide grandement à déboguer les problèmes éventuels liés à la version du navigateur, au réseau du client et aux fichiers auxquels on accède. Mais cela ne s’arrête pas là. Il existe une infinité de possibilités quant à ce qu'il faut enregistrer, en fonction entièrement de votre plateforme et de vos besoins.

Architecture de journalisation de NGINX

Lorsque vous exécutez un proxy inverse, un équilibreur de charge ou un réseau de diffusion de contenu (CDN), vous ajoutez un autre nœud au flux de communication entre le client et le serveur. Un serveur intermédiaire qui manipule des données, comme un proxy inverse, introduit souvent des problèmes inattendus.

En tant que proxy inverse, NGINX convertit la connexion du client au serveur Web (ou autre serveur d'applications) en deux connexions distinctes en mettant fin à la connexion du client et en en créant une nouvelle sur le serveur. La « division » en deux connexions crée également deux contextes distincts pour la journalisation, et NGINX prend en charge la journalisation pour eux de manière quelque peu différente.

• Pour le trafic entre le client et le proxy inverse, NGINX fournit à la fois un journal d’erreurs et un journal d’accès , qui enregistre les événements de traitement et les actions qui ne sont pas des erreurs.

  Vous activez le journal des erreurs avec la directive error_log et pouvez définir le niveau de gravité des erreurs à enregistrer.

  Vous activez le journal d'accès avec la directive access_log . La directive log_format associée vous permet de personnaliser le type d'informations incluses dans les journaux et le format des entrées du journal. Vous pouvez écrire les journaux dans un fichier, dans syslog ou les deux.

• Pour le trafic entre le proxy inverse et le serveur Web ou d'application (que NGINX appelle serveur en amont ), NGINX prend en charge le journal des erreurs. Il ne prend cependant pas en charge la journalisation des accès pour ce trafic.

  La seule façon de voir les événements sans erreur entre le serveur proxy et un serveur en amont est de définir le niveau de gravité dans le journal des erreurs sur debug . L’inconvénient de ce paramètre est que d’énormes quantités de données sont enregistrées. Cela ralentit le traitement des demandes et crée des fichiers très volumineux qui peuvent rapidement remplir l'espace de stockage. (Notez que vous devez également recompiler NGINX avec l'argument --with-debug sur la commande configure , car la prise en charge du débogage n'est pas activée par défaut.)

Notre solution de journalisation en amont

En tant que fournisseur de CDN, nous rencontrons souvent des serveurs en amont qui ne communiquent pas correctement avec nos serveurs proxy inverses et nos clients. Les messages de niveau de débogage dans le journal des erreurs ne fournissent pas toujours le type d’informations dont nous avons besoin pour résoudre un problème avec le serveur en amont.

La solution est vite devenue évidente : générer un journal d’accès en amont en ajoutant une fonction qui rassemble uniquement les informations essentielles de la communication entre le proxy inverse et les serveurs en amont.

L’idée générale est que NGINX appelle notre fonction à chaque fois qu’une demande est effectuée auprès d’un serveur en amont. Cela nous permet de programmer toute la logique liée à la journalisation en amont dans la fonction elle-même.

Le module standard ngx_http_upstream_module gère les requêtes en amont et nous avons besoin qu'il appelle la fonction pour nous. Le module ne prend actuellement pas en charge cette fonctionnalité, nous l'avons donc corrigé pour activer le rappel en cas de besoin.

La journalisation elle-même est gérée dans un module séparé que nous avons écrit, qui utilise la capacité de rappel de journal que nous avons ajoutée dans le module en amont corrigé. Le nouveau module définit une nouvelle directive upstream_log pour configurer la fonctionnalité de journalisation. La directive utilise le même analyseur que la directive access_log , de sorte que les données peuvent être écrites soit dans un fichier, soit envoyées à un serveur syslog à l'aide d'un socket.

Lorsque NGINX lit la directive upstream_log dans nginx.conf au démarrage, deux fonctions sont appelées :

• ngx_http_upstream_log_set_log , qui analyse la directive et prépare la structure du journal elle-même ( ngx_log_t ) en utilisant ngx_log_set_log en interne
• ngx_http_upstream_log_init (dans une étape de post-configuration), qui enregistre notre fonction de journalisation principale avec le module en amont

De cette façon, lorsqu’une requête doit être proxy en amont, tout est prêt. Le module en amont établit une connexion au serveur en amont et notre correctif garantit que la fonction de journalisation est appelée pour enregistrer les détails de la demande.

Le format du journal est intégré au module en amont. Nous avons toujours la possibilité d'ajouter la prise en charge de la configuration à l'aide de la directive log_format , mais ce n'est pas nécessaire pour notre cas d'utilisation.

Valeurs enregistrées en amont

La fonction de journalisation est appelée juste après la fermeture de la connexion au serveur en amont. Son argument est un pointeur vers une requête en cours de traitement (la structure ngx_http_ request_t ), qui permet à la fonction d'accéder et d'enregistrer toutes les données de la structure. Le champ en amont (pointeur vers ngx_http_upstream_t ) est particulièrement intéressant car il contient des données sur la requête en amont. Nous sommes particulièrement intéressés par :

• Le code d'état de la réponse d'origine
• La durée de la demande
• La valeur d'un en-tête HTTP dans la réponse ou l'en-tête de l'hôte

L'accès à l'ensemble de la structure de la demande est ce qui donne au module la flexibilité, car une grande variété d'informations peuvent être enregistrées.

Problèmes rencontrés

Nous avons initialement implémenté la fonctionnalité dans ngx_http_core_module . C'était suffisant pour un prototype, mais ce n'était pas une solution très propre, car cela pouvait compliquer les mises à jour et modifications futures. Finalement, nous avons séparé la fonction de journalisation en amont en un module autonome comme décrit dans Notre solution de journalisation en amont .

Bien sûr, il y a eu quelques problèmes de mise en œuvre. Plus particulièrement, à certains endroits, nous avons mal géré les chaînes ngx_str_t , par exemple en utilisant la fonction sprintf de la bibliothèque C au lieu de ngx_snprintf . Cela peut entraîner l’écriture de données non définies dans le journal en amont ou même une erreur de segmentation dans le thread de travail. Ces problèmes ont été résolus après un débogage et des tests approfondis à l’aide d’outils tels que Valgrind et AddressSanitizer.

Fonctionnalités NGINX utilisées dans CDN77

La principale raison pour laquelle CDN77 utilise NGINX est ses capacités de mise en cache. Le serveur CDN est un nœud introduit entre le client et le serveur Web (serveur en amont), transmettant les requêtes des clients et demandant les fichiers appropriés au serveur en amont. Lorsque le fichier est mis en cache, il est livré aux autres utilisateurs demandant le même fichier à partir du même emplacement.

« Fichiers servis localement » est l’une des fonctionnalités que nous utilisons pour que NGINX fournisse un fichier à partir du disque du serveur lorsqu’il reçoit une demande.

Certaines fonctionnalités et configurations supplémentaires sont nécessaires pour une mise en cache sécurisée. Nous utilisons SSL (TLS 1.3 avec 0-RTT) ou des jetons sécurisés qui peuvent être générés pour une adresse IP spécifique afin de protéger correctement le contenu.

Les autres fonctionnalités que nous utilisons incluent des pages d'erreur personnalisées pour nos clients, l'implémentation NGINX par défaut de l'agrafage OCSP et FastCGI pour PHP pour réduire le nombre de processus PHP requis.

Conclusion

Non seulement la journalisation en amont nous a aidé et continue de nous aider à résoudre divers problèmes, mais elle nous a également fourni une excellente occasion de nous plonger davantage dans les fonctionnalités de base de NGINX et de simplifier de nombreux autres projets que nous avons entrepris.

À propos de CDN77

CDN77 rend la diffusion de contenu meilleure et plus pratique dans le monde entier. Avec plus de 30 centres de données, nous sommes capables de mettre en cache et de diffuser efficacement du contenu partout dans le monde. Cela inclut le contenu statique de votre site Web, la distribution de logiciels, la vidéo à la demande (VoD) et la diffusion en direct via divers protocoles, tels que HLS ou MPEG-DASH à l'aide d'un moteur de diffusion dédié.

Démarrer avec CDN77 est très facile, rapide et direct. Inscrivez-vous pour un essai gratuit , créez une ressource CDN et utilisez l'URL CDN générée ou l'enregistrement CNAME personnalisé pour l'intégrer à votre site Web ou à votre solution de streaming. Toutes les fonctionnalités, paramètres et solutions personnalisées possibles garantissent que CDN77 répond à vos exigences.