Beobachtbarkeit in Elasticsearch: Integration von Prometheus und den OpenMetrics-Standards für Metriken

Von
Dan Roscigno

Themen dieses Blogposts:

  • Warum sind offene Standards wichtig?
  • Das Expositionsformat von Prometheus
  • Welche Bedeutung misst Elastic der Beobachtbarkeit bei?
  • Drei Möglichkeiten, Prometheus-Metriken in Elasticsearch zu nutzen
  • Ein Beispiel für das Erfassen und Visualisieren von Metriken, die vom Redis-Exporter von Prometheus bereitgestellt werden

Warum sind offene Standards wichtig?

Auf opensource.com steht Ihnen eine informative Ressource mit dem Titel What are Open Standards? (Was sind offene Standards?) zur Verfügung, in der viele wichtige Aspekte von offenen Standards behandelt werden. Aufgrund meiner langjährigen Erfahrung in Operations sind jedoch insbesondere folgende Aspekte für mich wichtig:

  1. Verfügbarkeit: Offene Standards sind für alle lesbar und können von allen implementiert werden.
  2. Optionsvielfalt für Endbenutzer
  3. Anbieterneutralität: Offene Standards und ihre regulierenden Organisationen bevorzugen kein spezielles Implementierungsprogramm.
  4. Transparenz: Die Standards dürfen keine für die interoperable Implementierung erforderlichen Details vorenthalten.

Dies sind überzeugende Argumente für offene Standards. Sprechen wir nun darüber, warum das Expositionsformat von Prometheus die Grundlage für OpenMetrics darstellt. In seinen Vorträgen auf der PromCon 2018 und der KubeCon + CloudNativeCon North America 2018 fasste Richard Hartmann die Gründe für die Definition eines offenen Standards auf der Grundlage des Expositionsformats von Prometheus zusammen:

  • Die meisten Datenformate sind proprietär und/oder schwierig zu implementieren.
  • Prometheus ist zum De-facto-Standard beim cloudnativen Metrikmonitoring geworden.
  • Die einfache Handhabung von Expositionsdaten hat zu einer explosionsartigen Zunahme kompatibler Metrikendpunkte geführt.
  • Das Expositionsformat von Prometheus basiert zwar auf umfangreicher operativer Erfahrung, wurde jedoch von nur einigen wenigen Entwicklern entworfen.
  • Einige andere Projekte und Anbieter sind unschlüssig, ob sie etwas von einem Konkurrenzprodukt übernehmen sollten.

Das Expositionsformat von Prometheus

Ausführliche Informationen zum Expositionsformat finden Sie im GitHub-Repository zu Prometheus. Schauen wir uns an dieser Stelle ein Beispiel an. Betrachten wir den Exporter Oliver006's Redis exporter, mit dem Metriken auf Port 9121 am Endpunkt „/metrics“ veröffentlicht werden. Im Folgenden sind nur Informationen zur Redis-Metrik „instantaneous ops per second“ (unmittelbare Operationen pro Sekunde) abgebildet. Es sind drei Zeilen sichtbar:

  1. Hilfetext
  2. Der Metriktyp (in diesem Fall „Gauge“)
  3. Der zu messende Redis-Server (localhost port 6379) und der aktuell für diesen Server gemessene Wert (9 Operationen pro Sekunde)

roscigno-prometheus-exposition-format.png

Welche Bedeutung misst Elastic der Beobachtbarkeit bei?

Ich empfehle Ihnen, die Ansichten von Elastic hinsichtlich der Beobachtbarkeit zu lesen. Dies ist meine bevorzugte Aussage aus dem Blogpost:

Bei der Gestaltung und der Erstellung beobachtbarer Systeme geht es darum, dass die verantwortlichen Personen im Produktionsbetrieb Verhaltensweisen (z. B. Dienstausfälle, Fehler, langsame Reaktionszeiten) erkennen können und aussagekräftige Informationen erhalten, um die Ursache effektiv bestimmen zu können (z. B. ausführliche Ereignis-Logs, differenzierte Informationen zur Ressourcenauslastung und Anwendungs-Traces).

Ich stimme dieser Aussage voll und ganz zu. Sie unterstreicht, dass wir all die Logs, Metriken und Tracinginformationen benötigen, um die von uns bereitgestellten Services auszuführen, zu reparieren und zu verwalten. Prometheus spielt aufgrund seiner weiten Verbreitung und seiner aktiven Community eine sehr wichtige Rolle bei der Beobachtbarkeit. Der OpenMetrics-Standard wird den Wert noch erhöhen, indem er reale oder fiktive Hindernisse bei der Einführung eines vernünftigen, auf Operationen zugeschnittenen Metrikformats aus dem Weg räumt.

Die meisten Menschen, mit denen ich rede, sind bereits sehr mit dem Elastic Stack oder ELK für das Logging vertraut. Falls Sie noch nicht wussten, dass der Elastic Stack auch hervorragend für Metriken und APM geeignet ist, lesen Sie unsere Postings zu Metriken und APM/verteiltem Tracing.

Wir haben folgende Hauptgründe für das Interesse an einer tief reichenden Integration zwischen Elastic Stack und der von Prometheus verwendeten Methode für den Export von Metriken festgestellt:

  • Kombination von Metriken mit Logs und APM in Elasticsearch und deren wechselseitige Zuordnung in Kibana (Lesen Sie eine Anwendergeschichte von NS1 über die Kombination von Logs und Metriken in Elastic Stack.)
  • Nutzung von Elasticsearch als Langzeitspeicher für vom Prometheus-Server erfasste Metriken (Dieser Server unterstützt derzeit nativ noch kein Clustering.)
  • Bereitstellung einer globalen Ansicht Ihrer Metriken über geografisch verteilte Prometheus-Instanzen hinweg

Im verbleibenden Teil dieses Blogposts wird ausführlich erläutert, wie wir diese Integrationen angehen.

Beispiel für einen Exporter

Meine Demoumgebung läuft unter Google Kubernetes Engine (GKE), daher führe ich sowohl meine Anwendung Metricbeat als auch den Prometheus-Exporter in Kubernetes aus. Hier sehen Sie einen Teil des Oliver006's Manifests zur Bereitstellung eines Redis-Exporters als ein Sidecar neben dem Redis-Image. Wie ersichtlich, veröffentlicht der Exporter auf Port 9121. Dies ist die standardmäßig zugewiesene Portnummer für den Redis-Exporter von Prometheus. 

...
  - name: redis-exporter
    image: oliver006/redis_exporter:latest
    resources:
      requests:
        cpu: 100m
        memory: 100Mi
    ports:
    - containerPort: 9121
...

Den vollständigen Quellcode finden Sie auf GitHub.

Scraping von Metriken mit dem Prometheus-Modul von Metricbeat

Metricbeat ist das Basismodul von Elastic für den Transfer von Metriken. Das zum Lieferumfang von Metricbeat gehörende Prometheus-Modul kann Metriken auf drei Arten erfassen:

  1. Herstellen einer Verbindung zum Prometheus-Server auf Port 9090 und Abrufen der von Prometheus erfassten Metriken mithilfe der Prometheus Federation API
  2. Herstellen einer Verbindung zum Prometheus-Server auf Port 9090 mithilfe des Endpunkts „/metrics“ (Eigenüberwachung von Prometheus)
  3. Herstellen von individuellen Verbindungen zu den einzelnen Prometheus-Exportern und Analysieren des Expositionsformats

Aus welchem Grund würden Sie eine dieser Methoden bevorzugen? Das hängt davon ab, wie gut Sie sich mit dem Prometheus-Server auskennen.

  • Falls Sie den Prometheus-Server bereits für das Scraping von Metriken eingerichtet haben und Sie diese Metriken zu Integrationszwecken direkt abfragen möchten, können Sie mit den Optionen (1) und (2) beginnen.
  • Falls Sie noch nicht über einen Prometheus-Server verfügen oder falls Sie bereit sind, für Ihre Exporter mit mehreren Tools parallel ein Scraping durchzuführen, könnten Sie sich für Option (3) entscheiden.

Hinweis: Ein Teil der zuvor beschriebenen Metricbeat-Funktionalität gehört zu den Betafunktionen in Metricbeat Version 7.0. Wir empfehlen Ihnen, die Version 7.0 Beta herunterzuladen oder die Container-Links von der Webseite https://www.docker.elastic.co/ zu kopieren und die Betafunktionen in einer Nicht-Produktionsumgebung auszuführen.

Die Prometheus Federation API

Im Allgemeinen wird Federation dazu verwendet, das Skalieren zu ermöglichen, Datensätze zusammenzuführen oder eine Kopie von Daten, die an einem anderen Ort verfügbar sind, zu erstellen (für die Notfallwiederherstellung). Der Prometheus-Server stellt einen Endpunkt /federation bereit und Elastic stellt eine Verbindung mit diesem Endpunkt her, um die von Prometheus erfassten Metriken aus allen zuvor dargelegten Gründen zu kopieren. 

...
  - module: prometheus
    period: 10s
    hosts: ["prometheus-service.monitoring.svc.cluster.local:9090"]
    metrics_path: '/federate'
    query:
      'match[]': '{__name__!=""}'
...

Den vollständigen Quellcode finden Sie auf GitHub.

Im vorhergehenden Beispiel ist die Abfrage so festgelegt, dass sie alles abdeckt, was keinen leeren Namen aufweist. Möglicherweise möchten Sie jedoch nicht alles aufgreifen. In der Prometheus-Dokumentation finden Sie Anleitungen, wie Sie die Übereinstimmungsbedingung (match) stärker einschränken können. Im Beispiel wird auch alle 10 Sekunden eine Verbindung zum Prometheus-Server hergestellt. Mein Demoserver erfasst Daten nur von einigen wenigen Pods und Kube-Status-Metriken, es empfiehlt sich möglicherweise jedoch, das Intervall zu ändern.

Eigenüberwachung (Self Monitoring) in Prometheus

Genau wie die Exporter bietet Prometheus einen Endpunkt /metrics. Dies ermöglicht es Ihnen, Metriken zum Prometheus-Server zu erfassen. Die Konfiguration sieht wie folgt aus: 

...
  - module: prometheus
    period: 10s
    hosts: ["prometheus-service.monitoring.svc.cluster.local:9090"]
    metrics_path: /metrics
...

Den vollständigen Quellcode finden Sie auf GitHub.

Exporter-Scraping in Prometheus

Dieser Abschnitt in YAML aus einem Manifest zur Bereitstellung eines Metricbeat DaemonSet weist Metricbeat zur automatischen Ermittlung (Autodiscovery) mit kubernetes.labels.app == redis und zum Einlesen von Metriken von Port 9121 aus diesem Pod an. Hinweis: 9121 ist der für den Container des Redis-Exporters festgelegte containerPort. 

...
- condition.equals:
    kubernetes.annotations.prometheus.io/scrape: "true"
  config:
    - module: prometheus
      period: 10s
      # Redis pods
      hosts: ["${data.host}:9121"]
      metrics_path: /metrics
...

Sobald Metricbeat bereitgestellt ist, wird das Prometheus-Modul auf alle Pods angewendet, die die Bedingung „kubernetes.labels.app == redis“ erfüllen, und die Metriken werden vom Exporter-Sidecar auf Port 9121 erfasst.

Doch sind Metadaten nicht der Antriebsfaktor für die Kubernetes-Welt? Lassen Sie uns an dieser Stelle etwas näher auf Metadaten und die Funktion „Autodiscover“ von Beats eingehen. Schauen Sie sich diesen Ersatzcode für den vorherigen Abschnitt in YAML an: 

...
- condition.equals:
    kubernetes.annotations.prometheus.io/scrape: "true"
  config:
    - module: prometheus
      period: 10s
      hosts: ["${data.host}:${data.kubernetes.annotations.prometheus.io/port}"]
      metrics_path: /metrics
...

Den vollständigen Quellcode finden Sie auf GitHub.

Statt nach Exportern für Redis-Pods Ausschau zu halten, suchen wir nach Exportern für einen beliebigen Pod, bei dem eine Anmerkung kubernetes.annotations.prometheus.io/scrape den Wert „true“ aufweist. Dies entspricht auch der Einrichtung der Prometheus-Funktion „Autodiscover“. Im Allgemeinen wird die Funktion „Autodiscover“ von Metricbeat über eine Anmerkung in dem elastic.co-Namespace gesteuert, aber da wir die Daten von Prometheus-Exportern einlesen, sollten wir die Standards für Kubernetes-Anmerkungen im Zusammenhang mit Prometheus einhalten. Betrachten Sie nun die Hostliste aus dem vorherigen Beispiel:

hosts: ["${data.host}:${data.kubernetes.annotations.prometheus.io/port}"]

Wie Sie sehen können, enthält sie keine Hartcodierung für Port 9121 mehr, da dies der Port für den Redis-Exporter ist. Für die Anmerkung prometheus.io/port ist die Portnummer des Exporters festgelegt. Aus Vollständigkeitsgründen folgt hier ein Abschnitt aus der Datei „guestbook.yaml“, in der diese Anmerkungen festgelegt sind: 

...
kind: Deployment
metadata:
  name: redis-master
spec:
  replicas: 1
  template:
    metadata:
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9121"
      labels:
        app: redis
...

Den vollständigen Quellcode finden Sie auf GitHub.

Mehr Einblick durch Visualisierung

Die Möglichkeit, Daten in den Elastic Stack zu importieren, ist hervorragend, doch Sie müssen auch mit den Daten interagieren können. Im folgenden Video wird die Vorgehensweise zum Aufbau einer zweckdienlichen Visualisierung erläutert. Hierbei werden die von Prometheus per Scraping erfassten und dann in den Elastic Stack importierten Redis-Metriken und die direkt mit Metricbeat aus den Kube-Status-Metriken erfassten Kubernetes-Ereignisse verwendet.

Sie können die im Video gezeigte Vorgehensweise im Beispiel-Repository verfolgen. Dort finden sie auch ausführliche Anleitungen.

Zurück zur Beobachtbarkeit

In diesem letzten Abschnitt haben wir eine Kibana-Visualisierung für eine wichtige Redis-Metrik („instantaneous ops per second“ [unmittelbare Operationen pro Sekunde]) erstellt, die von dem Exporter „Oliver006's Redis exporter“ bereitgestellt wird. Unser nächster Schritt würde darin bestehen, Logs zu erfassen, dann ein Dashboard zu erstellen und die Logs und Metriken über unsere Anwendungen hinweg miteinander zu kombinieren.

Anleitungen zum Erfassen von Logs in einer Kubernetes-Umgebung finden Sie im GitHub-Repository elastic/examples. In nur wenigen Minuten können Sie Daten von Filebeat, Metricbeat und Packetbeat erfassen und auf Elasticsearch veröffentlichen lassen. Es werden Beispiel-Dashboards mit den unterschiedlichen Beats bereitgestellt, doch erstellen Sie auch ruhig Ihre eigenen Visualisierungen für Prometheus-Daten und kombinieren Sie die Visualisierungen miteinander, um Ihre eigenen, an Ihre Arbeitsweise angepassten Dashboards zu erstellen. Wenn Sie hierbei Probleme haben oder über die Beobachtbarkeit reden möchten, nutzen Sie die Discuss-Foren.