Docker und Kubernetes: hinweisbasiertes Autodiscover mit Beats

Ab Version 6.0 haben wir Beats neue Features hinzugefügt, die unsere Unterstützung für Containermonitoring verbessern. Wir haben vor Kurzem ein neues Feature eingeführt: Autodiscover in Filebeat und Metricbeat mit Unterstützung für Docker und Kubernetes Mit dem Feature „Autodiscover“ können Sie einen Satz von Konfigurationen definieren, die von Beats auf Ihren Wunsch hin dynamisch gestartet werden. Dieses Feature ist aufgrund der dynamischen Eigenschaften von Containern insbesondere zu deren Überwachung geeignet.

Die Herausforderung des Containermonitorings

In einer traditionellen Infrastruktur würden Sie normalerweise einen neuen Host einrichten, dann alle auf ihm auszuführenden Dienste konfigurieren und den Monitoring-Agent für die periodische Abfrage der Dienste konfigurieren. Konfigurationsverwaltungstools unterstützen Sie bei dieser Aufgabe, sie sind jedoch weitestgehend statisch.

In der Containerarchitektur wird alles zu einem beweglichen Ziel. Deployments sind dynamisch: sie nehmen zu, sie nehmen ab und verschwinden, Container wechseln von einem Knoten zum anderen. Es gibt keine feste IP-Adresse, von der Ihre Kenndaten abgerufen werden können.

Wir benötigen spezielle Tools für die Nachverfolgung.

Autodiscover

Schauen wir uns die Funktionsweise einmal genauer an. Dies ist eine Beispielkonfiguration:

metricbeat.autodiscover:
  providers:
   - type: docker
     templates:
       - condition.contains:
           docker.container.image: etcd
         config:
          - module: etcd
            metricsets: ["leader", "self", "store"]
            hosts: "${data.host}:2379"

output.elasticsearch:
  hosts: ["localhost:9200"]

Hier wird Metricbeat für die Verwendung des Docker Autodiscover-Anbieters konfiguriert. Sie können eine Liste von Vorlagen definieren, die an die Bedingung gebunden sind, von der sie ausgelöst werden sollten. In diesem Fall entspricht die Bedingung dem Containerimage, das etcd enthält (wir verwenden „contains“, da im Feld „Image“ Name:Tag-Paare gespeichert werden). Wenn ein etcd-Container erstellt wird, wird das etcd-Modul von Metricbeat gestartet, um diesen Container zu überwachen, wobei die Variable ${data.host} durch die IP-Adresse des Containers ersetzt wird.

Schauen wir uns die Funktionsweise einmal im Detail an:

1. Autodiscover-Ereignisse

Beats Autodiscover unterstützt mehrere Anbieter. Von diesen Anbietern sind derzeit Kubernetes und Docker verfügbar. Anbieter implementieren eine Möglichkeit, eine bestimmte Plattform auf Ereignisse hin zu überwachen. Sobald ein Ereignis eintritt, wird vom Anbieter ein Autodiscover-Ereignis ausgelöst, das alle von Ihnen zur Reaktion auf das Ereignis benötigten Informationen enthält.

2. Abgleich mit den Bedingungen

Jedes Ereignis wird mit einer Liste von Bedingungen abgeglichen, wobei das verwendete Konfigurationsformat mit dem von den Prozessoren verwendeten Format übereinstimmt. Falls eine der Bedingungen mit dem Ereignis übereinstimmt, wird der angegebene Satz von Konfigurationen für das Ereignis erstellt.

3. Var Expansion

Konfigurationsvorlagen können Variablen enthalten, die durch tatsächliche Werte aus dem die Bedingung auslösenden Ereignis ersetzt werden. Mithilfe dieses Mechanismus ist es möglich, dynamische Konfigurationen zu definieren, die vom Status eines Containers abhängen können, wie beispielsweise die IP-Adresse. Durch Verwendung von Bezeichnungen und Anmerkungen sind jedoch auch komplexere Konfigurationen möglich.

4. Start/Stopp der Konfiguration

Sobald die endgültige Konfiguration erstellt ist, wird diese vom Autodiscover-Vorgang gestartet. Zu den gültigen Konfigurationen gehören Module in Metricbeat und Filebeat sowie Eingaben in Filebeat.

Es gibt sowohl Start- als auch Stoppereignisse, daher wird eine von Autodiscover gestartete Konfiguration automatisch gestoppt, sobald der Container nicht mehr vorhanden ist. Hierzu ist keine spezielle Konfiguration erforderlich.

Ein praktisches zusätzliches Feature bei der Verwendung von Autodiscover besteht darin, dass alle mit Autodiscover gefundenen Ereignisse automatisch mit Metadaten von Docker oder Kubernetes ergänzt werden. Die Verwendung von adddockermetadata- oder addkubernetesmetadata-Prozessoren ist daher nicht erforderlich. Diese Metadaten sind bei der Navigation in Logs und Kenndaten nützlich. Sie ermöglichen es, Logs und Kenndaten zu filtern und sich auf die wesentlichen Dinge zu konzentrieren.

Einführung von Hinweisen

Ab Release 6.3 können Sie nun Hinweise verwenden, um das Monitoring Ihrer Container zu definieren. Bisher musste die Beats-Einstellungsdatei zur Konfiguration des Monitorings einer neu bereitgestellten Anwendung aktualisiert werden.

Beim hinweisbasierten Autodiscover wird die Steuerung der Monitoringeinstellungen umgekehrt. Statt an einer zentralen Stelle können sie direkt neben dem Anwendungscontainer gespeichert werden. So erhält das Team, das eine Anwendung erstellt und bereitstellt, die Möglichkeit, Verantwortung für die Gestaltung des Monitorings der Anwendung zu übernehmen.

Diese Konfiguration ermöglicht hinweisbasiertes Autodiscover für Kubernetes-Containerlogs (diese Änderung kann beispielsweise in Verweis auf Kubernetes Manifest für Filebeat erfolgen):

filebeat.autodiscover:
  providers:
    - type: kubernetes
      hints.enabled: true

Sie können Kubernetes Pod-Anmerkungen oder Docker-Bezeichnungen verwenden, um Filebeat und Metricbeat darüber zu informieren, wie Ihre Containerlogs behandelt werden sollen. Wird beispielsweise eine Java-Anwendung in einem Pod ausgeführt, können dieser die folgenden Anmerkungen hinzugefügt werden:

annotations:
  co.elastic.logs/multiline.pattern: '^\['
  co.elastic.logs/multiline.negate: 'true'
  co.elastic.logs/multiline.match: after

Wenn der Pod gestartet wird, verarbeitet Filebeat die Anmerkungen und beginnt damit, die dazugehörigen Logs mit einem vorgegebenen Mehrzeilenmuster zu lesen, wobei die Java-Stacktraces nach Möglichkeit zusammengehalten werden. Die Dokumentation enthält eine umfassende Liste der verfügbaren Hinweise.

Es können auch Module zur Verarbeitung der Logs in strukturierte Daten verwendet werden. Wenn Sie beispielsweise einen NGINX-Server ausführen, fügen Sie einfach diese Anmerkungen hinzu, dann werden alle Logs so verarbeitet, dass Sie Einblicke über Ihre Besuche erhalten:

annotations:
  co.elastic.logs/module: nginx
  co.elastic.logs/fileset.stdout: access
  co.elastic.logs/fileset.stderr: error

Wie ersichtlich, ist jeder Datenstrom der Logausgabe einer anderen Dateigruppe zugeordnet. Sie können auch alle Datenströme einer einzelnen Dateigruppe zuordnen, indem Sie „co.elastic.logs/fileset“ definieren.

Hinweise sind auch bei der Verwendung von Metricbeat nützlich. So würde die gleiche NGINX-Instanz konfiguriert, damit Kenndaten von Metricbeat aus ihr abgerufen werden. Wie ersichtlich, ist auch hier eine variable Erweiterung verfügbar. ${data.host} wird verwendet, um die IP-Adresse des Containers zu übernehmen.

annotations:
  co.elastic.metrics/module: nginx
  co.elastic.metrics/metricsets: stubstatus
  co.elastic.metrics/hosts: '${data.host}:80'
  co.elastic.metrics/period: 10s

Werden sowohl Filebeat als auch Metricbeat ausgeführt, können beide Sätze von Hinweisen gemeinsam verwendet werden.

Fazit

Beim hinweisbasierten Autodiscover wird die Konfiguration Ihrer Monitoringeinstellungen neben die zu überwachenden Anwendungen verschoben. So gelangen die richtigen Tools zu den Teams, die sie benötigen, – insbesondere in mehrinstanzfähigen Szenarien. Zudem steht eine Reihe einfacher Anleitungen zur Verfügung, mit denen die Bedienung der Benutzeroberfläche klar und einfach verständlich wird.

Dies ist nur ein Überblick über die Möglichkeiten, die Autodiscover bietet. Wir freuen uns auf Ihr Feedback und würden gerne mehr darüber erfahren, wie Sie Autodiscover verwenden! Besuchen Sie unser Beats-Forum und berichten Sie uns über Ihre Erfahrungen.