Moment … das Monitoring von AWS-Metriken in Elastic Observability ist echt nur eine Sache von Minuten?

Von

Bahubali Shetti

blog-charts-packages.png

Als Verbraucher:innen und dynamische Unternehmen müssen wir ständig online sein. Und um dem gerecht zu werden, wird derzeit überall auf verteilte Anwendungen umgestellt. Das, gekoppelt mit der Notwendigkeit, sich global divers aufzustellen und in hohem Maße innovationsfähig zu sein, führt dazu, dass Deployments immer komplexer werden.

Die Cloud hat sich zum De-facto-Standard für die Bereitstellung von Anwendungen entwickelt. Und wenn es um die Auswahl eines Cloud-Anbieters geht, entscheiden sich viele Betreiber von Cloud-Deployments wegen der vielen unterstützten Regionen in aller Welt, des großen Angebots an verfügbaren Services (für schnellere Entwicklung und Innovation) und der geringeren Betriebs- und Kapitalkosten für AWS. Entwicklungsteams schätzen bei AWS die Möglichkeit, auf Kubernetes auf Amazon EKS zu migrieren, die neuesten Serverless-Optionen auszutesten und herkömmliche Anwendungen in Tier-Architektur mit besseren Services zu versehen.

Elastic Observability bietet standardmäßig 30 Integrationen für AWS-Services – weitere sind bereits in der Entwicklung.

Einen kurzen Überblick über einige der Integrationen und Funktionen erhalten Sie in folgendem Blogpost:

Darüber hinaus behandeln die folgenden Blogposts wichtige Elastic-Integrationen für AWS-Services:

Die komplette Liste von AWS-Integrationen finden Sie in der Online-Dokumentation von Elastic:

Zusätzlich zu unseren nativen AWS-Integrationen gibt es auch die Elastic Observability-Funktionen zum Aggregieren von Logdaten und Metriken für AWS-Services und die Anwendungen, die auf AWS-Compute-Services laufen (EC2, Lambda, EKS/ECS/Fargate). Alle diese Daten können mit den innovativen Machine-Learning-Funktionen von Elastic visuell und intuitiv analysiert werden, um Performance-Problemen nachzugehen und deren Ursachen zu finden, bevor sie sich auf die Endnutzer:innen auswirken.

Mehr darüber, wie Elastic Observability APM-Funktionen wie Service-Maps, Tracing, Abhängigkeiten und ML-basierte Korrelationen von Metriken bereitstellt, erfahren Sie in den folgenden Blogposts:

Sie haben richtig gelesen: Elastic ermöglicht das Ingestieren, Aggregieren und Analysieren von Metriken für AWS-Services und ‑Anwendungen bei AWS-Compute-Services (EC2, Lambda, EKS/ECS/Fargate). Dabei beschränkt sich Elastic nicht allein auf Logdaten, sondern bietet eine zentralisierte Observability-Lösung für AWS-Umgebungen.

In diesem Blogpost zeige ich, wie Elastic Observability Metriken für eine einfache AWS-Anwendung auf AWS-Services überwachen kann. Dazu gehören:

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

Sobald die Integration installiert ist, laufen die ersten Metriken ein und Sie können sofort mit deren Prüfung starten.

Voraussetzungen und Konfiguration

Wenn Sie die in diesem Blogpost beschriebenen Schritte für sich nachvollziehen möchten, sollten Sie Folgendes beachten:

  • Sie benötigen ein Konto auf Elastic Cloud und ein entsprechendes Stack-Deployment (eine Anleitung finden Sie hier).
  • Sie benötigen ein AWS-Konto mit Berechtigungen zum Abrufen der erforderlichen Daten aus AWS. Entsprechende Angaben finden Sie in unserer Dokumentation.
  • Wir haben die AWS Three Tier-Anwendung verwendet und sie entsprechend der Anleitung in git installiert.
  • Wir führen Sie durch die Schritte zur Installation der allgemeinen Elastic-AWS-Integration, die die vier Services abdeckt, für die wir Metriken sammeln möchten.
    (Vollständige Liste der von der Elastic-AWS-Integration unterstützten Services.)
  • Wir werden hier nicht näher auf das Anwendungs-Monitoring eingehen, da das Monitoring von Anwendungsdaten (Metriken, Logdaten und Traces) auf AWS bereits anderswo ausführlich beschrieben worden ist. Stattdessen beschäftigen wir uns damit, wie AWS-Services problemlos überwacht werden können.
  • Damit wir Metriken sehen können, müssen wir die Anwendung laden. Wir haben auch ein Playwright-Skript erstellt, um die Anwendung mit Traffic zu versorgen.

Überblick über die Three Tier-Anwendung

Bevor wir uns näher mit der Elastic-Konfiguration befassen, werfen wir einen Blick darauf, was wir eigentlich überwachen. Wenn Sie der Anleitung im „AWS Three Tier Web Architecture Workshop“ gefolgt sind, haben Sie das folgende Deployment:

Bereitgestellte Komponenten:

  • 1 VPC mit 6 Subnetzen
  • 2 AZs
  • 2 Webserver pro AZ
  • 2 Anwendungsserver pro AZ
  • 1 nach außen gerichteter Application Load Balancer
  • 1 nach innen gerichteter Application Load Balancer
  • 2 NAT-Gateways zur Verwaltung des Traffics zur Anwendungsschicht
  • 1 Internet-Gateway
  • 1 RDS-Aurora-DB mit einem Lesereplikat

Am Ende dieses Blogposts finden Sie ein Playwright-Skript, mit dem Sie diese Anwendung implementieren können. Das wird dabei helfen, Metriken zu beschaffen, die die Dashboards auf Trab halten.

Einrichtung

Sehen wir uns an, wie Sie sich die Anwendung holen können, wie Sie AWS in Elastic integrieren und was alles ingestiert wird.

Schritt 0: Laden Sie die AWS Three Tier-Anwendung und beschaffen Sie sich die Anmeldeinformationen

Befolgen Sie die in „AWS Three Tier Web Architecture Workshop“ aufgeführten Schritte und die Schritte im Workshop-Link auf git. Der Workshop ist hier aufgeführt.

Wenn die Anwendung installiert ist, besorgen Sie sich die Anmeldeinformationen von AWS. Sie benötigen sie für die Elastic-eigene AWS-Integration.

Es gibt verschiedene Optionen für Anmeldeinformationen:

  • direkte Nutzung von Zugriffsschlüsseln
  • Nutzung temporärer Sicherheitsanmeldeinformationen
  • Nutzung einer gemeinsam genutzten Datei mit Anmeldeinformationen
  • Nutzung eines IAM-Rollen-ARN (Amazon Resource Name)

Mehr über die erforderlichen Anmeldeinformationen finden Sie hier und mehr über die erforderlichen Berechtigungen finden Sie hier.

Schritt 1: Konto auf Elastic Cloud erstellen

Befolgen Sie die Anleitung zum Einstieg in Elastic Cloud.

Schritt 2: Elastic-AWS-Integration installieren

Gehen Sie zur AWS-Integration bei Elastic.

Klicken Sie auf Add AWS .

An dieser Stelle müssen Sie Ihre Anmeldeinformationen eingeben. Diese werden als Richtlinie in Elastic gespeichert und diese Richtlinie wird als Teil der Installation für den Agent im nächsten Schritt verwendet.

Wie Sie sehen können, sammelt die allgemeine Elastic-AWS-Integration einen Großteil der Daten aus 30 AWS-Services. Wenn Ihnen das zu allgemein ist, können Sie individuelle Integrationen installieren.

Schritt 3: Mit AWS-Integration Elastic Agent installieren

Nachdem Sie nun eine Integrationsrichtlinie erstellt haben, gehen Sie in Elastic unter Management zum Abschnitt Fleet.

Wählen Sie den Namen der Richtlinie aus, die Sie im letzten Schritt erstellt haben.

Führen Sie Schritt 3 in der Anleitung im Fenster Add Agent aus. Dazu müssen Sie Folgendes tun:

1: EC2-Instanz starten

  • mindestens t2.medium
  • welche Linux-Variante ist Ihnen überlassen
  • beim Starten der EC2-Instanz muss offene Reservierung gestattet werden

2: Bei der Instanz anmelden und die Befehle auf dem Tab Linux Tar ausführen (siehe Beispiel)

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

Schritt 4: Die Anwendung mit Traffic versorgen

+++While getting the application running is fairly easy, there is nothing to

Mit dem folgenden einfachen Skript, das Sie mit Playwright ausführen können, können Sie der Website für die AWS Three Tier-Anwendung Traffic hinzufügen:

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)

});

Dieses Skript startet drei Browser, aber Sie können diese Last auf einen Browser in der Datei playwright.config.ts auf einen Browser begrenzen.

Für diese Übung haben wir diesen Traffic bei einem Intervall von fünf Minuten ungefähr fünf Stunden laufen lassen und dabei die Website getestet.

Schritt 5: AWS-Dashboards aufrufen

Nachdem wir den Elastic Agent zum Laufen gebracht haben, können wir zu den zugehörigen AWS-Dashboards gehen und uns anzeigen lassen, was ingestiert wird.

Sie können die AWS-Integration-Dashboards finden, indem Sie einfach in der Elastic-Suchleiste nach ihnen suchen. Für diesen Blogpost sind die folgenden Dashboards relevant:

  • [Metrics AWS] EC2 Overview
  • [Metrics AWS] ELB Overview
  • [Metrics AWS] RDS Overview
  • [Metrics AWS] NATGateway Overview

Sehen wir uns an, was es in den Dashboards zu sehen gibt!

Alle diese Dashboards gehören zum Standardlieferumfang und bei allen folgenden Abbildungen haben wir die Ansichten so eingerichtet, dass nur die relevanten Elemente unserer Anwendung dargestellt werden.

Bei allen Dashboards wurde der Zeitraum auf die Zeit begrenzt, in der wir den Traffic-Generator laufen hatten.

Elastic Observability-Dashboard „EC2 Overview“
Elastic Observability-Dashboard „EC2 Overview“

Wir haben nach unseren 4 EC2-Instanzen (2 Webserver und 2 Anwendungsserver) gefiltert und sehen jetzt Folgendes:

1: Alle 4 Instanzen laufen und zeigen in den Statusprüfungen keine Fehler.

2: Die durchschnittliche CPU-Nutzung im zu betrachtenden Zeitraum ist ohne Befund.

3: Wir sehen, wie die Netzwerk-Bytes ein- und ausgehen und sich, während die Datenbank mit Zeilen befüllt wird, immer weiter ansammeln.

Diese Übung zeigt nur einen kleinen Teil der Metriken, die geprüft werden können. AWS EC2 bietet aber noch viel mehr. Eine vollständige Liste der verfügbaren Metriken finden Sie in der AWS-Dokumentation, darunter auch die Dimensionen, mit denen sich die Suche auf konkrete Instanzen usw. eingrenzen lässt.

Elastic Observability-Dashboard „ELB Overview“
Elastic Observability-Dashboard „ELB Overview“

Für das ELB-Dashboard filtern wir nach unseren beiden Load Balancers (externer Web-Load-Balancer und interner Anwendungs-Load-Balancer).

Das fertig vorkonfigurierte Dashboard präsentiert Metriken, die für den Anwendungs-ELB spezifisch sind. Für einen Großteil der in der AWS-Dokumentation aufgeführten Anwendungs-ELB-spezifischen Metriken stehen entsprechende Diagrammdarstellungen zur Verfügung.

Wenn wir uns unsere beiden Load Balancers ansehen, stellen wir fest:

1: Beide Hosts (mit ELBs verbundene EC2-Instanzen) laufen ohne Beanstandungen.

2: Die Zahl der Load Balancer Capacity Units (Angabe, wie viele Sie nutzen) und der Anfragen stieg während des betrachteten Zeitraums so wie erwartet.

3: Wir haben uns für die Anzeige der 4XX- und der 2XX-Werte entschieden. Die 4XX-Werte helfen uns dabei, Probleme mit der Anwendung oder Konnektivität mit den Anwendungsservern zu identifizieren.

Elastic Observability-Dashboard „RDS Overview“
Elastic Observability-Dashboard „RDS Overview“

Für AuroraDB, in RDS bereitgestellt, haben wir im Dashboard nach den primären und sekundären Instanzen von Aurora gefiltert.

Wie bei EC2 und ELB können für die meisten RDS-Metriken aus Cloudwatch auch neue Diagramme und Tabellen erstellt werden. Dieses Dashboard wurde so konfiguriert, dass folgende Metriken angezeigt werden:

1: Einfügen-Durchsatz („Insert Throughput“) und Auswählen-Durchsatz („Select Throughput“)

2: Latenz beim Schreiben („Write Latency“)

3: CPU-Auslastung („CPU Usage“)

4: allgemeine Zahl von Verbindungen im betrachteten Zeitraum

Elastic Observability-Dashboard „NATGateway Overview“
Elastic Observability-Dashboard „NATGateway Overview“

Wir haben die Ansicht so gefiltert, dass nur unsere beiden NAT-Instanzen für die Anwendungsserver angezeigt werden. Wie auch bei den anderen Dashboards stehen bei Bedarf weitere Metriken für das Erstellen von Diagrammen/Tabellen zur Verfügung.

Im NAT-Dashboard können wir Folgendes sehen:

1: Die NAT-Gateways funktionieren gut, alle Pakete werden weitergeleitet.

2: Die Zahl der aktiven Verbindungen vom Webserver liegt im erwartbaren Rahmen.

3: Die Metriken für ein- und ausgehende Bytes sind ganz normal.

Herzlichen Glückwunsch, Sie haben damit das Monitoring von Metriken aus wichtigen AWS-Services für Ihre Anwendung gestartet!

Was kann noch auf AWS überwacht werden?

Hinzufügen von Logdaten aus AWS-Services

Das Monitoring muss nicht auf Metriken beschränkt bleiben – Sie können auch Logdaten hinzufügen. Es gibt verschiedene Optionen für das Ingestieren von Logdaten:

1. Die AWS-Integration im Elastic Agent verfügt über eine Logdaten-Einstellung. Aktivieren Sie einfach die entsprechenden Optionen. Nehmen wir als Beispiel das Ingestieren der Aurora-Logdaten aus RDS. Wir gehen zur Elastic Agent-Richtlinie und aktivieren dort einfach „Collect logs from CloudWatch“ (siehe unten). Als Nächstes wird der Agent aktualisiert. Dies geschieht über die Fleet-Management-Benutzeroberfläche.

2. Sie können den Lambda Logs Forwarder installieren. Mit dieser Option legen Sie fest, dass Logdaten aus mehreren Speicherorten abgerufen werden. Die entsprechende Architektur können Sie dem Diagramm unten entnehmen.

Diese Option wird in diesem Blogpost genauer beschrieben.

Analysieren Ihrer Daten mit Machine Learning (ML) von Elastic

Sobald sich die Metriken und/oder Logdaten in Elastic befinden, können Sie beginnen, Ihre Daten mit den ML-Funktionen von Elastic zu analysieren. Einen ausführlichen Überblick über diese Features finden Sie hier:

Darüber hinaus bietet der Elastic-Blog zahlreiche zusätzliche Videos und Artikel zum Thema.

Fazit: Das Monitoring von Metriken aus AWS-Services mit Elastic Observability ist ganz einfach.

Ich hoffe, dass ich Ihnen einen Eindruck davon vermitteln konnte, wie Sie mithilfe von Elastic Observability Metriken aus AWS-Services überwachen können. Lassen Sie mich noch einmal zusammenfassen, was Sie hier gelernt haben:

  • Elastic Observability unterstützt das Ingestieren und Analysieren von Metriken aus AWS-Services.
  • Das Einrichten des Ingestierens von Metriken aus AWS-Services über den Elastic Agent ist einfach.
  • Elastic Observability verfügt über mehrere vorkonfigurierte Dashboards für AWS-Services, die Sie nutzen können, um erst einmal die dort präsentierten Informationen zu betrachten und gegebenenfalls an Ihre Anforderungen anzupassen.
  • Die AWS-Integration in Elastic Observability bietet Unterstützung für mehr als 30 AWS-Services, Tendenz steigend.
  • Wie in entsprechenden Blogposts bereits angemerkt, können Sie für die Analyse der Metriken für Ihre AWS-Services Machine-Learning-Funktionen von Elastic einsetzen.

Sie können Elastic Cloud 7 Tage lang kostenlos ausprobieren. Dazu müssen Sie sich lediglich über den AWS Marketplace anmelden und ein Deployment in einer der vielen Elastic Cloud-Regionen auf AWS in der ganzen Welt bereitstellen – das ist in wenigen Minuten erledigt. Wenn Sie Elastic über den AWS Marketplace erwerben, werden die Kosten über Ihre konsolidierte Monatsabrechnung bei AWS ab- und auf Ihre Mindestabnahmeverpflichtung bei AWS angerechnet.

Die Entscheidung über die Veröffentlichung der in diesem Blogpost beschriebenen Leistungsmerkmale und Funktionen oder deren Zeitpunkt liegt allein bei Elastic. Es ist möglich, dass nicht bereits verfügbare Leistungsmerkmale oder Funktionen nicht rechtzeitig oder überhaupt nicht veröffentlicht werden.

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