Tout le monde sait que c'est toujours bon signe lorsque votre équipe DevOps est légèrement détendue, calme et confiante. Cela signifie que le projet est sous contrôle et que tout fonctionne comme il se doit. Et quand ils se sentent concernés, c'est une raison pour que tout le monde s'inquiète. Surtout si la journalisation des erreurs du projet est un facteur de troubles.
Aujourd'hui, je souhaite partager l'histoire du problème lié à l'énorme différence entre les données des analyses Cloudflare et NEL que nous avons découvertes dans le cadre de l'un de nos plus grands projets (une infrastructure blockchain gérant plus de 800 millions de requêtes par jour). Ne vous inquiétez pas, il y a une fin heureuse.
Voici ce qui s'est passé.
Dans ma routine quotidienne en tant que responsable technique et DevOps senior, il n'y a rien de spécial. Mon travail doit être ennuyeux, mais je tombe parfois sur des perturbations et des imperfections qui m'incitent à rechercher le problème et à le résoudre. Oui, parfois, avant de résoudre un problème, il faut le trouver.
En parcourant les rapports sur l'état des projets dans Cloudflare, j'ai remarqué un nombre impressionnant de 408 erreurs sur le site Web, environ 20 millions au cours des dernières 24 heures. Cela m'a intrigué.
C'en était beaucoup trop, surtout si notre infrastructure était en pleine ébullition en raison d'autres types de pannes si au moins 1/10 000 de ces 408 erreurs se produisaient. Comme nous obtenons les données non pas directement sur le site Web, mais via Cloudflare, j'ai pensé que je devais examiner cette affaire de plus près. La question que je devais résoudre : dois-je m'inquiéter des chiffres de Cloudflare, si tout allait bien du côté de l'infrastructure ? Comment puis-je obtenir des statistiques vraiment fiables sur notre journalisation des erreurs ? Existe-t-il un meilleur outil pour suivre cela ?
Spoiler : bien sûr, il existait un meilleur instrument pour le suivi des erreurs, car les « erreurs » de Cloudflare ne sont pas ce qu'elles étaient censées être. Et je vais te le prouver maintenant.
Comme vous le savez peut-être, Cloudflare Analytics est une plateforme d'analyse Web qui fournit des informations en temps réel sur le trafic, les pages vues et le comportement des visiteurs. Il collecte des données à l'aide de diverses méthodes, notamment des balises JavaScript, des balises Web et des journaux de serveur. Cloudflare Analytics fournit de nombreuses informations sur les performances des sites Web, notamment les temps de chargement des pages, les taux de rebond et les taux de conversion. Il permet également aux utilisateurs d'explorer des indicateurs spécifiques pour obtenir une vue plus détaillée des performances du site Web. En général, cela suffit au propriétaire du site Web pour avoir une idée générale de ce qui se passe.
Cloudflare utilise diverses méthodes, notamment la surveillance des utilisateurs réels (RUM), la surveillance synthétique et la surveillance côté serveur. Le RUM consiste à suivre les interactions des utilisateurs avec un site Web en temps réel, à l'aide de balises JavaScript ou de plugins de navigateur. La surveillance synthétique consiste à simuler les interactions des utilisateurs avec un site Web à partir de différents emplacements et appareils. La surveillance côté serveur implique le suivi des erreurs et des indicateurs de performance côté serveur, tels que les temps de réponse et la disponibilité du serveur. Ces méthodes supposent à la fois le traitement des données et l'utilisation d'événements bruts.
Les erreurs 408 sont généralement causées par des délais d'expiration du réseau, qui se produisent lorsqu'un serveur met trop de temps à répondre à une demande d'un client. Ces erreurs peuvent être causées par divers facteurs, notamment la lenteur des connexions réseau, la surcharge du serveur ou un code mal optimisé. Dans notre cas, nous avons optimisé l'infrastructure de ce projet plus tôt, de sorte que tous les principaux facteurs ont été exclus des causes d'apparition.
L'une des raisons pour lesquelles Cloudflare signale plus de 408 erreurs est qu'il est plus sensible aux délais d'expiration du réseau que les autres systèmes de journalisation. Il utilise un réseau mondial de serveurs et de centres de données pour collecter des données provenant d'un large éventail de sites et d'appareils, et ce système peut être plus susceptible de détecter les délais d'expiration du réseau qui se produisent dans des sites distants ou mal connectés. D'autres systèmes de journalisation peuvent ne pas être aussi sensibles à ces types d'erreurs, ou ils peuvent être configurés pour les ignorer.
Une autre explication possible est que Cloudflare signale les 408 erreurs, tandis que d'autres systèmes de journalisation filtrent peut-être certaines de ces erreurs. Par exemple, certains systèmes de journalisation peuvent être configurés pour exclure 408 erreurs qui se produisent pendant les périodes de trafic élevé ou de surcharge du serveur, car ces erreurs peuvent être considérées comme « attendues » ou « normales » dans ces circonstances. Cloudflare, en revanche, peut signaler les 408 erreurs, quel que soit le contexte dans lequel elles se produisent.
Il convient également de noter que le nombre d'erreurs 408 signalées peut être affecté par des facteurs tels que le trafic du site Web, la charge du serveur et l'état du réseau. Par exemple, un site Web qui enregistre des niveaux de trafic élevés peut être plus susceptible de présenter des erreurs 408, car le serveur peut être surchargé ou incapable de répondre aux demandes entrantes. De même, un site Web hébergé sur un serveur lent ou mal connecté peut être plus susceptible de connaître des délais d'expiration du réseau et des erreurs 408.
N'importe laquelle de ces raisons pourrait nous faire oublier la vérité. Nous avons donc décidé de rechercher une autre solution pour le suivi des erreurs et avons trouvé la plus fiable de toutes au moment de la prise de décision.
Enregistrement des erreurs réseau (NEL) est un nouvel en-tête HTTP conçu pour fournir un moyen d'enregistrer et d'analyser les erreurs réseau qui se produisent sur les sites Web. NEL peut être utilisé pour surveiller les erreurs réseau telles que les requêtes échouées, les échecs de résolution DNS et les délais de connexion, et pour diagnostiquer et résoudre rapidement les problèmes susceptibles d'entraîner une mauvaise expérience utilisateur et une perte de revenus. C'est un outil facile à produire, open source et fiable. Chaque caractéristique correspond à mes goûts en matière de DevOps.
La spécification NEL est une norme du W3C qui définit la manière dont les navigateurs Web doivent gérer l'en-tête NEL. L'en-tête NEL configure un client (navigateur) pour envoyer des rapports [d'erreur] réseau au point de terminaison d'en-tête fourni par Report-To. C'est comme un lien vers un formulaire de commentaires, où tout utilisateur peut laisser des commentaires sur le site. Mais il est destiné aux rapports automatiques.
Les projets peuvent bénéficier de la NEL de plusieurs manières. En surveillant les erreurs réseau, les développeurs peuvent rapidement identifier et résoudre les problèmes susceptibles d'entraîner une mauvaise expérience utilisateur ou une perte de revenus. Ils peuvent également utiliser les données NEL pour identifier les tendances en matière d'occurrence d'erreurs et optimiser leurs sites Web ou leurs applications afin de réduire la fréquence des erreurs.
L'un des principaux avantages du NEL est qu'il permet aux développeurs Web de collecter des données plus complètes sur les erreurs réseau. Traditionnellement, les développeurs s'appuyaient sur la journalisation des erreurs côté client ou côté serveur pour diagnostiquer les erreurs réseau, mais ces méthodes ne parvenaient souvent pas à capturer toutes les erreurs. Grâce à NEL, les développeurs peuvent voir les erreurs qui se produisent côté client et côté serveur, et ils peuvent utiliser ces informations pour identifier des modèles et des tendances en matière d'occurrence d'erreurs.
Un autre avantage de NEL est qu'il fournit un format standard pour la journalisation des erreurs réseau, ce qui permet aux développeurs d'analyser et de comparer plus facilement les données provenant de différentes sources. Cela peut être particulièrement utile pour les grands projets impliquant de nombreux développeurs ou pour les entreprises possédant plusieurs sites Web ou applications.
Pour utiliser NEL, les développeurs Web doivent inclure l'en-tête NEL dans leurs réponses HTTP. L'en-tête contient un URI qui pointe vers un point de terminaison du rapport, où le navigateur envoie l'objet JSON décrivant l'erreur réseau. Les développeurs peuvent ensuite utiliser ces informations pour analyser et diagnostiquer les erreurs réseau.
L'un des défis de l'utilisation de NEL est qu'elle nécessite un système principal pour traiter et stocker les rapports d'erreurs. Les développeurs doivent configurer un point de terminaison capable de gérer et de stocker les rapports d'erreurs, et ils doivent disposer d'un système pour analyser les données et agir en conséquence.
En utilisant NEL, vous pouvez rapidement diagnostiquer et résoudre les problèmes susceptibles d'entraîner une mauvaise expérience utilisateur et une perte de revenus. Vous pouvez également optimiser vos projets afin de réduire la fréquence des erreurs au fil du temps. Et dans notre cas, nous avions besoin de NEL pour comparer l'image de 408 erreurs fournie par Cloudflare et trouver une seule vérité sur laquelle s'appuyer.
Après avoir implémenté NEL, nous obtenons à coup sûr une image beaucoup plus réaliste de ce qui se passait. Nous avons également présenté cette solution au client et avons reçu une nouvelle salve d'applaudissements.
Le NEL Grafana a indiqué que tout était calme et net, avec environ 400 erreurs qui n'ont rien changé pour une infrastructure de 800 millions de demandes par jour.
Les deux derniers jours nous ont montré le nombre correct d'erreurs fiables, car nous les obtenons directement sur le site Web, et non par l'intermédiaire d'un fournisseur tiers.
Cette petite histoire nous montre à quel point il est important de comprendre les objectifs de nos instruments plutôt que de les utiliser aveuglément et sans réfléchir. Une autre leçon que vous pouvez en tirer est que la solution, même au problème le plus dangereux, peut être un outil simple et pratique, et non une sorte de Saint Graal.
Nous apprécions NEL pour son démarrage, son explicabilité et sa fiabilité. Ce sont des fonctionnalités que nous apprécions dans toutes nos solutions. C'est la véritable voie vers un suivi et une analyse efficaces : évitez les boîtes noires et les solutions tierces fermées et optez pour des instruments transparents et ouverts.
Et vous serez aussi calme qu'un DevOps professionnel.
.jpg)
.jpg)
