AWS-Distro für OpenTelemetry & ECS

Die Überwachung ist ein wichtiger Bestandteil der Aufrechterhaltung der Zuverlässigkeit, Verfügbarkeit und Leistung Ihres ECS-Workloads. Sie sollten Überwachungsdaten von allen Bestandteilen Ihrer Architektur sammeln, damit Sie im Falle eines Ausfalls an mehreren Stellen leichter Fehler beheben können.

Lassen Sie uns zuerst visualisieren

Bevor wir uns mit der Implementierung befassen, sollten wir uns zunächst ein Bild von der Einrichtung machen, zumindest ziehe ich es immer vor, ein Diagramm zu zeichnen, wie es am Ende aussehen soll. Sie werden sofort sehen, dass die Einrichtung ziemlich einfach und geradlinig ist. Wenn Sie sich den Titel dieses Artikels und das unten stehende Diagramm ansehen, haben Sie es vielleicht schon herausgefunden. Schön für Sie, bleiben Sie trotzdem dran.

 

 

Wir können hier einige Dinge feststellen. Erstens: Es sieht so aus, als gäbe es einen zweiten Container, auf dem die AWS-Distro für OpenTelemetry läuft. Dabei handelt es sich um ein Tool, das Metriken/Traces sammelt und sie irgendwo veröffentlicht. In unserem Fall ist das ein verwalteter AWS Prometheus Service und AWS X-Ray. Zweitens sieht es so aus, als würde Grafana sowohl Prometheus als auch X-Ray nutzen.

AWS OTel-Kollektor

Die AWS-Distro für OpenTelemetry Collector (ich werde sie im Laufe des Artikels als AWS OTel Collector oder ADOT Collector bezeichnen) ist eine von AWS unterstützte Version des Upstream OpenTelemetry Collector und wird von Amazon verteilt. Es umfasst sowohl Docker-Statistiken (zeigt CPU, Speicher usw. an) als auch den ECS Task Metadata Endpoint (AWS stellt in jedem Container einen lokalen Metadaten-Endpunkt zur Verfügung, der Informationen über die Aufgabe anzeigt).

Wie Sie im vorstehenden Diagramm sehen können, ist der AWS OTel Collector ein Sidecar-Container. Es ist ein Container, der neben jedem von uns bereitgestellten Service läuft. (Im Wesentlichen hat jeder Service seine eigene Aufgabendefinition und in dieser Aufgabendefinition definieren wir 2 Container, einen für die Anwendung und einen für den AWS OTel Collector, unseren Sidecar).

Nachdem ich mich einige Stunden durch den verstreuten Quellcode und die Dokumentation auf Github gelesen habe, um Teile der Dokumentation zusammenzufügen, habe ich herausgefunden, wie das Ganze unter der Haube funktioniert. Die OpenTelemetry-Kollektoren implementieren einen Prometheus Remote Write Exporter. Der Collector ist eine übliche Metrik-Senke in Sammlungspipelines, in der Metrikdatenpunkte empfangen und schnell an Exporteure "weitergeleitet" werden. Wenn ich es richtig verstanden habe, sieht es in etwa so aus: (Da der ADOT Collector das Konzept der Pipelines verwendet, gibt es im ADOT Collector mehr steckbare Komponenten, z.B. den X-Ray Receiver/Exporter).

 

 

Bitte beachten Sie, wenn das oben Gesagte zu abstrakt ist, machen Sie sich keine Sorgen - ich habe mir aus reiner Begeisterung angeschaut, wie das Ganze unter der Haube funktioniert. Eine Dokumentation ist verfügbar unter: aws-otel.github.io/docs. Außerdem verwende ich die Begriffe ADOT Collector und AWS OTel Collector synonym, da beide dasselbe bezeichnen.

Der Seitenwagen in Aktion

Nun, da wir eine gute Vorstellung davon haben, was gebaut werden muss, können wir uns an die Arbeit machen. Bevor wir unseren ECS-Dienst bereitstellen können, müssen wir einige Voraussetzungen erfüllen. Ich gehe davon aus, dass Sie diese selbst einrichten können, oder Sie tun einfach so, als ob und lesen weiter.

Voraussetzungen

• AWS Prometheus Arbeitsbereich.

• ECS IAM-Rolle mit den folgenden verwalteten IAM-Richtlinien AWSXrayWriteOnlyAccess, AmazonECSTaskExecutionRolePolicy und AmazonPrometheusRemoteWriteAccess.

Beachten Sie, dass AWS Prometheus automatisch skaliert, wenn Ihr Überwachungsbedarf wächst. Es bietet hochverfügbare, Multi-AZ-Bereitstellungen.

Seitenwagen & Container Definition

Angenommen, Sie haben eine Aufgabendefinition erstellt und die Containerdefinition mit Ihrer Anwendung vorkonfiguriert. Fügen wir der Container-Definition einen zusätzlichen Container hinzu. Wir werden ein Muster verwenden, das Sidecar-Muster. Sie erinnern sich, dass der Sidecar ein Container ist, der neben Ihrer Anwendung als separater Container lebt. Wenn wir von Containern sprechen, sollte ein Container eine bestimmte Aufgabe erfüllen, während ein Sidecar eine andere Aufgabe hat. In unserem Fall ist der Sidecar für alles gut, was der ADOT Collector tut (Datenaufnahme). Unsere Anwendung sollte nicht diejenige sein, die diese schwere Aufgabe übernimmt!

Legen Sie für den Sidecar-Container die folgenden Werte in der Containerdefinition fest:

• Bild: public.ecr.aws/aws-observability/aws-otel-collector:latest
• Befehl: --config=/etc/ecs/ecs-amp-xray.yaml
• ENV: AWS_PROMETHEUS_ENDPOINT = Der Wert sollte der Remote-Schreibendpunkt aus dem AWS Prometheus-Arbeitsbereich sein, den Sie gerade erstellt haben.

Der Sidecar-Container sollte wie folgt aussehen:

      {
          "name": "aws-otel-collector",
          "image": "public.ecr.aws/aws-observability/aws-otel-collector:v0.14.1",
          "cpu": 0,
          "links": [],
          "portMappings": [],
          "essential": true,
          "entryPoint": [],
          "command": [
              "--config=/etc/ecs/ecs-amp-xray.yaml"
          ],
          "environment": [
              {
                  "name": "AWS_PROMETHEUS_ENDPOINT",
                  "value": "https://aps-workspaces.eu-west-1.amazonaws.com/workspaces/ws-3e63f902-e43a-40d0-a86e-1a47d16a6a71/api/v1/remote_write"
              }
          ],
          "mountPoints": [],
          "volumesFrom": [],
          "dnsServers": [],
          "dnsSearchDomains": [],
          "dockerSecurityOptions": [],
          "dockerLabels": {},
          "logConfiguration": {
              "logDriver": "awslogs",
              "options": {
                  "awslogs-create-group": "True",
                  "awslogs-group": "/ecs/ecs-aws-otel-sidecar-collector",
                  "awslogs-region": "eu-west-1",
                  "awslogs-stream-prefix": "ecs"
              }
          },
          "systemControls": []
      }

Hinweis: Verknüpfen Sie die ECS IAM-Rolle, die Sie als Voraussetzung erstellt haben, mit der Aufgabendefinition. (Ich verwende dieselbe Rolle sowohl für die Aufgabenrolle als auch für die Aufgabenausführungsrolle).

Einrichten des ECS-Dienstes

Erstellen Sie den ECS-Service. Stellen Sie sicher, dass der ECS-Service den AWS OTel-Kollektor nicht als Ziel in einer Zielgruppe registriert (Sie sollten dies verhindern, indem Sie dem Sidecar-Container kein Port-Mapping zuweisen). Führen Sie einige Anfragen aus, um Datenverkehr zu erzeugen, damit der AWS OTel-Kollektor Metriken an unsere AWS Prometheus-Instanz und X-Ray sendet.

Wenn alles gut gegangen ist, sollten Sie einige Sidecar-Container-Protokolle sehen.

2021-11-26T13:46:18.772Z info service/collector.go:132 Everything is ready. Begin running and processing data.

2021-11-26T13:46:18.772Z info service/telemetry.go:116 Serving Prometheus metrics {"address": ":8888", "level": "basic", "service.instance.id": "92c6a1bf-99f5-4357-8319-7f79893962db", "service.version": "latest"}

Röntgenstrahlen

Standardmäßig hat die AWS-Distribution für den OpenTelemetry Collector den Export nach AWS X-Ray ohne zusätzliche Konfigurationen aktiviert. Dabei werden die mit AWS X-Ray OTLP formatierten Trace-Daten in das AWS X-Ray-Format konvertiert und dann an den AWS X-Ray-Service exportiert.

 

 

Grafana

Grafana ist eine großartige Möglichkeit, Ihre Metriken zu visualisieren. Sie können einen AWS Managed Grafana-Arbeitsbereich in weniger als 5 Minuten einrichten und AWS Prometheus als Datenquelle einbinden. Ich empfehle Ihnen, sich über die Konfiguration von Datenquellen in Grafana zu informieren.

 

 

Grafana hat eine steile Lernkurve, wenn es um die Konfiguration von Dashboards und Datenquellen geht. Ich empfehle dringend, bei Grafana den As Code-Ansatz zu verfolgen. Das AWS Observability-Team hat einen schönen Artikel über die Verwendung des Grafana Terraform-Anbieters veröffentlicht. Sie können auch Ihr eigenes benutzerdefiniertes Dashboard mit PromQL erstellen, indem Sie ein benutzerdefiniertes Dashboard erstellen und ein Panel hinzufügen, das AMP als Datenquelle verbindet.

curl https://raw.githubusercontent.com/aws-samples/ecsdemo-amp/main/grafana/AMP_ECS_Task_Monitoring.json -o AMP_ECS_Task_Monitoring.json

Wenn Sie sich einen ersten Überblick verschaffen möchten, sollten Sie mit der obigen Aufstellung das gleiche Ergebnis erzielen, wie ich es oben eingestellt habe.

Fußnoten

• Ich würde empfehlen, die Alarmierung in Prometheus zu konfigurieren und/oder die vereinheitlichte Alarmierung zu nutzen, die Grafana in 8.0 veröffentlicht hat.

• Setzen Sie für jede Aufgabe einen Sidecar-Container ein. Denken Sie bei der Arbeit mit Containern immer an die Trennung der Verantwortlichkeiten.

• Sowohl Grafana als auch Prometheus sind als Docker-Images verfügbar.