Engineering

Überwachung von Kubernetes- und Docker-Containern mit Beats: Protokolleinträge, Metriken und Metadata

In diesem Blogpost geht es um das Überwachen von Containerumgebungen, wie Google Kubernetes Engine (GKE), IBM Cloud Kubernetes Service oder jede andere Kubernetes (k8s)- und Docker-Umgebung. In den Beispielen in diesem Post verwende ich den IBM Cloud Kubernetes Service.

Vielleicht fragen Sie sich, warum ich über die Überwachung von Kubernetes- und Docker-Containern schreibe. Die Verwaltung der Infrastruktur ist doch eigentlich Sache der Cloud-Anbieter und ich muss mich nur um meine App kümmern, oder? Da haben Sie sicher recht, aber ich gehöre zu denen, die sich trotz persönlicher Empfehlungen zur Sicherheit auch noch einmal die Yelp-Rezensionen ansehen – je mehr Informationen ich habe, desto besser. Ich möchte alle Protokolleinträge und Metriken zu meiner App und ihrer Umgebung, die ich kriegen kann, und ich möchte in der Lage sein, sie alle zu durchsuchen und zu visualisieren, und bei Bedarf Benachrichtigungen erhalten. Die üblichen Funktionen zur Containerüberwachung sind zwar durchaus hilfreich, aber ich werde Ihnen zeigen, wie Sie mithilfe von Kubernetes-Ereignissen und -Metadaten Ihr App-Performance-Diagramm mit Benachrichtigungen über Skalierungen oder rollierende Updates aufwerten können.

Lassen Sie mich zunächst ein paar Begriffe klären.

  • Protokolleintrag: Auch „Log“ genannt. Ein Zeitstempel und eine Nachricht. Das könnte ein typischer Protokolleintrag wie „NGINX started at 13:42“ (NGINX um 13:42 gestartet) sein oder ein k8s-Ereignis wie „There was an NGINX container with a Back-off restarting failed container at 16:20“ (Um 16:20 gab es einen NGINX-Container mit einem Container bei dem der Back-off-Neustart fehlgeschlagen ist).
  • Metrik: Numerisches Ergebnis einer Messung, erfasst für einen festen Zeitraum, wie zum Beispiel: „Sales through the eCommerce site were $50,000 over the past ten minutes“ (In den letzten 10 Minuten sind die Verkäufe über die eCommerce-Website um 50.000 $ gestiegen) oder „CPU utilization was 17% from 14:00:00 to 14:00:10“ (Von 14:00:00 bis 14:00:10 lag die CPU-Auslastung bei 17 %).

App-Deployment in einem Kubernetes-Cluster

In meinem Beispiel werde ich diese Anwendung auf der Basis von Apache HTTP Server, PHP und Redis verwenden.

k8s-module-1.png

Zusätzlich haben wir zur Überwachung der Anwendung und der Containerinfrastruktur Folgendes: 

  • ein gehostetes Elasticsearch Service-Deployment in Elastic Cloud
  • Beats, die leichten Shipper für Protokolleinträge und Metriken, bereitgestellt als DaemonSet im selben Kubernetes-Cluster – Beats können an die Stelle des üblicherweise in Kubernetes-Clustern bereitgestellten fluentd treten

Protokolleinträge und Metriken

Die oben gezeigte Anwendung ist nur ein Teil eines größeren Ökosystems, das ständig nützliche Informationen produziert, die nicht unerfasst bleiben sollten. Die erfassten Protokolleinträge und Metriken stammen aus den folgenden Quellen:

  1. Orchestrierung (Kubernetes)
  2. Hosts
  3. Anwendung
  4. Container (Docker)

k8s-module-2.png

Zur Erfassung der Daten kommen Beats (Filebeat, Metricbeat und Packetbeat), die Module System, Kubernetes und Docker sowie Module für die Anwendung (Apache und Redis) zum Einsatz. Wir haben für jeden Beat DaemonSets bereitgestellt, die wir von Kubernetes verwalten lassen. Die Liste ist zwar ganz schön lang, aber keine Angst: Die Beats-Autodiscover-Funktion sorgt dafür, dass das Ganze übersichtlich bleibt. Einzelheiten zur Bereitstellung der Beats zum Überwachen einer Anwendung finden Sie in diesem Blogpost und dem zugehörigen Video. Und wenn Sie ganz von vorn beginnen möchten, sehen Sie sich die Elastic-Seite zur Container-Überwachung an.

Zum Indexieren, Speichern, Durchsuchen, Analysieren und Visualisieren der Daten habe ich den gehosteten Elasticsearch Service verwendet. Die Bereitstellung des Elasticsearch Service in Elastic Cloud wird auf unserer „Erste Schritte“-Seite erläutert. Dort finden Sie auch Informationen zur Bereitstellung von Elasticsearch und Kibana auf einem von Ihnen selbst verwalteten System – beide Varianten sind okay.

Ich habe Beats und Module erwähnt und sie verdienen es, eingehender vorgestellt zu werden. Ein Beat ist ein leichter Agent, der Daten an Elasticsearch oder Logstash sendet. Beats werden entweder dort bereitgestellt, wo die Daten herstammen, also zum Beispiel auf einem physischen oder einem virtuellen System, oder ihre Bereitstellung erfolgt parallel zu den Quellen, beispielsweise als DaemonSet (wie ich es hier getan habe). Module vereinfachen das Erfassen, Parsen, Indexieren und Visualisieren gängiger Protokollformate.

Wenn das ein wenig langweilig klang, kann man es auch so ausdrücken: Elastic-Module bieten das ganze Erlebnis in einem vorgefertigten Paket. Nehmen wir einmal an, Sie kennen sich super mit der Verwaltung von Apache HTTPD Server aus, aber NGINX ist Neuland für Sie. Sie könnten zu jemandem gehen, der NGINX kennt, und diese Person mit Fragen bombardieren: „Worauf achtest du in den Protokollen? Welche Metriken behältst du im Blick? Kannst du mir die Greps aus deiner History-Datei geben?“ Beat-Module bieten mit vorgepackten Dashboards, gespeicherten Suchen, Parsing und Erfassung von Daten für Kubernetes, Docker, NGINX, Apache, Betriebssysteme, Datenbanken und so weiter Antworten auf all diese Fragen und damit ein nach meiner Erfahrung äußerst großen und hilfreichen Umfang an Funktionen und Fähigkeiten.

Das k8s-Modul erfasst Messdaten im Zusammenhang mit Pods, Knoten, Volumes, ReplicaSets, Deployments und so weiter. Jeder Messdatenparameter ist mit einer Vielzahl unterschiedlicher Metadaten versehen, sodass Sie die Daten in Ihre App einbinden können. Es mag Ihnen zum Beispiel egal sein, ob Pod xyz bei der Arbeitsspeichernutzung fast am Limit ist, aber wenn dieser Parameter für das Frontend Ihrer App relevant wird, wird er plötzlich zu einer wertvollen und geschäftskritischen Information. Das Modul erfasst auch Ereignisse (vielleicht erinnern Sie sich, dass ich oben in der Definition des Begriffs „Protokolleinträge“ Kubernetes-Ereignisse erwähnt habe), die wir im Video unten nutzen, um ein Performance-Diagramm mit zusätzlichen Informationen anzureichern.

Das Docker-Modul erfasst Metriken, die im Zusammenhang mit Containern, Hosts, dem Arbeitsspeicher, dem Netzwerk, Integritätsprüfungen und so weiter stehen. Wie das Kubernetes-Modul bieten die Metadaten wertvolle Informationen, die Ihnen dabei helfen, die Performance Ihrer App und der Umgebung zu analysieren.

Es gibt auch viele andere Module für Filebeat und Metricbeat. Außerdem enthält Packetbeat eine Vielzahl von Dashboards für Dienste wie Cassandra, Flows, HTTP, MySQL, MongoDB und so weiter.

Im Video unten erfahren Sie, wie einfach es ist, rohe Daten in umsetzbare Informationen zu verwandeln. Folgende Themen werden behandelt:

  • Visualisierung von Kubernetes-Ereignissen mit App-Performance-Metriken
  • Eingehende Betrachtung des Metricbeat-Kubernetes-Modul-Ereignis-Metricsets
  • Navigation durch die Kubernetes-Ereignisse und benutzerdefinierte Visualisierung