Le saviez-vous ? Elastic Observability monitore les indicateurs des services AWS en seulement quelques minutes !

blog-charts-packages.png

La transition vers les applications distribuées bat actuellement son plein. En cause, notre besoin d'être "toujours en action", quel que soit notre statut (clients, entreprises à croissance rapide, etc.). Ce besoin implique que nos déploiements prennent en charge des exigences toujours plus complexes. Nous devons en plus être capables de nous diversifier sur le plan mondial et d'innover rapidement.

Sans surprise, c'est donc le cloud qui est l'option privilégiée aujourd'hui pour les déploiements d'applications. Bon nombre d'entreprises choisissent d'héberger leurs applications sur AWS, car il couvre un vaste éventail de régions et propose une multitude de services (pour un développement et une innovation plus rapides). Mais ce n'est pas tout. Il permet également de réduire les dépenses opérationnelles et les coûts en capital. Sur AWS, les équipes de développement dégagent une valeur supplémentaire en migrant vers Kubernetes sur Amazon EKS, où elles peuvent tester les dernières options sans serveur et améliorer les applications traditionnelles par niveaux avec de meilleurs services.

Elastic Observability propose 30 intégrations prêtes à l'emploi pour les services AWS. Et elle ne compte pas en rester là.

Si vous souhaitez en savoir plus sur certaines de ces intégrations et fonctionnalités, consultez notre précédent article :

Vous trouverez ci-dessous d'autres articles sur les intégrations clés des services AWS sur Elastic :

Vous trouverez également une liste complète des intégrations AWS dans la documentation en ligne d'Elastic :

En plus de nos intégrations AWS natives, Elastic Observability agrège non seulement les logs, mais aussi les indicateurs pour les services AWS et les applications s'exécutant sur les services de calcul AWS (EC2, Lambda, EKS/ECS/Fargate). Toutes ces données peuvent être analysées de manière visuelle et plus intuitive grâce aux fonctionnalités avancées de Machine Learning d'Elastic, qui aident à détecter les problèmes de performances et leurs causes premières avant que les utilisateurs ne s'en aperçoivent.

Envie d'en savoir plus sur les fonctionnalités de monitoring des performances applicatives (APM) proposées par Elastic Observability, comme les mappings des services, le traçage, les dépendances et les corrélations d'indicateurs basées sur le Machine Learning ? C'est par ici :

Elastic propose d'ingérer, d'agréger et d'analyser les indicateurs pour les services et les applications AWS sur les services de calcul AWS (EC2, Lambda, EKS/ECS/Fargate). Elastic ne fournit pas que des logs : elle offre une solution d'observabilité unifiée pour les environnements AWS.

Dans cet article, nous verrons comment Elastic Observability peut monitorer des indicateurs pour une application AWS simple s'exécutant sur les services AWS, parmi lesquels :

  • AWS EC2
  • AWS ELB
  • AWS RDS (AuroraDB)
  • Passerelles NAT AWS

Comme vous allez le voir, une fois l'intégration installée, les indicateurs arriveront instantanément et vous pourrez commencer à les étudier immédiatement.

Conditions requises et configuration

Si vous comptez reproduire les étapes présentées dans cet article, voici quelques informations utiles pour l'exécution :

  • Vérifiez que vous disposez d'un compte Elastic Cloud et d'une pile déployée (cliquez ici pour obtenir des instructions).
  • Vérifiez que vous disposez d'un compte AWS avec les autorisations appropriées pour collecter les données nécessaires d'AWS. Pour en savoir plus, consultez notre documentation.
  • Nous avons utilisé l'application à trois niveaux d'AWS et nous l'avons installée conformément aux instructions du référentiel git.
  • Nous allons voir comment installer l'intégration AWS générale d'Elastic, qui couvre les quatre services à partir desquels nous souhaitons collecter des indicateurs.
    (Liste complète des services pris en charge par l'intégration AWS d'Elastic)
  • Nous n'aborderons pas le monitoring des applications (indicateurs, logs et traçage) sur AWS étant donné que d'autres articles en parlent. Ici, nous allons voir principalement comment monitorer les services AWS en toute simplicité.
  • Pour voir les indicateurs, vous devrez charger l'application. Nous avons également créé un script Playwright pour diriger le trafic vers l'application.

Aperçu de l'application à trois niveaux

Avant de nous pencher sur la configuration d'Elastic, étudions d'abord ce que nous monitorons. Si vous suivez les instructions concernant aws-three-tier-web-architecture-workshop, le déploiement se présentera comme suit.

Éléments déployés :

  • 1 VPC avec 6 sous-réseaux
  • 2 zones de disponibilité
  • 2 serveurs web par zone de disponibilité
  • 2 serveurs d'application par zone de disponibilité
  • 1 équilibreur de charge d'application externe
  • 1 équilibreur de charge d'application interne
  • 2 passerelles NAT pour gérer le trafic vers la couche d'application
  • 1 passerelle internet
  • 1 base de données RDS Aurora avec une réplique de lecture

À la fin de cet article, nous fournirons aussi un script Playwright à mettre en œuvre pour charger cette application. Les indicateurs pourront ainsi "illuminer" les tableaux de bord.

Paramétrage

Voyons comment mettre en place l'application et l'intégration AWS d'Elastic, et déterminons les éléments ingérés.

Étape 0 : Charger l'application à trois niveaux AWS et obtenir vos identifiants

Suivez les instructions indiquées dans l'application à trois niveaux d'AWS, ainsi que les instructions sur le lien d'atelier dans le référentiel git. L'atelier se trouve ici.

Une fois l'application installée, obtenez des identifiants à partir d'AWS. Vous en aurez besoin pour l'intégration AWS d'Elastic.

Pour les identifiants, plusieurs options sont possibles :

  • Utilisation directe de clés d'accès
  • Utilisation d'identifiants de sécurité temporaires
  • Utilisation d'un fichier d'identifiants partagés
  • Utilisation d'un Amazon Resource Name (ARN) de rôle pour la gestion des identités et des accès

Pour en savoir plus sur les identifiants nécessaires, cliquez ici, et pour en savoir plus sur les autorisations, cliquez ici.

1ère étape : Créer un compte sur Elastic Cloud

Suivez les instructions pour vous lancer sur Elastic Cloud.

2e étape : Installer l'intégration AWS d'Elastic

Accédez à l'intégration AWS sur Elastic.

Cliquez sur Add AWS (Ajouter AWS).

C'est là que vous entrerez vos identifiants. Ceux-ci seront stockés comme une règle dans Elastic. Cette règle sera utilisée dans le cadre de l'installation de l'agent à la prochaine étape.

Comme vous pouvez le constater, l'intégration AWS générale d'Elastic va collecter un volume conséquent de données à partir de 30 services AWS. Si vous ne souhaitez pas installer cette intégration générale, vous pouvez sélectionner des intégrations individuelles.

3e étape : Installer Elastic Agent avec l'intégration AWS

Maintenant que vous avez créé une règle d'intégration, accédez à la section Fleet sous Management (Gestion) dans Elastic.

Sélectionnez le nom de la règle que vous avez créée dans la dernière étape.

Suivez l'étape 3 des instructions indiquées dans la fenêtre Add agent (Ajouter un agent). Vous devrez :

1 : Mettre en place une instance EC2

  • t2.medium is minimum (Au minimum t2.medium)
  • Linux - your choice of which (Linux (version au choix))
  • Ensure you allow for Open reservation on the EC2 instance when you Launch it (Autorisez les réservations ouvertes sur l'instance EC2 lorsque vous la lancez)

2 : Vous connecter à l'instance et exécuter les commandes indiquées dans l'onglet Linux Tar (voir l'exemple ci-dessous)

curl -L -O https://artifacts.elastic.co/downloads/beats/elastic-agent/elastic-agent-8.5.0-linux-x86_64.tar.gz
tar xzvf elastic-agent-8.5.0-linux-x86_64.tar.gz
cd elastic-agent-8.5.0-linux-x86_64
sudo ./elastic-agent install --url=https://37845638732625692c8ee914d88951dd96.fleet.us-central1.gcp.cloud.es.io:443 --enrollment-token=jkhfglkuwyvrquevuytqoeiyri

4e étape : Diriger le trafic vers l'application

Voici un script simple que vous pouvez également exécuter avec Playwright pour ajouter du trafic vers le site web pour l'application à trois niveaux AWS :

import { test, expect } from '@playwright/test';

test('homepage for AWS Threetierapp', async ({ page }) => {
  await page.goto('http://web-tier-external-lb-1897463036.us-west-1.elb.amazonaws.com/#/db');

   await page.fill('#transactions > tbody > tr > td:nth-child(2) > input', (Math.random()*100).toString())
  await page.fill('#transactions > tbody > tr > td:nth-child(3) > input', (Math.random()*100).toString())
  await page.waitForTimeout(1000)
  await page.click('#transactions > tbody > tr:nth-child(2) > td:nth-child(1) > input[type=button]')
  await page.waitForTimeout(4000)

});

Ce script lancera trois navigateurs, mais vous pouvez limiter cette charge à un seul navigateur dans le fichier playwright.config.ts.

Pour cet exercice, nous avons exécuté le trafic pendant environ cinq heures avec un intervalle de cinq minutes, tout en testant le site web.

5e étape : Accéder aux tableaux de bord AWS

Maintenant que votre instance Elastic Agent est en cours d'exécution, vous pouvez accéder aux tableaux de bord AWS associés pour consulter les éléments ingérés.

Pour trouver les tableaux de bord de l'intégration AWS, effectuez tout simplement une recherche dans la barre prévue à cet effet. Voici les tableaux de bord intéressants pour cet article :

  • [Indicateurs AWS] Présentation d'EC2
  • [Indicateurs AWS] Présentation d'ELB
  • [Indicateurs AWS] Présentation de RDS
  • [Indicateurs AWS] Passerelle NAT

Voyons ce qui ressort.

Tous ces tableaux de bord sont prêts à l'emploi. Sur les images ci-dessous, nous avons affiné les vues de sorte à afficher uniquement les éléments pertinents de notre appli.

Sur tous les tableaux de bord, nous avons limité la période définie au moment où nous avons exécuté le générateur de trafic.

Tableau de bord de présentation d'EC2 avec Elastic Observability
Tableau de bord de présentation d'EC2 avec Elastic Observability

Une fois que nous avons filtré nos quatre instances EC2 (deux serveurs web et deux serveurs d'application), voici ce que nous constatons :

1 : Les quatre instances sont opérationnelles, sans échec lors des vérifications d'état.

2 : Nous voyons l'utilisation moyenne du processeur dans la période définie, et rien ne paraît anormal.

3 : Nous voyons le trafic réseau entrant et sortant, s'agrégeant au fil du temps au fur et à mesure que la base de données est chargée avec des lignes.

Dans cet exercice, nous ne voyons qu'une petite partie des indicateurs qu'il est possible de consulter. Il en existe davantage dans AWS EC2. Les indicateurs répertoriés dans la documentation AWS sont tous disponibles, y compris les dimensions pour affiner la recherche sur des instances spécifiques, etc.

Tableau de bord de présentation d'ELB avec Elastic Observability
Tableau de bord de présentation d'ELB avec Elastic Observability

Pour le tableau de bord ELB, nous appliquons un filtre pour avoir uniquement nos deux équilibreurs de charge (l'équilibreur de charge web externe et l'équilibreur de charge d'application interne).

Avec le tableau de bord prêt à l'emploi, nous pouvons consulter les indicateurs d'application propres à ELB. Une bonne partie de ces indicateurs qui sont répertoriés dans la documentation AWS permet d'ajouter des graphes.

Pour nos deux équilibreurs de charge, voici ce que nous constatons :

1 : Les deux hôtes (instances EC2 connectées aux instances ELB) sont sains.

2 : Les unités de capacité des équilibreurs de charge (c.-à-d. ce que vous consommez) et les décomptes de requêtes sont conformes à ce qui était attendu au moment de la génération du trafic.

3 : Nous avons décidé d'afficher les décomptes 4XX et 2XX. 4XX nous aide à identifier les problèmes rencontrés avec l'application ou avec la connectivité des serveurs d'application.

Tableau de bord de présentation de RDS avec Elastic Observability
Tableau de bord de présentation de RDS avec Elastic Observability

Pour AuroraDB, qui est déployé dans RDS, nous avons appliqué un filtre pour afficher uniquement les instances primaires et secondaires d'Aurora sur le tableau de bord.

Comme pour EC2 et ELB, la plupart des indicateurs RDS de Cloudwatch permettent de créer des graphiques et des graphes. Dans ce tableau de bord, nous avons affiné la recherche pour afficher :

1 : Le débit d'insertion et le débit de sélection

2 : La latence d'écriture

3 : L'utilisation du processeur

4 : Le nombre général de connexions pendant la période définie

Tableau de bord NAT AWS avec Elastic Observability
Tableau de bord NAT AWS avec Elastic Observability

Nous avons appliqué un filtre pour afficher uniquement nos deux instances NAT qui interagissent avec les serveurs d'application. Comme pour les autres tableaux de bord, d'autres indicateurs sont disponibles pour créer des graphes et des graphiques selon les besoins.

Dans le tableau de bord NAT, voici ce que nous constatons :

1 : Les performances des passerelles NAT sont bonnes car il n'y a pas de perte de paquets.

2 : Le nombre de connexions actives du serveur web est conforme à ce qui est prévu.

3 : L'ensemble d'indicateurs pour le trafic entrant et sortant est plutôt normal.

Félicitations ! Vous venez de commencer à monitorer les indicateurs des principaux services AWS de votre application !

Et ensuite, que faut-il monitorer sur AWS ?

Ajout de logs à partir des services AWS

Maintenant que nous monitorons les indicateurs, nous pouvons ajouter le logging. Pour ingérer les logs, plusieurs options sont possibles.

1. L'intégration AWS dans Elastic Agent permet de paramétrer les logs. Assurez-vous d'activer ceux que vous souhaitez recevoir. Ingérons les logs Aurora à partir de RDS. Dans la règle d'Elastic Agent, nous activons Collect logs from CloudWatch (Collecter les logs de CloudWatch), comme vous pouvez le voir ci-dessous. Ensuite, nous mettons à jour l'agent via l'interface utilisateur de gestion Fleet.

2. Vous pouvez installer le forwarder de logs Lambda. Cette option collectera des logs dans différents emplacements, comme vous pouvez le voir dans le diagramme de l'architecture ci-dessous.

Cette option est également présentée dans cet article.

Analyse des données avec le Machine Learning Elastic

Une fois que les indicateurs et les logs (ou l'un ou l'autre) ont été ingérés dans Elastic, commencez à analyser vos données en vous aidant des fonctionnalités de Machine Learning d'Elastic. Pour en savoir plus sur ces fonctionnalités, lisez ces articles :

Et retrouvez encore plus de vidéos et d'articles ici.

Conclusion : Avec Elastic Observability, c'est un jeu d'enfants de monitorer les indicateurs des services AWS.

Nous espérons que cet article vous a donné un bon aperçu de la façon d'utiliser Elastic Observability pour monitorer les indicateurs des services AWS. Voici un récapitulatif rapide des points que nous avons abordés :

  • Elastic Observability prend en charge l'ingestion et l'analyse des indicateurs des services AWS.
  • Il est très simple de configurer l'ingestion à partir des services AWS via Elastic Agent.
  • Elastic Observability propose plusieurs tableaux de bord de services AWS prêts à l'emploi que vous pouvez utiliser pour consulter les informations préliminaires, puis effectuer des modifications en fonction de vos besoins.
  • Plus de 30 services AWS sont pris en charge dans le cadre de l'intégration AWS sur Elastic Observability, sachant que d'autres services sont régulièrement ajoutés.
  • Comme indiqué dans les articles associés, vous pouvez analyser les indicateurs de vos services AWS à l'aide du Machine Learning d'Elastic.

Démarrez un essai gratuit de 7 jours en vous inscrivant sur AWS Marketplace et effectuez un déploiement en quelques minutes sur n'importe quelle région d'Elastic Cloud sur AWS dans le monde entier. L'achat d'Elastic via AWS Marketplace sera inclus dans votre facturation consolidée mensuelle et comptera dans l'engagement de dépenses d'AWS.

La publication et la date de publication de toute fonctionnalité ou fonction décrite dans le présent article restent à la seule discrétion d'Elastic. Toute fonctionnalité ou fonction qui n'est actuellement pas disponible peut ne pas être livrée à temps ou ne pas être livrée du tout.