Selbst wenn euer Team viel Erfahrung mit Logs in konventionellen Anwendungsumgebungen hat, kommt vermutlich noch eine Menge Neues auf euch zu, wenn es um Logs in Kubernetes-Umgebungen geht.
Schließlich ist Kubernetes eine ziemlich einzigartige Plattform. Sie hat viel mehr bewegliche Teile – und damit auch Logs – als herkömmliche Anwendungsumgebungen. Diese Logs zu finden, zu analysieren und daraus eine Observability zu schaffen, die verwertbare Erkenntnisse liefert, ist sogar noch deutlich komplexer als das Logging bei anderen Formen verteilter Systeme und Computing-Umgebungen.
Kubernetes-Logging ist kein Hexenwerk. Aber ihr müsst euren Logging-Ansatz weiterentwickeln, wenn es klappen soll. Hier ist ein Umdenken gefordert, und zwar sowohl bei der Erfassung und der Analyse von Logs als auch hinsichtlich der Rolle, die das Logging in eurer allgemeinen Observability-Strategie spielt.
Dieser Beitrag soll eine Orientierungshilfe bieten. Er deckt das Kubernetes-Logging in seinen Grundlagen ab. Es wird erklärt, warum die Erfassung von Kubernetes-Logs so knifflig ist und warum es schwierig ist, verwertbare Erkenntnisse aus all den unterschiedlichen Typen von Logs zu ziehen, die in einer Kubernetes-Umgebung erzeugt werden. Wir erläutern auch, was ihr tun könnt, damit ihr nicht im Sumpf der Kubernetes-Logs versinkt. Ihr könnt euch nämlich das Log-Management in Kubernetes-Umgebungen leichter machen, ohne dabei die Einblicke zu verlieren, die Kubernetes-Logs in die komplexen, Cloud-nativen Umgebungen dieser Plattform ermöglichen.
Kubernetes-Logging: die Grundlagen
Auf den ersten Blick scheinen sich Kubernetes-Logs nicht groß von anderen Log-Typen zu unterscheiden. Allerdings funktionieren sie in einigen wesentlichen Aspekten anders.
Log-Typen
Zunächst einmal gibt es in Kubernetes zwei grundlegend verschiedene Log-Typen. Container und Pods, in denen Anwendungen bereitgestellt werden, erzeugen den einen Typ. Diese Logs können euch helfen, die Performance und Zuverlässigkeit einzelner Anwendungen zu bewerten. Kubernetes selbst erzeugt den zweiten Typ. Er gewährt Einblick in den Zustand des Gesamtclusters.
Beide Kategorien umfassen wiederum viele weitere Log-Typen. Eine einzelne Anwendung erzeugt in der Regel mehrere Logs: ein Log für jede Microservice-Instanz, die als Teil der Anwendung ausgeführt wird. Auch die Logs auf Cluster-Ebene lassen sich in mehrere Kategorien unterteilen. Es gibt eigene Logs für den Master-Knoten, die Arbeitsknoten, die Kubernetes-API-Server und verschiedene weitere Kubernetes-Komponenten.
Log-Speicherorte
Da es in Kubernetes zahlreiche Log-Typen gibt, ist es kaum verwunderlich, dass diese Logs an unterschiedlichen Orten zu finden sind. Einige davon, zum Beispiel die Knoten-Logs, sind auf den jeweiligen Servern, die einen Kubernetes-Cluster bilden, unter /var/log gespeichert und dürften der IT-Technik vertraut sein. Bei anderen, etwa den Logs, die innerhalb von Containern gespeichert sind, kann die Erfassung sich komplizierter gestalten, wenn euch der Umgang mit solchen Log-Daten nicht vertraut ist.
Events und Metriken
Der Fokus dieses Beitrags liegt zwar auf Kubernetes-Logs, allerdings sind Logs nur eine von mehreren Quellen, die in Kubernetes für Transparenz sorgen können. Kubernetes bietet darüber hinaus eine Metrik-API, über die Daten zum Cluster-Zustand und zum Ressourcenverbrauch erfasst werden können. Sie zeichnet auch bestimmte Event-Typen auf, zum Beispiel das Beenden von Pods. Diese Informationen sind nicht alle in Kubernetes-Logs verfügbar, ihr solltet sie jedoch zusammen mit den Log-Daten erfassen und analysieren, wenn ihr End-to-End-Transparenz in Kubernetes-Umgebungen schaffen wollt.
Kubernetes-Logging: die Herausforderungen
Die soeben beschriebene Logging-Architektur von Kubernetes ist nicht sonderlich kompliziert. Dennoch wird das Logging in Kubernetes zu einer echten Herausforderung, weil es sich schwierig gestaltet, die unterschiedlichen Logs in euren Anwendungen und Clustern zu erfassen und zu analysieren.
Kein zentraler Log-Speicherort
Eine grundlegende Herausforderung liegt darin, dass die Kubernetes-Logs sich auf viele unterschiedliche Speicherorte verteilen. Sämtliche Log-Daten eures Clusters abzurufen, indem ihr eine einzelne Log-Datei verfolgt oder einen einzigen Befehl ausführt, ist schlicht nicht möglich.
Wenn ihr die Logs stattdessen manuell erfassen wollt, müsst ihr zwischen einer Vielzahl von Speicherorten hin- und herwechseln, die sich auf all eure einzelnen Knoten, die einzelnen Pods etc. verteilen. Befehle wie journalctl können diesen Prozess etwas vereinfachen, aber wirklich leicht wird es damit noch lange nicht.
Kein integriertes Log-Management
Noch komplexer wird die Log-Erfassung dadurch, dass Kubernetes selbst kein natives Framework zum Log-Management bietet. Kubernetes erzeugt lediglich Logs. Es bleibt den IT-Teams überlassen, herauszufinden, wie sie damit am besten umgehen.
Zwar löscht Kubernetes beispielsweise Log-Daten aus Containern, sobald die Größe der Logs 10 MB überschreitet, aber das ist eher hinderlich als hilfreich. Denn das bedeutet: Wenn diese Logs für Analysen verfügbar bleiben sollen, dann müsst ihr die Daten anderswo aggregieren, bevor Kubernetes sie überschreibt.
Unterschiedliche, veränderliche Log-Formate
Logs aus Kubernetes-Clustern und Anwendungen weisen viele unterschiedliche Formate auf. In den meisten Clustern gibt es derzeit keine Standardstruktur oder -methode.
Kubernetes-Entwicklerinnen und -Entwickler haben sich des Problems mittlerweile angenommen und haben das Logging auf Cluster-Ebene per JSON-Formatierung standardisiert. Dies ist jedoch ein neues Feature, das erst ab Kubernetes 1.19 verfügbar ist. Außerdem betrifft es nur Cluster-Logs. Eure Anwendungslogs kommen noch immer in einer Vielzahl von Formaten daher.
Stand der Dinge auf dieser Baustelle ist also, dass die Kubernetes-Entwicklung zwar einiges unternommen hat, um Logs konsistenter zu gestalten, dass aber der Mangel an einer gemeinsamen Struktur und Formatierung nach wie vor eine Herausforderung ist. Allein die Tatsache, dass Kubernetes-Logging-Standards sich immer wieder ändern, erschwert die Entwicklung von Log-Management-Strategien. Ob eine Logging-Methode, die ihr für eine bestimmte Kubernetes-Version anwendet, bei einem späteren Release ebenso gut funktionieren würde, ist schwer zu sagen.
Keine persistente Log-Speicherung
Kubernetes bietet standardmäßig keine persistente Log-Speicherung für Anwendungslogs. Stattdessen schreiben Pods und Container ihre Logs in ihre internen Umgebungen. Diese Logs verschwinden endgültig, wenn die Pods oder Container heruntergefahren werden.
Folglich müssen die Log-Daten der Anwendungen an einem externen, persistenten Speicherort aggregiert werden, damit sie weiterhin für Analysen verfügbar bleiben. Hierfür gibt es mehrere Verfahren, beispielsweise die Speicherung der Logs mithilfe sogenannter Sidecar-Container oder das direkte Streamen an einen externen Speicherort anstelle des lokalen Loggings in euren Containern. Allerdings: Eure Kubernetes-Architektur und die Management-Workflows werden dadurch noch komplexer.
Ein besserer Logging-Ansatz für Kubernetes
Bis hierher lässt sich sagen, dass Kubernetes-Logging eine ziemliche Tortur ist – zumindest wenn ihr versucht, die Logs von Hand zu verwalten.
Daher gehen clevere Teams anders vor. Statt jedes einzelne Log mühsam aus dem jeweiligen Pod oder Cluster zu erfassen, was bei größerer Skalierung eine extrem nervige Aufgabe ist, könnt ihr einfach ein Tool einrichten, das die Logs automatisch für euch erfasst – und zwar unabhängig vom Format und vom Speicherort in der Kubernetes-Umgebung.
Ebenso wichtig ist es, dass ihr zur Log-Analyse eine Lösung nutzt, die eure Log-Daten mit anderen Kubernetes-Observability-Quellen kombiniert, namentlich mit Metriken und Traces. Erst dann bekommt ihr vollständig kontextualisierte Daten zum Zustand eures Clusters und der darin ausgeführten Anwendungen.
Wenn ihr die Erfassung und Analyse von Kubernetes-Logs derart automatisiert, umgeht ihr leichtfüßig die Fallstricke der Log-Komplexität in diesen Umgebungen. Statt mühsam zu ermitteln, wo die einzelnen Logs gespeichert sind und wie ihr sie erfasst, bevor sie gelöscht werden, könnt ihr euch darauf konzentrieren, aus diesen Logs verwertbare Erkenntnisse zu gewinnen.
Eine solche Lösung steht mit Splunk Log Observer zur Verfügung. Splunk Log Observer erfasst automatisch Logs jeder Art von allen Komponenten eurer Kubernetes-Umgebung. Eine manuelle Aggregierung wird damit überflüssig. Durch die Integration in Splunk Infrastructure Monitoring und Kubernetes Navigator ermöglicht Splunk Log Observer außerdem die Analyse von Kubernetes-Log-Daten im Kontext mit anderen wichtigen Quellen der Kubernetes-Transparenz und schafft auf diese Weise vollständige Observability.
Das Log-Management in Kubernetes kann zwar einiges Kopfzerbrechen bereiten, sollte euch aber nicht davon abhalten, in euren Kubernetes-Clustern für umfassende Observability zu sorgen. Überlasst die mühselige Arbeit der Log-Erfassung und -Korrelation einfach Splunk. Ihr konzentriert euch stattdessen auf die Log-Analyse und nutzt eure Erkenntnisse dazu, die Performance eurer Kubernetes-Umgebung zu optimieren.
Log Observer ist integraler Bestandteil von Splunk Observability Cloud. Damit bekommen SREs, DevOps-Fachleute und Dev-Teams jetzt leistungsstarkes Splunk-Logging mit nahtlosen, optimierten Workflows für IT-Monitoring, Troubleshooting und Untersuchungen. Dann ist es nur mehr ein Katzensprung von der Problemerkennung zur Problemlösung. Wie sich das Troubleshooting auf einer Logging-Oberfläche anfühlt, die all eure Metrik-, Trace- und Log-Daten zentral zusammenfasst, könnt ihr in der Demo zu Splunk Observability Cloud selbst erleben.
Was ist Splunk?
Dieser Blog-Post ist der ganz persönliche Beitrag von Splunker Stephen Watts und spiegelt nicht unbedingt die Positionen, Strategien oder Ansichten von Splunk wider. Er ist eine Neufassung eines ursprünglich von Bill Emmett verfassten Beitrags.
*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier.
