Le monitoring synthétique : l'union entre le testing et le monitoring

Par

Carly Richmond

digital-experience-monitoring.jpg

Historiquement parlant, les équipes de développement logiciel et de SRE ont toujours travaillé de manière cloisonnée avec des perspectives culturelles et des priorités différentes. Le but des DevOps est d'établir des pratiques communes et complémentaires pour le développement logiciel et les opérations. Or, dans certaines organisations, il est rare d'avoir une véritable collaboration entre ces deux équipes. Le chemin à parcourir pour mettre en place des partenariats DevOps efficaces est encore long.

En dehors des problématiques culturelles, l'une des raisons les plus courantes à l'origine de ce cloisonnement est le fait que ces équipes utilisent des outils différents pour atteindre les mêmes objectifs. On le voit bien avec le testing de bout en bout et le monitoring synthétique. 

Dans cet article, nous présenterons quelques techniques intéressantes en la matière. À l'aide de l'exemple de référentiel carlyrichmond/synthetics-replicator, nous verrons également comment Playwright, @elastic/synthetics et GitHub Actions peuvent unir leurs forces à celles d'Elastic Synthetics et de son enregistreur pour permettre aux équipes de développement et de SRE de valider et de monitorer conjointement l'expérience utilisateur pour une application web simple hébergée sur un fournisseur comme Netlify.

Récemment, Elastic a lancé le monitoring synthétique. Comme nous l'avons vu dans notre article précédent, il peut remplacer les tests de bout en bout. En recourant à un seul et même outil pour valider le workflow d'un utilisateur en amont, il est possible d'adopter un langage commun pour reproduire les problèmes rencontrés par cet utilisateur et valider des correctifs pour y remédier.

Comparaison entre le monitoring synthétique et les tests de bout en bout

Si les outils de développement et ceux des opérations s'opposent les uns aux autres, il est difficile d'unifier leurs cultures. Pourtant, si l'on se penche sur la définition de leurs approches, on voit qu'en réalité, ils visent le même objectif.

Les tests de bout en bout sont une suite de tests servant à recréer le parcours de l'utilisateur, notamment au niveau des clics, de la saisie de texte et de la navigation. Même si certains avanceront qu'il s'agit par-dessus tout de tester l'intégration des couches d'une application logicielle, le workflow de l'utilisateur constitue l'axe d'émulation des tests de bout en bout. En parallèle, le monitoring synthétique, et plus particulièrement un sous-ensemble connu sous le nom de monitoring du navigateur, est une pratique de monitoring des performances applicatives qui émule le parcours de l'utilisateur sur une application. 

Dans les deux cas, ces techniques émulent le parcours de l'utilisateur. Si nous utilisons des outils qui créent un pont entre développement et opérations, nous pouvons alors travailler main dans la main pour concevoir des tests qui pourront également servir au monitoring de la production dans nos applications web.

Création de parcours utilisateur

Lors du développement d'un nouveau workflow utilisateur ou d'un ensemble de fonctionnalités à une fin précise dans notre application, les développeurs peuvent se servir de @elastic/synthetics pour créer des parcours utilisateur. Après avoir installé l'utilitaire init, vous pouvez vous en servir pour générer l'arborescence initiale du projet, comme dans l'exemple ci-dessous. Remarque : avant d'utiliser cet utilitaire, vous devez installer Node.js.

npm install -g @elastic/synthetics
npx @elastic/synthetics init synthetics-replicator-tests

Avant de lancer l'assistant, assurez-vous d'avoir les informations de votre cluster Elastic et vérifiez que l'intégration Elastic Synthetics est configurée sur votre cluster. Vous aurez besoin des éléments suivants : 

  1. La fonctionnalité de gestion des outils de monitoring doit être activée dans l'application Elastic Synthetics, conformément aux prérequis répertoriés dans la documentation sur la prise en main. 
  2. L'ID cloud du cluster Elastic Cloud, si vous utilisez Elastic Cloud. Sinon, si vous utilisez un hébergement sur site, vous devrez entrer votre point de terminaison Kibana.
  3. Une clé d'API générée à partir de votre cluster. Les paramètres de l'application Synthetics comprend un raccourci permettant de générer cette clé sous l'onglet "Project API Keys" (Clés d'API du projet), comme expliqué dans la documentation.

Cet assistant vous guidera tout au long de la procédure pour générer un exemple de projet, avec une configuration adaptée et des exemples de parcours à monitorer. La structure de ce projet sera similaire à celle présentée ci-dessous :

tests du réplicateur de l'application synthetics

Pour les développeurs web, la plupart des éléments, tels que les fichiers README, package.json et LOCK, seront familiers. La configuration principale de vos outils de monitoring est disponible dans synthetics.config.ts, comme vous pouvez le voir ci-dessous. Cette configuration peut être modifiée afin d'inclure une configuration spécifique à la production et au développement. Cette modification est essentielle pour unir les forces, réutiliser les mêmes outils de monitoring pour les tests de bout en bout, et permettre à n'importe quel parcours de servir comme test de bout en bout et outil de monitoring de la production. Vous pouvez également inclure les détails relatifs à des emplacements privés si vous préférez procéder au monitoring depuis votre propre instance Elastic dédiée, plutôt qu'à partir de l'infrastructure Elastic (ce n'est pas le cas dans notre exemple).

import type { SyntheticsConfig } from '@elastic/synthetics';

export default env => {
  const config: SyntheticsConfig = {
    params: {
      url: 'http://localhost:5173',
    },
    playwrightOptions: {
      ignoreHTTPSErrors: false,
    },
    /**
     * Configure global monitor settings
     */
    monitor: {
      schedule: 10,
      locations: ['united_kingdom'],
      privateLocations: [],
    },
    /**
     * Project monitors settings
     */
    project: {
      id: 'synthetics-replicator-tests',
      url: 'https://elastic-deployment:port',
      space: 'default',
    },
  };
  if (env === 'production') {
    config.params = { url: 'https://synthetics-replicator.netlify.app/' }
  }
  return config;
};

Rédaction de votre premier parcours

Même si la configuration ci-dessus s'applique à tous les outils de monitoring du projet, vous pouvez la remplacer pour un test spécifique.

import { journey, step, monitor, expect, before } from '@elastic/synthetics';

journey('Replicator Order Journey', ({ page, params }) => {
  // Only relevant for the push command to create
  // monitors in Kibana
  monitor.use({
    id: 'synthetics-replicator-monitor',
    schedule: 10,
  });

// journey steps go here

});

Le wrapper @elastic/synthetics présente de nombreuses méthodes de test standard, comme les constructions before et after, qui permettent de définir et de supprimer des propriétés types dans les tests, mais aussi le support technique pour de nombreuses méthodes courantes d'assistance pour les affirmations. La liste complète des méthodes attendues prises en charge est fournie dans la documentation. L'objet page de Playwright est également présent. Il nous permet d'exécuter toutes les activités attendues fournies dans l'API, comme la localisation des éléments page et la simulation d'événements utilisateur, tels que les clics, comme dans l'exemple ci-dessous.

import { journey, step, monitor, expect, before } from '@elastic/synthetics';

journey('Replicator Order Journey', ({ page, params }) => {
  // monitor configuration goes here
 
  before(async ()=> {
    await page.goto(params.url);
  });

  step('assert home page loads', async () => {
    const header = await page.locator('h1');
    expect(await header.textContent()).toBe('Replicatr');
  });

  step('assert move to order page', async () => {
    const orderButton = await page.locator('data-testid=order-button');
    await orderButton.click();
    
    const url = page.url();
    expect(url).toContain('/order');

    const menuTiles = await page.locator('data-testid=menu-item-card');
    expect(await menuTiles.count()).toBeGreaterThan(2);
  });


// other steps go here


});

Comme vous pouvez le voir dans l'exemple ci-dessus, les constructions journey et step sont également présentes. Cette construction reflète la pratique du Behavior-Driven Development (BDD), c'est-à-dire le développement piloté par le comportement, pratique qui consiste à montrer le parcours de l'utilisateur dans l'application lors des tests.

Dans le cadre du développement de fonctionnalités, les développeurs peuvent mener des tests à bien dans une application qui s'exécute en local afin de déterminer les étapes réussies et celles qui sont en échec dans le workflow de l'utilisateur. Dans l'exemple ci-dessous, la commande de démarrage du serveur local est encadrée en bleu tout en haut. La commande d'exécution de l'outil de monitoring est encadrée en rouge un peu plus loin.

Comme vous pouvez le voir avec les coches vertes affichées en regard de chaque étape du parcours, tous nos tests ont réussi. C'est une bonne nouvelle !

Utilisation de vos pipelines CI comme passerelles

Il est important d'utiliser l'exécution des outils de monitoring au sein de votre pipeline CI comme une passerelle pour fusionner les changements de code et télécharger la nouvelle version de vos outils de monitoring. Dans cette section et la suivante, nous allons aborder chacune des tâches de notre workflow GitHub Actions.

La tâche de test crée une instance de test et exécute notre parcours utilisateur pour valider nos changements, comme on peut le voir ci-dessous. Cette étape devrait exécuter des requêtes pull pour valider les changements des développeurs, ainsi que des requêtes push.

jobs:   
  test:
    env:
      NODE_ENV: development
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 18
      - run: npm install
      - run: npm start &
      - run: "npm install @elastic/synthetics && SYNTHETICS_JUNIT_FILE='junit-synthetics.xml' npx @elastic/synthetics . --reporter=junit"
        working-directory: ./apps/synthetics-replicator-tests/journeys
      - name: Publish Unit Test Results
        uses: EnricoMi/publish-unit-test-result-action@v2
        if: always()
        with:
          junit_files: '**/junit-*.xml'
          check_name: Elastic Synthetics Tests

Remarque : contrairement à l'exécution du parcours sur notre machine locale, nous utilisons l'option --reporter=junit lors de l'exécution de npx @elastic/synthetics pour fournir de la visibilité sur nos parcours réussis (ou parfois en échec malheureusement) à notre tâche CI.

Téléchargement automatique des outils de monitoring

Pour vous assurer que les outils de monitoring les plus récents sont disponibles dans Elastic Uptime, il est recommandé d'intégrer les outils de monitoring de façon programmée dans le cadre du workflow CI, comme dans l'exemple de tâche ci-dessous. Notre workflow a une deuxième tâche push, comme nous pouvons le voir ci-dessous, qui dépend de la réussite de notre tâche test qui télécharge nos outils de monitoring dans notre cluster. Remarque : cette tâche est configurée dans notre workflow pour exécuter la commande push, ce, pour garantir que les changements ont bien été validés et qu'ils n'ont pas simplement été émis dans une requête pull.

jobs:   
  test: …
  push:
    env:
      NODE_ENV: production
      SYNTHETICS_API_KEY: ${{ secrets.SYNTHETICS_API_KEY }}
    needs: test
    defaults:
      run:
        working-directory: ./apps/synthetics-replicator-tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 18
      - run: npm install
      - run: npm run push

L'assistant @elastic/synthetics init génère une commande push pour vous au moment de la création de votre projet, qui peut être déclenchée à partir du dossier du projet. On peut le voir ci-dessous avec la configuration steps et working_directory. La commande push nécessite la clé API de votre cluster Elastic. Cette clé doit être stockée comme une clé secrète au sein d'un coffre-fort sécurisé et référencée par une variable d'environnement du workflow. Il est également essentiel que les outils de monitoring s'exécutent correctement avant que la configuration mise à jour de votre instance Elastic Synthetics ne soit intégrée afin d'éviter toute interruption du monitoring de votre production. À la différence des tests de bout en bout exécutés sur un environnement de testing, les outils de monitoring défaillants ont un impact sur les activités SRE. Par conséquent, tout changement apporté doit être validé. C'est pourquoi il est recommandé d'appliquer une dépendance à votre étape de test via l'option needs.

Monitoring à l'aide d'Elastic Synthetics

Une fois téléchargés, les outils de monitoring feront office de point de contrôle et permettront aux équipes SRE de vérifier à intervalles réguliers si le workflow utilisateur fonctionne comme prévu. Cette vérification peut se faire de deux façons : soit avec les outils de monitoring qui s'exécutent conformément à la séquence périodique configurée pour le projet et les tests individuels, comme vu précédemment, soit en consultant l'état des exécutions des outils de monitoring et en exécutant ces derniers manuellement à la demande.

L'onglet "Monitors Overview" (Aperçu du monitoring) nous fournit une vue immédiate de l'état de tous les monitorings configurés, ainsi que la capacité à exécuter le monitoring manuellement grâce au menu accessible en cliquant sur les trois points situés en bas à gauche de chaque carte.

monitoring Elastic Observability

Depuis l'écran Monitor (Monitoring), vous pouvez également accéder à un aperçu d'une exécution individuelle en vue d'investiguer les échecs.

détails des tests

L'autre superpouvoir dont disposent les équipes SRE en ce qui concerne le monitoring, c'est le fait de pouvoir intégrer ces outils de monitoring à des outils familiers qu'elles utilisent déjà pour examiner les performances et la disponibilité des applications, comme les APM, les indicateurs et les logs. Le menu judicieusement nommé Investigate (Examiner) permet aux équipes SRE de naviguer facilement pendant qu'elles enquêtent sur d'éventuels dysfonctionnements ou goulots d'étranglement.

Il faut également trouver le bon équilibre entre le fait d'identifier des problèmes et le fait d'être averti automatiquement en cas de problèmes potentiels. Les équipes SRE qui ont déjà l'habitude de configurer des règles et des seuils pour la notification de problèmes seront contentes de savoir que c'est également possible de le faire pour les outils de monitoring de navigateur. Un exemple de modification de règle est présenté ci-dessous.

règles Elastic Observability

Le statut des outils de monitoring de navigateur peut être configuré non seulement pour déterminer si des outils de monitoring individuels ou collectifs ont été en panne plusieurs fois, comme lors de la vérification de statut indiquée ci-dessus, mais aussi pour évaluer la disponibilité générale en étudiant le pourcentage de vérifications réussies sur un intervalle de temps donné. Ce qui intéresse les SRE, ce n'est pas uniquement de répondre aux problèmes en les gérant de manière traditionnelle côté production, c'est également d'améliorer la disponibilité des applications.

Enregistrement des workflows utilisateur

Le fait de générer des tests de bout en bout lors du cycle de vie de développement présente des limites : il peut arriver que les équipes passent à côté de certains éléments. Par ailleurs, l'ensemble d'outils précédent est axé vers les équipes de développement. Malgré les intentions louables que sous-tend la conception d'un produit intuitif par des équipes pluridisciplinaires, les utilisateurs peuvent utiliser les applications de façon inattendue. En outre, les outils de monitoring écrits par des développeurs ne couvriront que les workflows attendus. De ce fait, ils déclencheront une alarme en cas d'échec en production ou en cas de comportement anormal repérée par la fonctionnalité de détection des anomalies (si elle est appliquée).

Lorsqu'un utilisateur rencontre un problème, il est utile de reproduire ce problème dans le même format que celui de nos outils de monitoring. Il est également important de s'appuyer sur l'expérience des SRE dans la génération de parcours utilisateur, étant donné qu'ils envisageront les échecs de façon intuitive là où les développeurs risqueraient d'être en difficulté et de se concentrer uniquement sur les réussites. Ceci étant dit, ce n'est pas pour autant que tous les SRE auront l'expérience ou la confiance nécessaire pour écrire ces parcours avec Playwright et @elastic/synthetics.

Video thumbnail

Alors comment faire ? C'est là qu'intervient l'enregistreur d'Elastic Synthetics. Regardez la vidéo ci-dessus pour découvrir comment utiliser ce système pour enregistrer les étapes d'un parcours utilisateur et les exporter dans un fichier JavaScript afin de les inclure dans votre projet d'outils de monitoring. Vous pourrez ainsi faire des commentaires pour améliorer la phase de développement et tester les correctifs créés pour résoudre le problème. La seule condition pour réussir, c'est que nous combinions tous nos forces pour utiliser ces outils de monitoring.

À vous de jouer !

À partir de la version 8.8, @elastic/synthetics et l'application Elastic Synthetics sont en disponibilité générale et l'enregistreur est disponible en version bêta. Présentez vos expériences de mise en place d'une passerelle entre le développement et les opérations grâce au monitoring synthétique via la catégorie "Uptime" (Disponibilité) dans les forums de discussion de la communauté ou sur Slack.

Bon monitoring !

Date de publication d'origine : 6 février 2023 ; date de mise à jour : 23 mai 2023.

Ressources
  1. Why and how to replace end-to-end tests with synthetic monitors
  2. Uptime and Synthetic Monitoring
  3. Scripting browser monitors
  4. Use the Synthetics Recorder
  5. Playwright
  6. GitHub Actions

Inscrivez-vous à un essai gratuit d'Elastic Cloud

Optez pour un déploiement ultra-complet sur la plateforme cloud de votre choix. En tant que créateurs d'Elasticsearch, nous mettons nos fonctionnalités et notre support technique au service de vos clusters Elastic dans le cloud.

Démarrer un essai gratuit