Le mardi 8 juin, le Content Delivery Network Fastly a connu une panne qui a rendu de larges pans du Web indisponibles pendant près d’une heure. Pour se concentrer sur le positif, cette panne peut servir de signal d’alarme pour les équipes d’observabilité, car elle montre à quel point les sites modernes dépendent de ressources échappant à leur contrôle immédiat, et à quel point il est difficile d’« observer » ce genre de problèmes avec une Observabilité incomplète. mentalité. Dans cet article de blog, je parlerai de la panne Fastly, examinerai comment les technologies de surveillance traditionnelles auraient répondu à cette panne et montrerai comment adopter Digital Experience Monitoring au sein de votre pratique d’observabilité est crucial pour détecter et répondre à ces types de problèmes.
À l’intérieur d’une panne de CDN
Rapidement est un Réseau de diffusion de contenu (CDN). Alors que les CDN d’aujourd’hui remplissent de nombreuses fonctions différentes, leur tâche principale consiste à mettre en cache des copies du contenu ou des ressources d’un site Web dans des centres de données du monde entier, de sorte que ces données soient géographiquement plus proches des visiteurs d’un site Web lorsqu’ils en font la demande, ainsi réduire la latence et améliorer les performances. Les CDN le font en s’asseyant « devant » un site Web ou une API. Par exemple, lorsque quelqu’un accède à splunk.com, les requêtes pour les images, CSS, polices de ce site et peut-être même son balisage HTML sont toutes servies par le CDN au lieu du serveur d’origine.
Dans le diagramme ci-dessous, nous pouvons voir comment le CDN se situe entre le visiteur du site et le serveur d’origine. Lorsque le navigateur demande main.js, le CDN a déjà une copie et la renvoie plus rapidement que le serveur d’origine ne l’aurait fait. Lorsque le navigateur effectue un appel API, le CDN transmet cette demande au serveur d’origine.
Mardi, en raison d’un problème interne, Fastly n’a pu répondre à aucune demande. Ces demandes n’ont pas été transmises au serveur d’origine, il n’a donc pas pu non plus traiter ces demandes. Le schéma ci-dessous illustre cette répartition :
Qu’est-ce qu’un utilisateur expérimente lors d’une panne de CDN
L’équipe Splunk Observability dispose d’un exemple de boutique en ligne, BalaisToGo, qui a été impacté par la panne de CDN cette semaine. Il fonctionne sur Shopify, qui utilise Fastly, j’ai donc pu utiliser nos outils d’observabilité pour voir de première main ce que les utilisateurs ont vécu. Ci-dessous un graphique en cascade de Surveillance synthétique Splunk qui montre les requêtes faites par le navigateur lorsqu’il a essayé de charger BroomsToGo :
Les demandes envoyées directement à l’hôte de l’application broomstogo.com, telles que le code HTML de base et une demande d’API, ont abouti. Tous les actifs du site, y compris CSS, la plupart des images et JavaScript, ont été servis par l’hôte cdn.shopify.com, qui était dirigé par Fastly. En raison de la panne, les demandes pour ces actifs ont toutes renvoyé une erreur 503. Ne pas charger le CSS et le JS a eu un effet catastrophique ! J’ai capturé l’image ci-dessous qui montre à quel point le site avait l’air et se comportait mal pendant la panne du CDN :
Cette mauvaise expérience utilisateur était également mauvaise pour les affaires. Même si vous aviez pu faire défiler pour trouver le bouton « paiement » sans style, cela n’aurait pas fonctionné ! Les fonctions JavaScript attachées à ce bouton ne se sont pas chargées, car le fichier main.js n’a pas pu se charger à partir du CDN.
Ce qu’une pratique d’observabilité incomplète voit lors d’une panne de CDN
Considérez l’impact si BroomsToGo était un magasin légitime, au lieu d’un exemple d’application amusant. L’équipe aurait-elle pu détecter ce problème en utilisant seulement quelques-uns des outils de surveillance traditionnels ?
Imaginez Mélanie, une SRE pour BroomsToGo, qui sirote son café quand Ethan de Bizdev appelle paniqué : « Le site est en panne ! Personne ne peut vérifier ! Nous perdons des milliers de ventes !’
Impossible! Mélanie réfléchit en sortant ses outils de surveillance traditionnels. Tout est vert. Il n’y a aucune alerte publiée dans le canal Ops dans Slack. Son infrastructure ou ses moniteurs d’application auraient sûrement détecté quelque chose ?
Malheureusement non. Le CDN est assis devant tout ou partie de l’application. Une panne de CDN a donc un impact sur la capacité à « observer » la panne via des moyens traditionnels. Voici comment les outils de surveillance traditionnels auraient géré cette panne
- Surveillance de l’infrastructure traditionnelle (IM) : La messagerie instantanée fournit des informations sur la santé de votre infrastructure, telles que les conteneurs, les serveurs ou les ressources cloud. Étant donné qu’une panne de CDN empêche la plupart, sinon la totalité, du trafic de visiteurs d’accéder à votre infrastructure, les équipes SRE utilisant la messagerie instantanée auraient vu des tableaux de bord verts sans problème. Aucune infrastructure contrôlée par l’entreprise n’a été sollicitée.
- Surveillance traditionnelle des performances des applications (APM) : APM va un niveau plus haut, vous montrant comment fonctionne une base de données, un serveur Web ou un code d’application. Étant donné que la panne a empêché la plupart du trafic d’atteindre votre application, APM n’aurait détecté aucun problème et n’aurait envoyé aucune alerte. Et ce serait bien ! Dans notre exemple, l’application elle-même était bonne. La page HTML de base et toutes les demandes d’API ont renvoyé 200 OK. Au lieu de cela, c’est la latence et la disponibilité de ces ressources CSS et JavaScript hébergées par le CDN tiers qui ont fait échouer l’application.
Là où Melanie aurait vu un problème, c’est si elle regardait les analyses de son site. Les taux de paiement diminueraient en fonction de l’étendue de la panne. Les chiffres de trafic et les chiffres d’engagement seraient également en baisse. Si elle avait des alertes sur les réseaux sociaux à propos de sa marque, elle verrait aussi les gens commencer à se plaindre.
Étendre l’observabilité avec la surveillance de l’expérience numérique
Melanie a supposé à tort que l’infrastructure et les applications qu’elle contrôle représentent tous les aspects importants de la santé et de la disponibilité de l’application. Malheureusement, ce n’est pas le cas. Les applications modernes se sont propagées au-delà de votre contrôle. Ils incluent presque toujours des composants tiers et s’exécutent dans des environnements opaques. Dans certains cas, comme lorsque le marketing ajoute un nouveau widget de discussion au site Web, les SRE peuvent même ne pas connaître toutes les infrastructures, applications et dépendances qui composent leur site. Alors que la messagerie instantanée et l’APM hérités sont des outils fantastiques pour aider à détecter et à diagnostiquer les problèmes, ces outils ne peuvent pas mesurer ce qu’ils ne peuvent pas voir, et les applications modernes ont beaucoup de surface au-delà du contrôle des SRE.
C’est ici que Surveillance de l’expérience numérique (DEM) entre en jeu. DEM surveille les performances et l’expérience du point de vue du client, ce qui vous permet de surveiller l’impact à la fois de vos performances backend – et des performances des actifs tiers inclus – sur l’utilisateur et de détecter tout problème de disponibilité avec l’application, quel que soit l’endroit où dans la pile, ils se produisent. DEM exploite une combinaison de Surveillance synthétique et Surveillance des utilisateurs réels (RHUM). La surveillance synthétique mesure les performances d’une page ou d’un flux commercial à l’aide de vrais navigateurs fonctionnant à partir d’emplacements à travers le monde chaque minute. RUM utilise JavaScript pour capturer les données d’utilisateurs réels visitant votre site ou utilisant votre application, vous donnant des mesures sur les performances, l’expérience et les erreurs qui se sont réellement produites.
En fait, parce que j’ai utilisé Surveillance synthétique Splunk sur le site BroomsToGo, j’ai reçu une alerte concernant cette panne. La surveillance synthétique a détecté une augmentation des erreurs côté client exactement au moment où la panne de CDN de cette semaine s’est produite.
Dans la capture d’écran ci-dessus, la ligne de couleur sarcelle représente le Première peinture de contenu et la ligne noire indique le nombre d’erreurs de navigateur rencontrées lors du téléchargement de ressources. Nous pouvons voir qu’au moment où la panne a commencé, les actifs tels que CSS et JS n’ont pas pu se charger, augmentant ainsi le nombre d’erreurs. Pendant ce temps, le temps de peinture s’est en fait amélioré, car tous ces échecs de requête signifiaient qu’il y avait moins de contenu à dessiner !
Bien sûr, les solutions DEM ne peuvent pas voir à l’intérieur de votre infrastructure et de votre application (en fait, si un client, qu’il s’agisse d’un utilisateur réel ou d’un navigateur synthétique, peut voir à l’intérieur de votre application, vous avez de plus gros problèmes !). C’est pourquoi DEM doit être combiné avec IM, APM et d’autres solutions dans une suite d’observabilité telle que Cloud d’observabilité Splunk. Cette combinaison offre une visibilité complète sur votre application, votre infrastructure et votre expérience utilisateur, vous permettant de rester au courant des problèmes, peu importe où ils surviennent dans votre pile.
Conclusion
La panne Fastly de cette semaine est un exemple clair de la façon dont le contenu et l’infrastructure échappant à votre contrôle peuvent faire échouer votre site et avoir un impact sur votre entreprise. En élargissant votre point de vue et en mesurant l’expérience du point de vue du client à l’aide de Digital Experience Monitoring, vous pouvez détecter ces types de problèmes et réagir rapidement pour minimiser leur impact. Lorsque vous développez une stratégie d’observabilité complète, n’oubliez pas d’inclure la surveillance de l’expérience numérique.
Pour commencer avec Splunk Synthetic Monitoring, Inscrivez-vous pour un essai gratuit aujourd’hui.
Ressources Splunk supplémentaires :
.
— to www.marketscreener.com