Observabilité : AWS Cloudwatch Synthetics & RUM
🔎

Observabilité : AWS Cloudwatch Synthetics & RUM

Quand on est opérateur, il est bon de savoir comment vont nos infrastructures et pour cela, nous avons déjà une trousse à outils soit directement issue d’AWS (CloudWatch et ses sous services), soit proposée par des tiers (Datadog, Zabbix, Nagios, Prometheus, Exporters…).

Maintenant, quand on est DevOps, il est aussi bon de savoir comment se portent les applications qui tournent sur nos infrastructures. Il existe pour cela différents types d’outils : les Applications Performance Monitor (Dynatrace APM, Datadog APM, Logz.io, Sentry…) et les Websites Monitoring (site24x7, pingdom). Aujourd’hui, nous allons voir deux outils complémentaires sur ce besoin pour les DevOps :

Les deux permettent de superviser une facette de nos applications.

AWS CloudWatch Synthetics

AWS CloudWatch Synthetics est un service permettant de mettre en place des scripts planifiés de surveillances (canaries) pour vos endpoints et autres API, en effectuant les mêmes actions que les utilisateurs pourraient mener sur ces mêmes ressources. Il permet de voir les problèmes avant que les utilisateurs y soient confrontés, ou pire, qu’ils se manifestent à cause de ces dits problèmes. En résumé, Synthetics c’est :

  • Python ou Node.js.
  • HTTP ou HTTPS.
  • Données non externalisées, tout reste dans votre compte AWS.
  • Technos sous-jacentes : Puppeteer & Selenium.
  • Peut remonter : disponibilité, latence, temps de chargement, capture d’écran.
  • Peut vérifier : les changements non autorisés liés au phising, l’injection de code, le cross-site scripting.
  • Intégration à :
  • Déclenchement manuel ou planifié.
  • Des droits IAM spécifiques pour les administrateurs (possibilité de permission fine-grained).
  • Des droits IAM spécifiques pour les canaries (exécution des scripts).

Création d’un Canary

La création d’un canary implique la création d’un nombre non négligeable de ressources AWS :

  • Un rôle IAM pour le canary.
  • Une policy IAM pour le role du canary.
  • Un bucket S3 pour les résultats du canary.
  • Une alarme AWS CloudWatch.
  • Une Lambda (avec ou sans layers).
  • Un groupe AWS CloudWatch Logs.

La création et le lien entre ces ressources sont gérés de manière transparente quand vous créez un canary via la console Web AWS et les blueprint fournis (Heartbeat, API, Broken Link, Visual Monitoring, Canary recorder, ou à travers un parcours GUI). Cependant, on sait tous que la console AWS pour déployer des ressources, ce n'est pas “idéal”. On va donc privilégier le déploiement de ces ressources à travers des outils d’Infrastructure as Code. Pour vous y aider, il existe des exemples de projets traitant de ce sujet :

Dans le cas de l’Infrastructure as Code, il faudra s’assurer de fournir le bon code à la fonction lambda (qui est gérée à travers le blueprint dans le cas de la console Web AWS). Dans le cas où on ne passe pas par un blueprint, soit on simule un blueprint sans valider la création et on prend le code de la fonction générée, soit un part “from scratch” en suivant les recommandations évoquées par AWS et les fonctions fournies par les librairies Python ou Node.js. Des exemples simplistes sont aussi disponibles dans la documentation officielle.

Un canary à comme attribut principal son runtime. Une gestion de version spécifique est en place concernant ces runtimes qu’ils soient en Node.js ou en Python. Il est important de suivre les cycles de vie de ces runtimes, de faire des montées de versions pour profiter des corrections et d’avoir accès aux nouvelles features.

De plus, les canaries créés peuvent être réunis en groupe (par exemple par application, par projet, par équipe) à travers les groups.

Analyse des Canaries

image

La console AWS permet d’analyser les résultats de vos différents canaries. Vous aurez en premier lieu un dashboard général où vous retrouverez vos canaries rangés par groupe, si vous avez eu la bonne idée ou la nécessité de le faire.

Ensuite, chaque canary est analysable individuellement et par itération si le tracing a été activé.

image

Si le tracing est activé, vous pourrez aller jusqu’à observer quels sont les délais de chaque segment dans le parcours du canary.

image

AWS Cloudwatch Synthetics est d’abord fait pour superviser la santé d’une application web (disponibilité, anomalies visuelles, erreurs de parcours). Il n’est pas là pour étudier et surveiller le ressenti des utilisateurs. Il peut juste donner une impression dans le temps vécu par ce processus automatisé. Ni plus, ni moins.

Concernant les coûts directement imputables à l’utilisation de ce service, ils sont simples puisque la seule valeur de facturation est un coût (de 0,0014$ en Irlande) par exécution d’un canary. Mais là, et comme tous les principes de facturation sur AWS, il faut voir l’intégralité des coûts au-delà des simples canaries, car des frais liés à Lambda, CloudWatch Logs et S3 seront imputables.

Les exemples sur la page de pricing AWS CloudWatch sont en revanche très parlants. Dans un des exemples présentés, cinq canaries tournant toutes les cinq minutes sur un mois vont générer approximativement 75$ en Irlande (il existe un free trail de 100 exécutions par mois). 

AWS CloudWatch RUM

AWS CloudWatch RUM (Real User Monitoring) va nous permettre d’avoir une vision utilisateur sur les aspects de performance, d’erreur côté client, de comportement et d’habitude client.

C’est un outil qui s’appuie sur un bloc de code JavaScript à intégrer dans les pages web de nos applications que l’on souhaite surveiller.

L’impact du RUM sur vos applications est quasiment nul. Il ne bloquera jamais vos applications au chargement par exemple. Le code RUM pour votre application peut être soit directement fourni par votre code applicatif, soit à travers un déport sur CDN (AWS Cloudfront par exemple).

Ce service fait partie de la suite d’outils AWS CloudWatch Application Signals et peut s’intégrer avec les sous-services de ce dernier ainsi que AWS X-Ray.

Voyons maintenant la création d’une App Monitor.

Création d’une App Monitor

Deux moyens de création vus de ma fenêtre, soit à travers la console web AWS, soit à travers les ressources proposées via Terraform.

Dans le cadre de cet article, j’ai déroulé le workshop One Observability Workshop, et la création de l’App Monitor se passe via la console web d’AWS.

Quelques paramètres sont disponibles pour peaufiner la configuration de l’App Monitor comme :

  • Son nom, le domaine (FQDN) de l’application web.
  • Si l’on doit ou non inclure les sous-domaines.
  • La liste des plugins que l’on souhaite activer (performance, erreurs JavaScript, erreur HTTP ou encore des évènements customisés).
  • L’activation des cookies ou non (pour capter les sessions utilisateurs).
  • L’échantillonnage.
  • Le stockage de la donnée, si on souhaite pouvoir dépasser les 30 jours de rétention fournie par AWS CloudWatch RUM par défaut (on parle ici d’un groupe CloudWatch Logs dédié).
  • La gestion des autorisations (pool d’identité Cognito).
  • Le choix des pages à inclure ou exclure des remontées RUM.
  • Activer ou non le tracing et avoir un diagramme du parcours sous AWS X-Ray.
  • L’utilisation (évidemment) des TAG.
image

Analyse via RUM

Une fois l’App Monitor créée, il faudra attendre que vos utilisateurs naviguent sur votre application web et que des informations remontent vers votre App Monitor.

Vous pourrez voir les premières informations centralisées sur le tableau de bord général via la page d’accueil RUM Overview en choisissant votre App Monitor dans la liste déroulante.

Ce tableau de bord remonte, sur la plage configurée, la synthèse des métriques et informations suivantes :

  • Le nombre de pages chargées.
  • Le temps de chargement moyen des pages.
  • Le score Apdex.
  • La remontée ou non d’alarmes.
  • Le pourcentage d’erreur par device.
  • Le nombre de sessions initiées.
  • Les canaries associés.
image

Ce tableau de bord générique est téléchargeable en pdf pour envoyer à qui de droit.

De plus amples détails peuvent être observés à travers les informations d’une App Monitor en allant dans List View et en cliquant sur l’App Monitor souhaitée.

Un ensemble d’onglets permettent de naviguer à travers la quantité de données remontées (soit en globalité, soit par page).

image

Chaque onglet ci-dessus permet d’avoir des détails spécifiques sur une catégorie précise.

  • Performance
    • Page loads
      • Page loads
      • Load time
      • Errors
      • Average load time by time of day
      • Web vitals
        • Largest contentful paint
        • First input delay
        • Cumulative layout shift
      • Page load steps over time
    • Request
      • Number of resource requests
      • Resource requests per hour
      • Resource requests over time
      • Resource requests
      • Response time by type
      • Frequency by type
    • Location
      • Highest load time
      • Most sessions
      • Apdex score
      • Locations
  • Errors
    • Most seen error message
    • Device with most errors
    • Browser with most errors
    • Errors
  • HTTP request
    • Request url with most errors
    • Device with most errors
    • Browser with most errors
    • Requets
  • Sessions
    • Average session length
    • Error free sessions
    • Average errors per session
    • Session starts
  • Events
    • Events
  • Browsers & Devices
    • Top browser by use
    • Slowest browser by page load
    • Browser with most errors
    • Browser breakdown
    • Errors by browser
    • Average page load time by browser
    • Browser throughput
  • User journey

    • Une vision intéressante des parcours utilisateurs :

    image
  • Configuration

Cela fait pas mal d’informations intéressantes pour les développeurs qui pourront s’en servir pour nourrir leur backlog de bug fixes ou d’amélioration de code sur des segments applicatifs particulièrement lents par exemple, ou permettre aux opérateurs de la plateforme d’envisager des resizing d’infrastructure, ou encore revoir la méthode de mise à l’échelle si des lenteurs sont identifiées mais relatives au matériel sous-jacent.

Cependant, vous vous doutez bien que ce genre d’outil (efficace, pertinent, et waouh !) a un prix non négligeable. Le free trial associé à ce service est de 1 million d’évènements RUM par compte AWS. Autant vous dire que ça va partir assez vite si vous activez toutes les fonctionnalités sur toutes les pages web. Puis le pricing passe à 1$ pour 100 000 évènements (pages vues, erreurs JavaScript, erreurs HTTP). Des coûts additionnels s’appliquent ou peuvent s’appliquer sur AWS CloudWatch, AWS Cognito et AWS X-Ray.

L’exemple de la page de pricing est intéressant. Pour un site ayant 500 000 visites par mois et remontant 20 évènements RUM par visite, le tout avec un échantillonnage à 100%, cela amène à une facture uniquement AWS Cloudwatch RUM de 100$ sur un mois.

Sur ce service, des stratégies différentes peuvent être observées quant à son usage :

  • On a de l’argent et on l’active partout avec un échantillonnage à 100% et tout le temps.
  • On a moins d’argent mais on veut avoir une idée globale de l’état de santé de l’application, alors on active tout mais sur un échantillonnage plus faible (50%) en laissant actif tout le temps.
  • On a moins d’argent mais on veut simplement activer le client web CloudWatch RUM à 100% du temps et de l’échantillonnage mais simplement sur quelques segments de l’application web.
  • On a beaucoup moins d’argent, alors on créer une App Monitor uniquement quand on a des remontées d’anomalies externes (clients) ou quand on fait des grosses mises à jour. Ce n’est pas foufou, mais ça a le mérite d’être possible.

Ressources Utiles

https://catalog.workshops.aws/observability/en-US/aws-native/app-monitoring/synthetics

https://catalog.workshops.aws/observability/en-US/aws-native/app-monitoring/rum

https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/deploy-cloudwatch-synthetics-canaries-by-using-terraform.html

https://aws.amazon.com/blogs/mt/how-to-validate-authentication-using-amazon-cloudwatch-synthetics-part-2/

https://aws.amazon.com/blogs/mt/multi-step-api-monitoring-using-amazon-cloudwatch-synthetics/

Article issu de notre participation à AWS Summit

Merci pour votre lecture. Cet article vous a plu, partagez sur vos réseaux 😉

Philippe Vidal - 30 avril 2024

image