Unabhängigkeit mit OpenTelemetry auf Elastic

Von

Bahubali Shetti

illustration-scalability-gear-1680x980_(1).jpg

Die Nachfrage nach schnelleren, besser skalierbaren Diensten nimmt zu. Apps ziehen sich wie ein roter Faden durch unseren Alltag – von der App für den Lieferservice von Lebensmitteln über die Banking-App für die Verwaltung von Konten bis hin  zu Apps für die Vereinbarung von Arztterminen. Diese Apps müssen nicht nur hinsichtlich der Funktionen, sondern auch hinsichtlich der Nutzerkapazität erweiterbar sein. Die Dimensionen und das Bestreben nach globaler Reichweite führen dazu, dass diese nachfragestarken Cloud-Anwendungen immer komplexer werden.

Um mit der Nachfrage Schritt zu halten, werden die meisten dieser Online-Anwendungen und -Dienste (z. B. mobile Anwendungen, Webseiten, SaaS) auf eine verteilte Microservice-basierte Architektur und Kubernetes umgestellt. Wie lassen sich Produktion, Skalierung und Verfügbarkeit des Dienstes nach der Migration der App in die Cloud verwalten und überwachen? OpenTelemetry entwickelt sich schnell zum De-facto-Standard für die Instrumentierung und Erfassung von Telemetriedaten für Kubernetes-Anwendungen.

OpenTelemetry (OTel) ist ein Open-Source-Projekt, das eine Sammlung von Tools, APIs und SDKs bereitstellt, mit denen Telemetriedaten (Metriken, Logs und Traces) erzeugt, gesammelt und exportiert werden können, um die Leistung und das Verhalten von Software zu verstehen. OpenTelemetry ist seit Kurzem ein CNCF-Inkubationsprojekt und wird von einer stark wachsenden Community und zahlreichen Anbietern unterstützt.

OTel bietet zwar eine Standardmethode zur Instrumentierung von Anwendungen mit einem Standard-Telemetrieformat, aber keine Backend- oder Analytics-Komponenten. Die Verwendung von OTel-Bibliotheken beim Monitoring von Anwendungen, Infrastrukturen und Benutzererfahrungen ermöglicht daher eine flexible Auswahl des geeigneten Observability-Tools. Beim Monitoring der Anwendungsleistung (APM) besteht keine Anbieterbindung mehr.

Elastic Observability bietet native Unterstützung für OpenTelemetry und das OpenTelemetry-Protokoll (OTLP), um  Traces, Metriken und Logs zu ingestieren. Sämtliche APM-Funktionen von Elastic Observability sind mit OTel-Daten verfügbar. Daher sind für OTel-Daten die folgenden (und weitere) Funktionen verfügbar:

  • Service Maps
  • Dienstdetails (Latenz, Durchsatz, fehlgeschlagene Transaktionen)
  • Abhängigkeiten zwischen Diensten
  • Transaktionen (Traces)
  • ML-Korrelationen (speziell für Latenz)
  • Dienstlogs

Zusätzlich zum APM von Elastic und der zentralen Ansicht der Telemetriedaten können Sie jetzt die leistungsstarken Machine-Learning-Funktionen von Elastic nutzen, um den Analyseaufwand zu verringern und die MTTR durch Warnmeldungen zu reduzieren.

Aufgrund seiner Open-Source-Tradition unterstützt Elastic auch andere CNCF-basierte Projekte wie Prometheus, Fluentd, Fluent Bit, Istio, Kubernetes (K8S) und viele mehr.  

In diesem Blog erfahren Sie Folgendes:

  • Wie Sie mit wenigen einfachen Schritten eine gängige OTel-instrumentierte Demoanwendung (HipsterShop) so konfigurieren, dass sie in Elastic Cloud ingestiert wird
  • Einige der APM-Funktionen und -Features von Elastic für OTel-Daten und wie Sie die Daten in Elastic nutzen können

In folgenden Blogs beschreiben wir, wie Machine Learning von Elastic mit OTel-Telemetriedaten verwendet werden kann, wie OTel-Anwendungsmetriken für bestimmte Sprachen instrumentiert werden können, wie wir Prometheus-Ingest über den OTel Collector unterstützen können und vieles mehr. Bleiben Sie dran!

Voraussetzungen und Konfiguration

Wenn Sie diesem Blog weiter folgen möchten, finden Sie hier einige der Komponenten und Details, mit denen wir die Konfiguration eingerichtet haben:

  • Stellen Sie sicher, dass Sie ein Konto auf Elastic Cloud und einen bereitgestellten Stack haben (siehe diese Anleitung).
  • Wir haben eine Variante der beliebten HipsterShop-Demoanwendung verwendet. Sie wurde ursprünglich von Google geschrieben, um Kubernetes für eine Vielzahl von Varianten zu präsentieren, wie z. B. die Demoanwendung für OpenTelemetry. Um die App zu verwenden, rufen Sie diese Seite auf und befolgen Sie die Bereitstellungsanleitung.
  • Außerdem verwenden wir eine Version der Anwendung, die manuell mit OTel instrumentier wurde. Bei dieser Blog-Konfiguration wurde keine automatische OTel-Instrumentierung verwendet.
  • Speicherort unserer Cluster. Wir haben Google Kubernetes Engine (GKE) verwendet, aber Sie können eine beliebige Kubernetes-Plattform Ihrer Wahl verwenden. 
  • Elastic kann zwar Telemetriedaten direkt von OTel instrumentierten Diensten ingestieren, wir werden uns jedoch auf die traditionellere Bereitstellung konzentrieren, bei der der OpenTelemetry Collector verwendet wird.
  • Anstelle der Dienste Prometheus und FluentD/Fluent Bit, die normalerweise zum Abrufen aller Kubernetes-Daten verwendet werden, werden hier Kubernetes-Agents verwendet. Dies wird in späteren Blogs beschrieben.

Dies ist die Konfiguration, die wir in diesem Blog einrichten:

In diesem Blog verwendete Konfiguration zum Ingest von OpenTelemetry-Daten

Einrichtung

Sie werden nun schrittweise durch die folgenden Aufgaben geführt:

  • Erstellen eines Kontos auf Elastic Cloud
  • Starten eines GKE-Clusters
  • Starten der Anwendung
  • Konfiguration der Configmap von Kubernetes OTel Collector mit Verweis auf Elastic Cloud
  • Verwendung von Elastic Observability APM mit OTel-Daten für erhöhte Transparenz

Schritt 0: Erstellen eines Kontos auf Elastic Cloud

Befolgen Sie die Anleitung zum Einstieg in Elastic Cloud.

Schritt 1: Starten eines K8S-Clusters

Wir haben Google Kubernetes Engine (GKE) verwendet, aber Sie können eine beliebige Kubernetes-Plattform Ihrer Wahl verwenden.

Damit Elastic OpenTelemetry-Daten aus einem Kubernetes-Cluster sammeln kann, müssen keine besonderen Voraussetzungen erfüllt sein. Es funktioniert mit jedem normalen Kubernetes-Cluster auf GKE, EKS, AKS oder Kubernetes-kompatiblen Clustern (selbst bereitgestellt und verwaltet).

Schritt 2: Laden der HipsterShop-Anwendung auf dem Cluster

Stellen Sie Ihre Anwendung in einem Kubernetes-Cluster in einem Cloud-Dienst Ihrer Wahl oder auf einer lokalen Kubernetes-Plattform bereit. Die von mir verwendete Anwendung ist hier verfügbar.

Sobald Ihre Anwendung auf Kubernetes läuft, werden die folgenden Pods (oder eine Variante davon) im Namespace default ausgeführt.

kubectl get pods -n default

Die Ausgabe sollte in etwa wie folgt aussehen:

NAME                                     READY   STATUS    RESTARTS   AGE
adservice-f9bf94d56-5kt89                1/1     Running   0          41h
cartservice-54d5955c59-7lrk9             1/1     Running   0          41h
checkoutservice-57b95c78bb-qqcqv         1/1     Running   0          41h
currencyservice-6869479db8-7tsnj         1/1     Running   0          43h
emailservice-7c95b8766b-mp5vn            1/1     Running   0          41h
frontend-5f54bcb7cf-kxwmf                1/1     Running   0          41h
loadgenerator-bfb5944b6-2qhnw            1/1     Running   0          43h
paymentservice-5bc8f549c8-hkxks          1/1     Running   0          40h
productcatalogservice-665f6879d6-kv29f   1/1     Running   0          43h
recommendationservice-89bf4bfc5-ztcrr    1/1     Running   0          41h
redis-cart-5b569cd47-6wt59               1/1     Running   0          43h
shippingservice-768b94fb8d-8hf9c         1/1     Running   0          41h

In dieser Version haben wir nur alle services und den loadgenerator geladen. Sie sehen, dass der OpenTelemetry Collector noch nicht geladen wurde. (Siehe nächster Schritt.)
Wenn Sie sich die einzelnen Dienst-YAMLs ansehen, stellen Sie fest, dass sie auf den OpenTelemetry Collector auf port 4317 zeigen.

        - name: OTEL_EXPORTER_OTLP_ENDPOINT
          value: "http://otelcollector:4317"

Port 4317 ist der Standardport, an dem OpenTelemetry auf Telemetriedaten von Diensten lauscht.  Daher sollten alle Dienste auf den OTel Collector zeigen.

Schritt 3: Laden des OpenTelemetry Collector, der auf Elastic zeigt

Wie Sie in der Datei otelcollector.yaml unter /deploy-with-collector-k8s sehen werden, gibt es zwei bestimmte Variablen, die im Abschnitt configmap festgelegt werden müssen.

    exporters:
      otlphttp/elastic:
        endpoint: OTEL_EXPORTER_OTLP_ENDPOINT
        headers:
          Authorization: OTEL_EXPORTER_OTLP_HEADERS

OTEL_EXPORTER_OTLP_ENDPOINT ist der APM-Server von Elastic.

OTEL_EXPORTER_OTLP_ENDPOINT stellt Ihre Autorisierung bereit.

Nähere Informationen zu den Variablen finden Sie in der Dokumentation von Elastic zur Konfiguration des OTel Collector.

Woher bekommen Sie diese Werte? 

In der Benutzeroberfläche von Elastic Observability wird Ihnen unter„ APM“, +add data, der folgende Bildschirm angezeigt. 

Klicken Sie auf OpenTelemetry:

Sie sehen die Werte für die Variablen OTEL_EXPORTER_OTLP_ENDPOINT (Ihr APM-Server-Endpoint von Elastic) und die Autorisierung von OTEL_EXPORTER_OTLP_HEADERS.

Bei der Konfiguration des OTel Collector mit dem APM-Server-Endpoint von Elastic haben Sie zwei Optionen: gRPC und http.

In der Datei otelcollector.yaml hier wurden die Exporter mit http konfiguriert. 

Wenn Sie Daten mit dem gRPC-Port an den APM-Server senden möchten, müssen Sie die Exporter wie folgt modifizieren:

    exporters:
      otlp/elastic:
        endpoint: OTEL_EXPORTER_OTLP_ENDPOINT
        headers:
          Authorization: OTEL_EXPORTER_OTLP_HEADERS

Beachten Sie die Änderung von otlphttp in otlp. Nachdem Sie die erforderlichen Änderungen wie oben angegeben vorgenommen haben, erstellen Sie den otelcollector:

kubectl create -f otelcollector.yaml

Stellen Sie sicher, dass er betriebsbereit ist und ordnungsgemäß ausgeführt wird.

mycomputer% kubectl get pods | grep otelcollector
otelcollector-5b87f4f484-4wbwn          1/1     Running   0            18d

Schritt 4: Öffnen von Kibana und Anzeigen Ihrer mit OTel instrumentierten Dienste mithilfe der APM Service Map

Wählen Sie in der Benutzeroberfläche von Elastic Observability unter „APM“ servicemap aus, um Ihre Dienste zu sehen.

Wenn es so aussieht, sendet der OpenTelemetry Collector Daten zu Elastic:

Herzlichen Glückwunsch! Sie haben die Dienste der HipsterShop-Demoanwendung mit OpenTelemetry für Tracing instrumentiert und die Telemetriedaten erfolgreich in Elastic ingestiert.

Konfiguration spezieller Umgebungen

Bei Elastic APM können Sie mehrere Anwendungen ingestieren und nach Environment filtern. Wenn daher dev team 1 und dev team 2 beide die Benutzeroberfläche verwenden, müssen Sie die Variable environment richtig festlegen. 

Die Variable „Environment“ wird für diese Anwendung über die Variable deployment.environment in den Dienst-YAMLs festgelegt.

Wenn Sie das ändern möchten, müssen Sie die OTEL_RESOURCE_ATTRIBUTES in den einzelnen Dienst-YAMLs im Git für die Anwendung für diesen Blog ändern.

Ändern Sie:

       - name: OTEL_RESOURCE_ATTRIBUTES
          Value: "service.name=recommendationservice,service.version=1.0.0,deployment.environment=MY-DEMO"

In:

       - name: OTEL_RESOURCE_ATTRIBUTES
          Value: "service.name=recommendationservice,service.version=1.0.0,deployment.environment=XXX"

Führen Sie den folgenden Befehl aus, um diese Änderung für alle Dienste vorzunehmen:

sed -i `s/MY-DEMO/XXX/g` *.yaml

Schritt 5: Was kann mir Elastic zeigen?

Welche Möglichkeiten haben Sie jetzt, nachdem die OpenTelemetry-Daten in Elastic ingestiert wurden?

Zunächst können Sie sich die APM Service Map ansehen (wie im vorherigen Schritt gezeigt). So erhalten Sie einen umfassenden Überblick über alle Dienste und die Transaktionsflüsse zwischen den Diensten.

Als Nächstes können Sie nun die einzelnen Dienste und die erfassten Transaktionen anzeigen.

Wie Sie sehen können, werden die Frontend-Details aufgeführt: 

  • Durchschnittliche Latenz der Dienste
  • Durchsatz
  • Zentrale Transaktionen
  • Anteil fehlgeschlagener Transaktionen
  • Fehler
  • Abhängigkeiten

Gehen wir zur Trace. Auf der Registerkarte „Transaction“ (Transaktion) können Sie alle Arten von Transaktionen sehen, die mit dem Frontend-Dienst zusammenhängen:

Wenn wir „/cart/checkout transactions“ auswählen, können wir die gesamte Trace mit allen Spans anzeigen:

Durchschnittliche Latenz für diese Transaktion, Durchsatz, alle Fehler und natürlich die Trace!

Sie können sich nicht nur die Trace ansehen, sondern auch analysieren, welche Faktoren für die überdurchschnittlich hohe Latenz für „/chart/checkout“ verantwortlich sind.

Elastic nutzt Machine Learning, um mögliche Latenzprobleme bei den Diensten anhand der Trace zu erkennen. Dazu müssen Sie einfach nur die Registerkarte Latency Correlations (Latenzkorrelationen) auswählen und die Korrelation ausführen.

Dies zeigt, dass Transaktionen vom Client 10.8.0.16 möglicherweise eine auffällige Latenz für diese Transaktion aufweisen.

Sie können dann direkt von der Trace-Ansicht aus einen Drilldown in die Logs durchführen und die mit der Trace verbundenen Logs überprüfen, um potenzielle Probleme zu identifizieren und zu lokalisieren.

Analysieren Ihrer Daten mit Machine Learning (ML) von Elastic

Sobald sich die OpenTelemetry-Metriken in Elastic befinden, können Sie mit der Analyse Ihrer Daten anhand der ML-Funktionen von Elastic beginnen.

Einen ausführlichen Überblick über diese Features finden Sie hier: Korrelieren von APM-Telemetrie, um Ursachen in Transaktionen zu ermitteln.

Außerdem finden Sie unter Elastic Blogpost zahlreich Videos und Blogs.

Es folgen weitere Blogs zur Nutzung der Machine-Learning-Funktionen von Elastic für OpenTelemetry-Daten.

Fazit

Ich hoffe, Sie haben einen Eindruck davon bekommen, wie Elastic Observability Ihnen helfen kann, OpenTelemetry-Daten mit den APM-Funktionen von Elastic zu ingestieren und zu analysieren.

Eine kurze Zusammenfassung des Gelernten:

  • Wie Sie mit wenigen einfachen Schritten eine gängige OTel-instrumentierte Demoanwendung (HipsterShop) so konfigurieren, dass sie in Elastic Cloud ingestiert wird
  • Einige der APM-Funktionen und -Features von Elastic für OTel-Daten und wie Sie die Daten in Elastic nutzen können

Sind Sie bereit loszulegen? Registrieren Sie sich für Elastic Cloud und probieren Sie die oben beschriebenen Features und Funktionen aus, um Ihre OpenTelemetry-Daten optimal zu nutzen und zu verstehen.

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