Eine Medaille, zwei Seiten: Wie synthetisches Monitoring Testen und Überwachen zusammenbringt

Von

Carly Richmond

digital-experience-monitoring.jpg

In der Vergangenheit haben die Softwareentwicklungs- und SRE-Teams in Silos mit unterschiedlichen kulturellen Perspektiven und Prioritäten gearbeitet. DevOps hat das Ziel, einheitliche und sich gegenseitig ergänzende Prozesse für die Softwareentwicklung und den operativen Betrieb zu etablieren. In einigen Unternehmen ist es jedoch eher eine Ausnahme, dass Teams wirklich gut zusammenarbeiten, und wenn es um den Aufbau effektiver DevOps-Partnerschaften geht, haben wir noch einen weiten Weg vor uns.

Abgesehen von kulturellen Herausforderungen liegt einer der häufigsten Gründe für diese Diskrepanz in der Verwendung unterschiedlicher Tools zur Erreichung ähnlicher Ziele. Ein typisches Beispiel für unterschiedliche Tools sind End-to-End-Tests (e2e-Tests) und das synthetische Monitoring. 

In diesem Blogpost möchten wir einen Überblick über diese Verfahren geben. Anhand des Beispiel-Repositorys carlyrichmond/synthetics-replicator zeigen wir außerdem, wie das Zusammenwirken von Playwright, @elastic/synthetics und GitHub Actions mit Elastic Synthetics und dem Recorder dabei helfen kann, Entwicklungs- und SRE-Teams bei der Validierung und Überwachung der User Experience für eine einfache, bei einem Provider wie Netlify gehostete Webanwendung zusammenzubringen.

Elastic verfügt seit Neuestem über Funktionen zum synthetischen Monitoring, und wie in einem früheren Blogpost beschrieben, können diese e2e-Tests gänzlich ersetzen. Wenn zur Beurteilung des Nutzer-Workflows schon sehr früh im Prozess nur noch ein Tool verwendet wird, ist dafür gesorgt, dass beim Nachstellen von Nutzerproblemen zum Zweck der Korrekturvalidierung alle dieselbe Sprache sprechen.

Synthetisches Monitoring vs. e2e-Tests

Wo sich Entwicklungs- und Operations-Tools gegenseitig bekriegen, ist es schwierig, ihre unterschiedlichen Kulturen zusammenzubringen. Sieht man sich die Definitionen dieser Ansätze an, zeigt sich, dass sie im Grunde dasselbe Ziel verfolgen.

e2e-Tests ist ein Oberbegriff für eine Reihe von Tests, die den Nutzerpfad nachbilden – von Klicks über Texteingaben bis hin zu Navigationsschritten. Viele behaupten zwar, es ginge bei e2e-Tests um das Testen der Integration der Schichten einer Softwareanwendung, aber in Wahrheit emulieren e2e-Tests den Nutzer-Workflow. Synthetisches Monitoring, insbesondere dessen Komponente Browser-Monitoring, ist dagegen ein Verfahren für das Monitoring der Anwendungsleistung (APM), das den Weg emuliert, den die Nutzer:innen in einer Anwendung zurücklegen. 

Bei beiden Verfahren wird also der Nutzerpfad emuliert. Wenn wir Tools verwenden, die die Grenzen zwischen Entwicklungs- und Operations-Teams überwinden, können wir gemeinsam Tests entwickeln, die in unseren Webanwendungen auch das Produktions-Monitoring ermöglichen.

Entwickeln von User Journeys

Wenn wir dabei sind, in unserer Anwendung einen neuen Nutzer-Workflow oder neue Funktionen zu entwickeln, die das Erreichen eines wichtigen Ziels möglich machen, können Entwickler:innen zum Entwickeln von User Journeys @elastic/synthetics verwenden. Das anfängliche Projektgerüst kann nach der Installation mit dem Dienstprogramm init erstellt werden, wie im folgenden Beispiel. Achtung: Bevor dieses Dienstprogramm zum Einsatz kommt, muss Node.js installiert worden sein.

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

Bevor Sie den Assistenten starten, vergewissern Sie sich, dass Sie die Elastic-Cluster-Informationen und die Elastic Synthetics-Integration auf Ihrem Cluster eingestellt haben. Folgende Voraussetzungen müssen erfüllt sein: 

  1. In der Elastic Synthetics-Anwendung muss das Monitor Management aktiviert sein (siehe Abschnitt „Prerequisites“ in der „Get Started“-Dokumentation). 
  2. Sofern Sie Elastic Cloud verwenden, müssen Sie die Elastic Cloud-Cluster-Cloud-ID zur Hand haben. Nutzen Sie stattdessen On-Premises-Hosting, wird die Angaben Ihres Kibana-Endpoints benötigt.
  3. Sie benötigen einen auf der Basis Ihres Clusters generierte API-Schlüssel. In der Synthetics-Anwendung finden Sie unter „Settings“ einen Link, über den Sie diesen Schlüssel auf dem Tab „Keys“ der Project API generieren können (siehe Dokumentation).

Dieser Assistent führt Sie durch das Projekt und generiert ein Beispielprojekt, das Konfigurations- und Beispiel-Monitoring-Journeys enthält. Die Struktur sieht ungefähr so aus:

Bildschirm „synthetics-replicator-tests“

Webentwickler:innen werden die meisten Elemente – README, package.json- und Lock-Dateien usw. – vertraut sein. Die Hauptkonfiguration für Ihre Monitore ist in synthetics.config.ts verfügbar (siehe unten). Diese Konfiguration kann so geändert werden, dass sie die produktions- und entwicklungsspezifische Konfiguration enthält. Dies ist wichtig, um die Kräfte zu bündeln und für die e2e-Tests dieselben Monitore wiederzuverwenden und als e2e-Test- und Produktionsmonitore beliebige Journeys zu ermöglichen. Auch wenn das in diesem Beispiel nicht vorkommt, weisen wir auf Folgendes hin: Wenn Sie es vorziehen, dass das Monitoring statt von der Elastic-Infrastruktur von Ihrer eigenen dedizierten Elastic-Instanz aus erfolgt, können Sie Details zu privaten Standorten einbeziehen.

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;
};

Schreiben Ihrer ersten Journey

Obwohl die Konfiguration oben für alle Monitore im Projekt gilt, kann sie für einen bestimmten Test außer Kraft gesetzt werden.

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

});

Der Wrapper @elastic/synthetics stellt viele Standardtestmethoden zur Verfügung, wie z. B. die Konstrukte before und after, die das Einrichten und Entfernen typischer Eigenschaften in den Tests ermöglichen. Außerdem sorgt er für die Unterstützung vieler gängiger Assertion-Helper-Methoden. Eine vollständige Liste der unterstützten „expect“-Methoden finden Sie in der Dokumentation. Das Playwright-Objekt page wird ebenfalls bereitgestellt, was es uns ermöglicht, alle erwarteten Aktivitäten durchzuführen, die in der API vorgesehen sind, wie z. B. das Auffinden von Seitenelementen und das Simulieren von User Events wie Klicks, die im folgenden Beispiel dargestellt werden.

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


});

Wie im Beispiel oben zu sehen ist, stehen auch die Konstrukte journey und step zur Verfügung. Dieses Konstrukt spiegelt die Praxis der verhaltensgesteuerten Entwicklung (Behavior Driven Development, BDD) wider, bei der die User Journey in Tests durch die Anwendung dargestellt wird.

Entwickler:innen können als Teil ihrer Funktionsentwicklung die Tests gegen eine lokal laufende Anwendung ausführen, um erfolgreiche und fehlgeschlagene Schritte im Nutzer-Workflow zu sehen. Im Beispiel unten ist der Befehl zum Starten des lokalen Servers oben im Bildschirm durch einen blauen Kasten hervorgehoben. Der Befehl zum Ausführen des Monitors ist weiter unten durch einen roten Kasten hervorgehoben.

Die grünen Häkchen neben den Journey-Schritten zeigen an, dass alle unsere Tests bestanden wurden. Juhu!

Gating Ihrer CI-Pipelines

Es ist wichtig, die Ausführung der Monitore innerhalb Ihrer CI-Pipeline als Tor für die Zusammenführung von Codeänderungen und das Hochladen der neuen Version Ihrer Monitore zu nutzen. In diesem und im nächsten Abschnitt werden wir auf jeden der Jobs in unserem GitHub Actions-Workflow eingehen.

Der Job „test“ startet eine Testinstanz und führt unsere User Journeys aus, um unsere Änderungen zu validieren (siehe Abbildung unten). Dieser Schritt sollte bei Pull-Requests ausgeführt werden, um die Änderungen der Entwickler:innen zu validieren, aber auch bei Push-Requests.

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

Beachten Sie, dass wir, anders als bei der Journey-Ausführung auf unserem lokalen Rechner, die Option --reporter=junit verwenden, wenn wir npx @elastic/synthetics ausführen, damit der CI-Job sehen kann, welche Journey-Tests bestanden wurden und welche leider fehlgeschlagen sind.

Automatisches Hochladen von Monitoren

Um sicherzustellen, dass in Elastic Uptime die neuesten Monitore verfügbar sind, ist es ratsam, die Monitore programmatisch als Teil des CI-Workflows zu „pushen“, wie es die Beispielaufgabe unten tut. Unser Workflow hat einen zweiten Job namens push, der von der erfolgreichen Ausführung des Jobs test abhängt, der Ihre Monitore in Ihren Cluster hochlädt (siehe unten). Dieser Job ist in unserem Workflow so konfiguriert, dass er bei „push“ ausgeführt wird, um sicherzustellen, dass die Änderungen nicht nur im Rahmen eines Pull-Requests aufgekommen sind, sondern tatsächlich auch validiert wurden.

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

Der @elastic/synthetics init-Assistent generiert beim Erstellen Ihres Projekts einen Push-Befehl, der aus dem Projektordner heraus ausgelöst werden kann. Dies wird im Folgenden anhand der steps- und working_directory-Konfiguration gezeigt. Der Push-Befehl erfordert den API-Schlüssel aus Ihrem Elastic-Cluster, der als Secret in einem vertrauenswürdigen Vault gespeichert und über eine Workflow-Umgebungsvariable referenziert werden sollte. Wichtig ist auch, dass die Monitore vor dem Pushen der aktualisierten Monitorkonfiguration an Ihre Elastic Synthetics-Instanz den Test bestehen, um eine Unterbrechung des Produktions-Monitorings zu verhindern. Im Gegensatz zu e2e-Tests, die gegen eine Testumgebung laufen, wirken sich fehlerhafte Monitore auf die SRE-Aktivitäten aus. Das macht es nötig, jede Änderung vorab zu validieren. Daher sollten Sie über die Option needs eine Abhängigkeit auf Ihren Prüfschritt anwenden.

Monitoring mit Elastic Synthetics

Nach dem Hochladen der Monitore können SRE-Teams regelmäßig überprüfen, ob der Nutzer-Workflow wie vorgesehen funktioniert – nicht nur, weil die Monitore nach einem regelmäßigen Zeitplan laufen, der für das Projekt und die einzelnen Tests konfiguriert ist (siehe oben), sondern auch, weil der Status aller Monitorläufe überprüft und die Monitore bei Bedarf ausgeführt werden können.

Dem Tab „Monitors Overview“ kann auf einen Blick der Status aller konfigurierten Monitore entnommen werden, und über das Dreipunkt-Menü der Karte können Sie den Monitor manuell starten.

Elastic Observability-Bildschirm „Monitors“

Vom Bildschirm „Monitors“ gelangen wir auch direkt zu einem Überblick über die Ausführung der einzelnen Monitore, um so Fehler untersuchen zu können.

Elastic Observability-Bildschirm „Test run details“

Die andere Monitoring-Superpower, auf die SREs jetzt zurückgreifen können, ist die enge Verzahnung dieser Monitore mit Tools, die SREs bereits von der Prüfung der Performance und Verfügbarkeit von Anwendungen kennen, wie z. B. APM, Metriken und Logdaten. Mit den intuitiven Optionen im Menü Investigate können SREs potenzielle Ausfälle oder Engpässe untersuchen.

Außerdem findet das Auffinden von Problemen und die automatische Benachrichtigung über mögliche Probleme in einem ausgewogenen Verhältnis statt. SREs, die bereits mit dem Festlegen von Regeln und Schwellenwerten für die Benachrichtigung über Probleme vertraut sind, werden sich freuen, dass dies auch für Browser-Monitore möglich ist. Wie eine Regel bearbeitet werden kann, wird im Folgenden an einem Beispiel gezeigt.

Elastic Observability-Bildschirm „Rules“

Der Status der Browser-Monitore kann so konfiguriert werden, dass nicht nur geprüft wird, ob einzelne oder gemeinsame Monitore mehrmals ausgefallen sind, wie in der Statusprüfung oben, sondern auch so, dass anhand des Prozentsatzes der bestandenen Prüfungen innerhalb eines bestimmten Zeitraums die Gesamtverfügbarkeit beurteilt werden kann. SREs sind nicht nur daran interessiert, auf Probleme im Sinne des herkömmlichen Produktionsmanagements zu reagieren, sondern sie wollen auch die Verfügbarkeit von Anwendungen verbessern.

Aufzeichnen von Nutzer-Workflows

Beim Aufsetzen von e2e-Tests im Rahmen des Entwicklungszyklus kommt es zuweilen vor, dass Teams Dinge übersehen, und die bisherigen Tools sind auf Entwicklungsteams ausgerichtet. Egal, wie sehr sich alle zusammen mit multidisziplinären Teams Mühe geben, ein intuitives Produkt zu entwickeln, kann doch nicht ausgeschlossen werden, dass Nutzer:innen Anwendungen in einer Weise nutzen, die so eigentlich nicht vorgesehen war. Außerdem decken die von den Entwickler:innen geschriebenen Monitore nur die erwarteten Workflows ab und es werden Alarme ausgegeben, wenn diese Monitore in der Produktion versagen oder aber wenn sie sich nach Anwendung der Anomalieerkennung anders als vorgesehen verhalten.

Wenn Probleme bei Nutzer:innen auftreten, hilft es, das Problem im selben Format wie unsere Monitore nachzustellen. Wichtig ist auch, beim Erstellen von User Journeys die Erfahrung von SREs zu nutzen, da sie intuitiv auch Ausfallszenarien berücksichtigen, was Entwickler:innen vielleicht nicht tun, weil sie sich auf positive Szenarien konzentrieren. Allerdings werden nicht alle SREs die Erfahrung oder das Selbstvertrauen haben, diese Journeys mit Playwright und @elastic/synthetics zu schreiben.

Video thumbnail

Hier kommt der Elastic Synthetics Recorder ins Spiel! Im Video oben erfahren Sie, wie Sie den Recorder nutzen können, um die Schritte einer User Journey aufzuzeichnen und in eine JavaScript-Datei zu exportieren, die Sie anschließend in Ihr Monitor-Projekt aufnehmen können. Damit erhält das Entwicklungsteam wertvolles Feedback und es erleichtert das Testen von Korrekturen zur Problemlösung. Dies alles ist aber nur möglich, wenn wir alle unsere Kräfte bündeln und diese Monitore gemeinsam nutzen.

Jetzt ausprobieren

In Version 8.8 sind @elastic/synthetics und die Anwendung Elastic Synthetics allgemein verfügbar und der Recorder befindet sich in der Beta-Phase. Wenn Sie uns und andere daran teilhaben lassen möchten, wie es Ihnen mit dem synthetischen Monitoring gelungen ist, Entwicklungs- und Operations-Teams zusammenzubringen, würden wir gern von Ihnen hören: entweder über die Kategorie „Uptime“ in den „Discuss“-Community-Foren oder über Slack.

Happy Monitoring!

Englische Originalversion ursprünglich am 6. Februar 2023 veröffentlicht; am 23. Mai 2023 aktualisiert

Ressourcen
  1. Blogpost zum Ersetzen von End-to-End-Tests durch synthetisches Monitoring
  2. Dokumentation zu Uptime und synthetischem Monitoring
  3. Dokumentation zur Erstellung von Skripts für Browser-Monitore
  4. Leitfaden zur Verwendung des Elastic Synthetics Recorders
  5. Playwright-Website
  6. Dokumentation zu GitHub Actions

Elastic Cloud kostenlos ausprobieren

Richten Sie ein Deployment mit vollem Funktionsumfang beim Cloud-Anbieter Ihrer Wahl ein. Als das Unternehmen hinter Elasticsearch stellen wir unsere Features und unseren Support für Ihre Elastic-Cluster in der Cloud bereit.

Kostenlos ausprobieren