© Sandor Jackal, Fotolia

Grafana schickt Loki als Konkurrenten zur Kombination aus Elasticsearch, Logstash und Kibana für Kubernetes-Umgebungen ins Rennen – und das junge Tool schlägt sich sehr gut. Grund genug, es im Detail vorzustellen.

ELK – dieses Kürzel weckt bei vielen Systemadministratoren eher schlimme Assoziationen. Gemeint ist die Kombination aus Elasticsearch, Logstash und Kibana. Sie kommt in vielen Setups weltweit zum Einsatz, um Log-Dateien an zentraler Stelle zu sammeln, zu indizieren und durchsuchbar zu machen. Dabei erweisen sich ELK und seine Abwandlungen aber als komplexes Biest, was auch und vor allem historische Gründe hat.

Den Bedarf für eine zentrale Sammelstelle für die Log-Dateien eines Setups gibt es noch gar nicht so lange, wie man meinen möchte. Wirklich durchgesetzt hat sich dieses Konzept erst im Fahrwasser der Cloud. Kein Wunder: In den konventionellen Setups der Vergangenheit hatten Admins es mit weniger Knoten pro Setup zu tun als heute, und obendrein kamen damals in der Regel deutlich weniger verschiedene Techniken und Protokolle zum Einsatz. Das machte es im Falle eines Falles leichter, Fehler zu finden. Wer ein Problem im Kontext von zwei Knoten einer 30-Knoten-Installation lokalisieren muss, der loggt sich per SSH auf beiden Systemen ein, durchstöbert die relevanten Logfiles und weiß anschließend in der Regel Bescheid.

Clouds funktionieren anders. Hier geht es meist nicht um ein paar Dutzend Server, sondern um Hunderte und Tausende. Technologien wie Software Defined Networking und Software Defined Storage haben die Anzahl der genutzten Protokolle und Produkte förmlich explodieren lassen, und Cloud-Lösungen wie OpenStack tragen ihr Scherflein zum Chaos bei. Klappt die Kommunikation zwischen zwei VMs in OpenStack nicht, muss der Admin zunächst herausfinden, wo sie überhaupt laufen. Dann muss er auf den entsprechenden Systemen die unterschiedlichen Protokollebenen debuggen, ehe er irgendwann zu einer Erklärung für das beobachtete Verhalten kommt. Im schlechtesten Fall spielen auch noch Netzwerkknoten eine Rolle, die es separat zu überprüfen gilt. Langer Rede kurzer Sinn: Wer in einer solchen Umgebung Fehler suchen soll, kann die dafür benötigten Log-Dateien nicht manuell einzeln zusammentragen.

Branchenprimus ELK

Das Gespann aus Elasticsearch, Logstash und Kibana genießt aus eben diesem Grund sein heutiges Ansehen. Die Kombination ermöglichte es erstmals, Logs von den betroffenen Systemen permanent einzusammeln, zentral zu speichern, zu indizieren und so durchsuchbar zu machen. Gerade im Falle von ELK paart sich die gewünschte Funktionalität allerdings auch mit einiger Komplexität: ELK ans Laufen zu bekommen, ist keine Kleinigkeit, und läuft es schließlich, erweisen sich Betrieb und Pflege als komplex. Obendrein verschlingt ein ausgewachsener ELK-Cluster oft enorme Ressourcen, weil das Parsen und Ablegen der Log-Dateien von Tausenden Servern kein Pappenstiel ist.

Hinzu kommt, dass ELK eigentlich nicht für die Cloud gemacht wurde. Wer es gewohnt ist, in Container-Umgebungen wie Kubernetes mit Mikroarchitekturanwendungen zu arbeiten, der empfindet bei der Installation von ELK den sprichwörtlichen “blast from the past”, sieht er sich doch einem riesigen Monolithen gegenüber. So gern Admins auch und gerade in Clouds zentralisiertes Logging mögen: Für jede Kubernetes-Instanz einen eigenen ELK-Stack zu betreiben, brächte den Admin früher oder später um den Verstand.

Mangel an Alternativen

Unerfreulicherweise gibt es zu ELK nicht viele Alternativen. Beim gern genannten Kandidat Splunk steigert alleine der Blick in die Preisliste den Blutdruck. Daher finden sich seit vielen Jahren Admins mit dem sauren Apfel ELK ab und sehen sich zum Betrieb eines Setups gezwungen, dessen sie sich am liebsten sofort wieder entledigen würden, wenn sie denn könnten. Nun gibt es endlich Hoffnung: Die Grafana-Entwickler schicken Loki [1] als schlanke Lösung für zentrales Logging in die Schlacht (Abbildung 1). Es richtet sich vorrangig an Kubernetes-Nutzer, die bereits Prometheus [2] einsetzen.

Abbildung 1: Loki funktioniert wie Prometheus für Log-Einträge und richtet sich primär an Kubernetes-Nutzer. Quelle: Loki

Loki behauptet von sich, viel Overhead zu vermeiden, der bei ELK fest dazugehört. In Sachen Funktionsumfang kann das Produkt aktuell zwar nicht mit ELK mithalten, aber viele Features, die ELK aufblähen, brauchen die meisten Admins gar nicht. Die Möglichkeit, Features gegen verminderten Funktionsumfang einzutauschen, bietet ELK aber nicht. Mit Loki von Grafana öffnet sich eben diese Tür. Im Folgenden geht der Artikel im Detail auf Loki und seinen Werdegang ein und beschreibt, welche Funktionen zur Verfügung stehen und welche fehlen.

Prometheus unter der Haube

Verfolgt man Loki zurück zu seinen Wurzeln, stößt man auf manches sehr interessante Detail. So handelt es sich bei Loki nicht um eine vollständige Neuentwicklung, die Grafana-Entwickler haben sich stattdessen an Prometheus (Abbildung 2) orientiert. Allerdings nicht direkt: Pate für Loki stand ein Fork von Prometheus namens Cortex [3], der das ursprüngliche Prometheus um die so oft vermisste horizontale Skalierbarkeit erweitert.

Abbildung 2: Das Gespann aus Prometheus und Grafana gehört mittlerweile zu den Standardlösungen für Monitoring, Alerting und Trending. Quelle: Grafana

Für Prometheus selbst gibt es ja bekanntlich bis heute keine Scale-Out-Story: Stattdessen raten die Prometheus-Entwickler dazu, viele Instanzen parallel zu betreiben und die zu überwachenden Systeme per Sharding darauf aufzuteilen. Das Verschicken der eingehenden Metrikdaten an mehrere Prometheus-Instanzen soll in einem solchen Setup für Redundanz sorgen. Das funktioniert zwar im Wesentlichen, ist aus administrativer Sicht allerdings äußerst unkomfortabel: Das Konstrukt zwingt den Admin dazu, in einer Instanz des Grafikzeichners Grafana verschiedene Prometheus-Instanzen zu bündeln, und das klappt nur zum Teil befriedigend.

Cortex räumt mit dieser Designbeschränkung von Prometheus auf, hat bisher allerdings noch nicht die Verbreitung und Bekanntheit seines Vorfahren erlangt. Bekannt genug für die Grafana-Entwickler ist es aber offenbar gewesen, denn auf ihrer Suche nach einem passenden Werkzeug für ihr Projekt verwendeten sie Cortex als Ausgangspunkt. Das erklärt auch den Slogan, mit dem die Loki-Entwickler ihr Produkt bewerben: Loki ist demnach wie “Prometheus, aber für Logs”.

Wohlgemerkt: Unter der Bezeichnung Prometheus verstehen Administratoren in der Regel ein Gespann aus mehreren Diensten – neben mindestens einer Instanz von Prometheus selbst auch eine des Alertmanagers sowie je eine Instanz eines Prometheus Node Exporters auf den zu überwachenden Systemen. Cortex ersetzt die Prometheus-Komponente, also den eigentlichen Datenspeicher. Alertmanager und Node Exporter lassen sich mit Cortex wie mit Prometheus nutzen, da Cortex zu Prometheus API-kompatibel ist. Im Backend bietet es aber viel mehr Optionen: So lassen sich mit Cortex Daten etwa auch in Cassandra oder Amazon S3 ablegen, während Prometheus lediglich das lokale Speichern erlaubt.

Log-Einträge als Metrik-Daten

Sowohl bei Prometheus als auch bei seinem Abkömmling Cortex handelt es sich um Werkzeuge für Monitoring, Alerting und Trending (MAT). Mit den bekannten Monitoring-Werkzeugen wie Icinga 2 oder Nagios lassen sie sich allerdings nicht vergleichen: Die konzentrieren sich vorrangig auf Event-basiertes Monitoring. MAT-Systeme sind hingegen darauf ausgelegt, von den zu überwachenden Rechnern so viele Performance-Metrikwerte wie nur möglich zu sammeln.

Daraus lässt sich die anliegende Last ablesen und die in Zukunft auftretende abschätzen; das Monitoring fällt quasi als Abfallprodukt an. Wenn man weiß, wie viele Instanzen des »httpd«-Prozesses auf einem System laufen, lässt sich mittels einer geeigneten Komponente Alarm schlagen, sobald ein Schwellenwert unterschritten wird. Der radikal revolutionäre Ansatz von Loki besteht nun darin, dass es die Log-Daten der Zielsysteme exakt so behandelt, als wären es ganz reguläre Metrikdaten.

Hat ein Admin ein vollständiges Prometheus für eine Umgebung bereits aufgesetzt, wird er zwischenzeitlich auch den Labels begegnet sein. Die sind in Prometheus nützlich, um bestimmte Metriken voneinander zu unterscheiden. Meistens setzen Admins Label im Hinblick auf bestimmte Werte ein: Eine Metrik »http_return_codes« könnte etwa ein Label »value« haben, das dann »200«, »403«, »404« und so weiter als Marker akzeptiert. Letztlich helfen Labels dem Admin also dabei, die Summe sämtlicher Metriken einigermaßen übersichtlich zu halten. Im oben genannten Fall bräuchte man ohne Label mindestens drei eigene Metriken, die auch separat erhoben und gespeichert werden müssten, was mit deutlich mehr Overhead beim Speichern und Verarbeiten einherginge.

Anders als ELK

An ebene jene Labels hängt Loki sich an und nutzt sie zur Indexierung der eingehenden Log-Meldungen, was den faktisch größten architektonischen Unterschied zu ELK markiert. Aus eben diesem Grund ist Loki viel effizienter und leichtfüßiger unterwegs: Es wertet die eingehenden Log-Meldungen nicht penibel aus und speichert sie auf Basis festgelegter Regeln und Schlüsselwörter, sondern vielmehr anhand der Labels, mit denen sie versehen sind.

Was in der Theorie kompliziert klingt, gestaltet sich in der Praxis simpel und nachvollziehbar. Angenommen etwa, in einer Kubernetes-Umgebung läuft eine Instanz des Cluster-Konsens-Managers Consul, die Log-Meldungen produziert. Der Admin wird, wenn er auf Prometheus für Monitoring setzt, Consul auf den Hosts mit diesem Tool überwachen.

Eine Metrik, die Prometheus dabei für Consul erhebt, ist »consul_service_health_status«. Dafür wiederum könnte der Admin, wenn er denn eine Dev-Instanz und eine Prod-Instanz seiner Umgebung betreibt, ein Label »Env« definieren, das die Werte »dev« oder »prod« haben kann. In einem an Prometheus angekoppelten Grafana ließen sich anschließend auf Basis der Labels unterschiedliche Graphen zeichnen. Mit Loki verhält es sich ganz ähnlich: Loki würde die gespeicherten Log-Einträge anhand der Labels aufteilen, sodass man gezielt Log-Einträge für »prod« und »dev« in Grafana zeigen könnte.

Das ist freilich nicht so komfortabel wie die von ELK gewohnte Volltextsuche, frisst dafür aber auch deutlich weniger Ressourcen. Und weil Prometheus und sein Fork Cortex sich gut dynamisch konfigurieren lassen, eignet Loki sich viel eher für den Betrieb in Containern.

Loki in der Praxis

Wie lässt sich Loki praktisch nutzen? Welche Komponenten werden benötigt, um etwa die Log-Meldungen von den Systemen in Loki zu übernehmen? Welche Tuning-Möglichkeiten gibt es, und wie lassen sich die Synergieeffekte mit Prometheus perfekt nutzen?

Grundsätzlich gilt: Loki lässt sich problemlos virtualisieren – das war sogar eine der Kernanforderungen der Entwickler. Weil Loki dabei weniger Ressourcen voraussetzt als etwa ELK, braucht es keine Monster-Hardware, die sonst auch als Heizkraftwerk zum Einsatz kommen könnte. Wie bei Prometheus handelt es sich auch bei Loki um eine Go-Applikation, die der Admin von Github [3] bezieht. Allerdings ist es gar nicht nötig, Loki als Go-Binary auszurollen und zu starten: In bester Cloud-Manier bieten die Loki-Entwickler auf Dockerhub vorgefertigte Docker-Images der Lösung an, die sich lokal sofort verwenden lassen. Von außen gibt der Admin dem Container dann nur noch die Konfigurationsdatei mit auf den Weg.

Unter der Haube

Was von außen so leicht aussieht, erfordert unter der Haube ein Zusammenspiel von mehreren Komponenten. Ganz im Stile einer Cloud-Native-Applikation setzt sich Loki aus mehreren Komponenten zusammen; erst deren Zusammenspiel führt zum Erfolg. Die Architektur, die Loki zugrunde liegt, ist jedoch gar nicht so Loki-spezifisch: Sie recycelt einfach weite Teile der schon für Cortex geleisteten Entwicklungsarbeit (Abbildung 3). Weil Cortex gut funktioniert, spricht auch nichts dagegen.

Abbildung 3: Große Teile seines Designs erbt Loki von Cortex, das sich als eine Art besser skalierbares Prometheus versteht. Quelle: Grafana

Eingehende Log-Daten landen bei Loki beim Distributor, wobei von diesem Dienst meist mehrere Instanzen laufen. Geht man von großen Systemen aus, kann die Anzahl der eingehenden Log-Meldungen je nach Art der laufenden Dienste in der Cloud schnell bei vielen Millionen liegen – eine einzelne Distributor-Instanz wäre da kaum ausreichend. Aber es wäre auch kritisch, diese eingehenden Log-Meldungen ungefiltert und unverarbeitet in eine Datenbank zu kippen: Die würde, sofern sie den Ansturm überhaupt überlebt, zwangsläufig zum Flaschenhals im Logging-Setup.

Die laufenden Instanzen des Distributors kategorisieren die eingehenden Daten deshalb anhand der angewandten Labels zu Streams und leiten diese an die Ingester weiter, die für die Verarbeitung der Daten verantwortlich zeichnen. Verarbeitung bedeutet ganz konkret, aus den eingehenden Log-Meldungen Log-Pakete (Chunks) zu bauen, die sich per Gzip komprimieren lassen. Die Ingester laufen, ebenso wie die Distributoren, auch mit mehreren Instanzen gleichzeitig. Untereinander bilden sie eine Ringarchitektur, und ein Distributor rechnet über einen konsistenten Hash-Algorithmus aus, welche der Ingester-Instanzen gerade für ein bestimmtes Label zuständig ist.

Hat ein Ingester einen Chunk eines Logs fertiggestellt, folgt der finale Schritt auf dem Weg zum zentralen Logging: das Ablegen der Informationen im Speicher, an den Loki angeschlossen ist. Wie bereits erwähnt, unterscheidet sich Loki hier erheblich vom Vorgänger Prometheus: Bei Letzterem und dessen Metriken ist ja gerade die Tatsache ein Kernaspekt, dass es sich um eine Zeitreihendatenbank handelt.

Loki hingegen hantiert nicht mit Metrikwerten, sondern mit Text, und greift deshalb auf andere Arten des Datenspeicherns zurück. Es speichert die Chunks und die Information darüber, wo sie liegen, separat voneinander. Der Index verzeichnet alle bekannten Chunks aus Log-Daten; die Datenpakete selbst liegen aber letztlich auf eben jenem Storage, den der Admin für Loki konfiguriert hat.

Interessant an der Loki-Architektur ist, dass sie den Schreib- und den Lesepfad beinahe vollständig voneinander trennt. Möchte der Admin etwa über Grafana Logs aus Loki auslesen, kommt dafür in Loki ein dritter Dienst zum Einsatz: der Querier. Er greift im Hintergrund auf den Index sowie auf die gespeicherten Chunks zu. Kurz kommuniziert er auch mit den Ingestern, um solche Log-Einträge zu finden, die von den Ingestern noch nicht auf den Storage verschoben worden sind. Ansonsten funktionieren Lese- und Schreibvorgänge aber komplett unabhängig voneinander.

Funktionierende Skalierung

Betrachtet man sich nach diesen Erläuterungen das Gesamtkonstrukt Loki, wird klar: Das Design der Lösung passt hervorragend zu den Anforderungen, vor denen die Entwickler standen. Skalierbar sollte die Lösung ausfallen, kostengünstig im Hinblick auf die benötigte Hardware und möglichst flexibel.

All diese Faktoren greifen: Der Index landet wahlweise auf Cassandra, Bigtable oder DynamoDB – alle drei Komponenten sind dafür bekannt, nahtlos in die Breite zu skalieren. Die Chunks speichert ein Objektspeicher wie Amazon S3, der ebenfalls problemlos skaliert. Und die zu Loki selbst gehörenden Komponenten wie die Distributoren und Querier arbeiten stateless und skalieren entsprechend ohnehin nach Belieben.

Etwas hakelig gibt sich lediglich der Ingester: Der ist, anders als seine Kollegen, eine Stateful-Applikation, die nicht einfach ausfallen darf. Der implementierte Ringmechanismus sorgt allerdings für die nötigen Features im Hinblick auf Sharding, sodass auch die Ingester beliebig oft vorhanden sein dürfen. Loki skaliert also tatsächlich nahtlos in die Breite. Da es die Inhalte der eingehenden Log-Daten nicht speichert, hinterlässt es dabei einen merklich kleineren Hardware-Fußabdruck als ein vergleichbarer ELK-Stack.

Die Loki-Doku enthält zur Skalierbarkeit ausführliche Hinweise, zusammengefasst sei aber gesagt: Um in die Breite zu skalieren, braucht Loki den Cluster-Konsens-Mechanismus Consul, um die Arbeitsschritte über die Grenzen von Knoten hinweg zu koordinieren. Wer Loki so betreiben möchte, sollte die entsprechende Doku gut lesen und verstehen, denn ein skaliertes Loki-Setup dieser Art fällt deutlich komplexer aus als eine einzelne Instanz.

Immerhin hat der Admin bei Loki aber die Wahl, das Setup entsprechend zu wählen. Das war zweifellos auch deshalb merklich leichter zu implementieren als bei Prometheus, weil Loki den Payload (also die Log-Daten) am Ende nicht selbst speichert: Das erledigen externe Speicher, auf deren Hochverfügbarkeit Loki sich entsprechend verlässt.

Woher kommen die Logs?

Bis hierhin hat der Artikel ausführlich beschrieben, wie Loki intern arbeitet und wie es Daten speichert und verwaltet. Ungeklärt blieb hingegen bisher die Frage, wie Log-Meldungen es schaffen, in Loki zu landen. Dabei gilt: Die ansonsten für Prometheus genutzten Node Exporter eignen sich hier nicht, denn die stellen fix auf Metrikdaten in Form von Zahlen ab. Prometheus selbst beherrscht gar nicht die Fähigkeit, andere Metrikdaten als Zahlen überhaupt irgendwie zu verarbeiten. Deshalb können die existierenden Prometheus-Exporter mit Log-Meldungen auch nichts anfangen.

Die Loki-Entwickler springen hier in die Bresche, indem sie ein eigenes Tool beisteuern: Promtail. Das Tail im Namen ist kein Zufall, schließlich verwenden viele Admins bis heute Tail auf der Kommandozeile, um den Inhalt von Log-Dateien einzusehen. So ähnlich darf man sich dann auch vorstellen, was Promtail tut: Es heftet sich an bestehende Logging-Quellen, zeichnet die dortigen Details auf und schickt sie an vordefinierte Instanzen des Loki-Servers.

Wie es der Admin von Prometheus möglicherweise schon gewohnt ist, gibt es auch bei Promtail die Möglichkeit, mit Labeln zu hantieren und diese im laufenden Betrieb durch Promtail umschreiben zu lassen. Erfahrene Prometheus-Jockeys merken schnell, dass Loki sich jedoch in einem Design-Aspekt fundamental von Prometheus absetzt: Während Prometheus seine Metrikdaten bei den Monitoring-Zielen selbst abholt, folgt Loki dem Push-Prinzip – die Promtail-Instanzen senden ihre Daten also an Loki.

Grafik mit Grafana

Weil Loki von den Grafana-Entwicklern kommt, erfolgt die Anzeige der aggregierten Log-Daten nur über dieses Tool. Dafür bietet Grafana ab Version 6.0 die benötigten Funktionen. Der Rest ist simpel: Der Admin richtet Loki so als Datenquelle ein, wie er das auch mit Prometheus tun würde. Grafana zeigt dann die entsprechenden Einträge an.

Über die Query-Sprache, die in Loki naturgemäß gewisse Ähnlichkeiten mit jener in Cortex und mithin in Prometheus aufweist, lassen sich selbst komplexe Queries bauen. Am Ende entpuppt sich Grafana mit dem Loki-Backend als nützliches Werkzeug für Log-Darstellung. Wer es weniger grafisch mag, findet in Form von Logcli auch ein Kommandozeilenwerkzeug zur Log-Anzeige; sonderlich komfortabel ist das erwartungsgemäß aber nicht.

Stark im Duett

Grundsätzlich lässt sich das Gespann aus Loki und Promtail freilich ebenso wie Prometheus völlig unabhängig von einer Container-Lösung einsetzen. Daran, dass die Entwickler für ihr Küken bevorzugt eine Kombination mit Kubernetes sehen wollen, lassen sie allerdings keinen Zweifel. Und in der Tat eignet die Lösung sich für Kubernetes besonders gut.

Einerseits ist auch Prometheus und mithin Cortex von Anfang an sehr eng mit Kubernetes verbunden. Das geht so weit, dass Prometheus sich direkt an die Kubernetes-Master-Server anhängen kann, um die Liste der Systeme zu finden, die es überwachen soll – die Node Discovery läuft hier also völlig automatisiert. Hinzu kommt, dass Prometheus bestens in der Lage ist, die von Kubernetes ausgegebenen Metrikdaten einzusammeln, zu interpretieren und dann zu speichern. Alle Labels, die zu den Metrikdaten gehören, verarbeitet es dabei völlig automatisch (Abbildung 4).

Abbildung 4: Loki lässt sich zwar unabhängig von Kubernetes betreiben, doch das Steckenpferd der Lösung ist die Kooperation mit Kubernetes. Quelle: Grafana

Loki erbt letztlich all diese Vorteile: Hängt man Loki an ein bestehendes Kubernetes-Prometheus-Setup an, lassen sich dieselben Label-Regeln recyceln, sodass das Setup leicht von der Hand geht.

Loki überwachen

Die beste Lösung für zentralisiertes Logging bleibt nutzlos, wenn sie gerade im Krisenfall nicht zur Verfügung steht. Dasselbe gilt, wenn der Admin aus Schusseligkeit vergessen hat, wichtige Log-Dateien in den Loki-Kreislauf zu integrieren. Die Loki-Entwickler bieten aber für beide Szenarien Support. Der kleine Dienst »Loki Canary« sucht auf Systemen systematisch nach solchen Log-Dateien, die Loki nicht einsammelt (Abbildung 5).

Abbildung 5: Loki lässt sich auch einsetzen, um die Log-Meldungen von Grafana selbst zu verarbeiten. Quelle: Grafana

Loki selbst wie auch Promtail geben über ihre Prometheus-Schnittstellen bei Bedarf sogar Metrikdaten zu sich selbst aus, die der Admin entsprechend in Prometheus integrieren kann. Das Operations-Handbuch von Loki listet passende Metriken auf.

Keine Multi Tenancy

Abschließend sei auf einen Umstand hingewiesen, den Loki unerfreulicherweise ebenfalls von Prometheus geerbt hat: Das Programm kennt keine Benutzerverwaltung und behandelt daher alle zugreifenden Nutzer gleichberechtigt. Für Multi Tenancy ist Loki damit nicht zu gebrauchen. Nutzer sollten stattdessen pro Tenant eine Loki-Instanz betreiben und diese so absichern, dass der Zugriff durch Eindringlinge von außen nicht möglich ist. (jcb)