![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/03\/logo_and_name-1.png\"){kind=logo}
<\/a><\/figure><\/div>\n\n\n\nGrafana Loki ist eine Kombination aus mehreren Komponenten, die zu einem vollwertigen Logging-Stack zusammengestellt werden k\u00f6nnen. Das Loki-Projekt wurde 2018 bei Grafana Labs gestartet. Es wurde in Golang geschrieben und ist eine Open Source Software, welche unter der AGPLv3-Lizenz ver\u00f6ffentlicht wurde. Loki ist ein horizontal skalierbares, hochverf\u00fcgbares, mandantenf\u00e4higes Log-Aggregation System nach dem Vorbild von Prometheus. Es entstand aus der Motivation heraus, die drei Komponenten der Observability (Beobachtbarkeit) Metriken, Logs und Tracing so einfach wie m\u00f6glich in einem Dashboard zu vereinen, um eine schnelle und unkomplizierte Fehlerermittlung zu erm\u00f6glichen. Damit ein nahtloser Wechsel zwischen den Komponenten stattfinden kann, werden die gesammelten Events mit denselben Metadaten wie bei den Prometheus-Daten versehen. Hierunter fallen zum Beispiel Namespace, Servicename und Instanz-IP. [1]<\/p>\n\n\n\n
<\/a><\/figure><\/div>\n\n\n\nSpricht man von Grafana, so ist in der Regel eine Dashboarding-L\u00f6sung f\u00fcr time-series Daten gemeint. Grafana unterst\u00fctzt \u00fcber 40 Datenquellen. Im Kontext Monitoring und Logging ist es als Dashboard L\u00f6sung f\u00fcr Prometheus Daten bekannt. [2]<\/p>\n\n\n\n
<\/a><\/figure><\/div>\n\n\n\nPrometheus ist eine Open Source Monitoring- und Alerting-L\u00f6sung. Es zeichnet Echtzeitmetriken in einer Zeitreihendatenbank auf, welche in Grafana visualisiert werden k\u00f6nnen. [3]<\/p>\n\n\n\n Loki verfolgt bei der Speicherung der Logdaten einen Ansatz, bei dem nur ein kleiner Teil der Metadaten jeder Logline indiziert werden. Eine Speicherung derselben Logdaten in Loki ben\u00f6tigt weit weniger Speicherplatz, als dies beispielsweise bei Elasticsearch, welcher im ELK-Stack zum Einsatz kommt, der Fall w\u00e4re. <\/p>\n\n\n\n Anhand des folgenden Log-Ausschnittes erfolgt ein direkter Vergleich zwischen Elasticsearch und Loki, welcher den Unterschied der beiden Indizierungsans\u00e4tze verdeutlicht.<\/p>\n\n\n\n Elasticsearch analysiert den gesamten String, einschlie\u00dflich der Felder mit hoher Kardinalit\u00e4t wie itemID oder userID, und speichert alle Werte in einem gro\u00dfen Index.<\/p>\n\n\n\n Dies f\u00fchrt oft dazu, dass der Index meist gr\u00f6\u00dfer ist als die eigentlichen Logdaten. Der Ursprung hiervon liegt in der Architektur von Elasticsearch. Es baut auf dem Lucene-Suchmaschinenprojekt auf, welches f\u00fcr Szenarien mit geringem Schreib-\/Leseaufwand konzipiert ist. Hierbei dauert das Schreiben l\u00e4nger, was jedoch das lesen und suchen vereinfacht und verschnellert. Bei Logs ist jedoch meist das Gegenteil der Fall. Hier wird viel geschrieben jedoch nur selten gelesen. [6]<\/p>\n\n\n\n Beispiel daf\u00fcr, wie Loki typischerweise die Logzeile indiziert:<\/p>\n\n\n\n Loki indiziert nur einige wenige Felder, sodass der Index sehr klein ist. Die erzeugten Logs k\u00f6nnen mittels Filter wie Zeitspanne und indizierten Feldern (Labels), sowie durch den Einsatz von Teil-String-Suche oder regul\u00e4ren Ausdr\u00fccken, abgefragt werden.<\/p>\n\n\n\n [5],[6]<\/p>\n\n\n\n Promtail ist ein Log-Kollektor, welcher speziell f\u00fcr Loki entwickelt wurde. Dieser ist in Golang geschrieben und wird typischerweise als Daemonset in einem Kubernetscluster ausgerollt. Promtail ist jedoch nicht ausschlie\u00dflich f\u00fcr Kubernetes-Nodes. Es kann ebenfalls auf einer lokalen Maschine ausgerollt werden. Installatiospakete werden auf der Grafana Loki Github-Seite<\/a> angeboten. <\/p>\n\n\n\n Damit Promtail Logdaten an Loki senden kann, ben\u00f6tigt es Informationen \u00fcber seine Umgebung. Zur zur leichteren Identifizierung von Services k\u00f6nnen ebenfalls Labels mitgegeben werden. Sie werden an die Log-Zeilen angeh\u00e4ngt. [7]<\/p>\n\n\n\n Neben Promtail k\u00f6nnen auch andere Tools wie Logstash (verwendet im ELK-Stack) verwendet werden. Promtail sendet Logs in Batches an Loki.<\/p>\n\n\n\n Wie bereits erw\u00e4hnt, besteht die Loki Anwendung aus mehreren Komponenten-Microservices. Dem Distributor, sowie dem Ingestor, dem Ruler, Querier und Query-Frontend.<\/p>\n\n\n\n Der Distributor ist f\u00fcr die Verarbeitung eingehender Streams der Log-Kollektoren verantwortlich. Ein Stream ist eine Sammlung von Logs die einem Mandanten und eindeutigen Labels zuordenbar sind. Die Distributoren von Loki verwenden Consistent Hashing in Verbindung mit einem Replikationsfaktor, um zu bestimmen, welche Instanz des Ingestor-Service den Stream erhalten soll. Ein Stream wird dazu mit der Mandanten-ID, sowie dem Labelset gehasht. Um Consistent Hashing zu erreichen, wird ein Hash-Ring verwendet. Dabei registriert sich jeder Ingestor mit einer Reihe von Tokens und ihrem jeweiligen Status im Ring. Ingestoren mit dem Status JOINING und ACTIVE k\u00f6nnen Schreibanforderungen empfangen. Ein Ingestor mit dem Status ACTIVE und LEAVING empf\u00e4ngt Leseanforderungen. Bei einer Hash-Suche (Lesende oder Schreibende Anfragen) werden nur die Ingestor beachtet, die sich im richtigen Status befinden. <\/p>\n\n\n\n Um die Hash-Suche durchzuf\u00fchren, finden Distributoren den kleinsten geeigneten Token, dessen Wert gr\u00f6\u00dfer ist als der Hash des Streams. Wenn der Replikationsfaktor gr\u00f6\u00dfer als eins ist, wird der gehashte Stream dem n\u00e4chstfolgenden Token (Ingestor) im Uhrzeigersinn zugeordnet. [9]<\/p>\n\n\n\n Der Ingestor ist verantwortlich f\u00fcr das Speichern von Logdaten. Diese werden bei Loki in ein einziges Objektspeicher-Backend, wie DynamoDB, S3, Cassandra oder \u00e4hnliche, geschrieben. Hierzu werden die eintreffenden Streams im Arbeitsspeicher in Chunks (Bl\u00f6cke) unterteilt und in einem konfigurierbaren Intervall an das Speicher-Backend gesendet. <\/p>\n\n\n\n Sobald ein Ingestor ausgerollt wurde, kann er unterschiedliche Zust\u00e4nde einnehmen. Diese k\u00f6nnen PENDING, JOINING, ACTIVE, LEAVING oder UNHEALTHY sein. Die ausf\u00fchrlicherere Erl\u00e4uterung der jeweiligen Status sind in der zugeh\u00f6rigen Dokumentation <\/a>festgehalten. <\/p>\n\n\n\n St\u00fcrzt ein Ingestor ab oder wird abrupt beendet, k\u00f6nnen alle noch nicht gespeicherten Chunks im Arbeitsspeicher verloren gehen. Loki verwendet hierzu das Write Ahead Log Prinzip (WAL) um nach einem Neustart die Persistenz best\u00e4tigter Daten zu gew\u00e4hrleisten.<\/p>\n\n\n\n Hierzu werden eingehende Daten aufgezeichnet und im lokalen Dateisystem gespeichert. Beim Neustart werden die Daten aus dem Protokoll neu eingespielt, bevor sich der Ingestor selbst als bereit f\u00fcr nachfolgende Schreibvorg\u00e4nge registriert. Beim Herunterfahren oder beim Verlassen des Hash-Rings wartet ein Ingestor standardm\u00e4\u00dfig darauf, ob ein neuer Ingestor seine Aufgaben \u00fcbernimmt. Ist dies nicht der Fall, werden die noch nicht gespeicherten Logs an den Langzeitspeicher gesendet. Andernfalls findet eine \u00dcbergabe statt. Bei der \u00dcbergabe werden alle Token und In-Memory-Chunks, die dem verlassenden Ingestor geh\u00f6ren, an den neuen Ingestor \u00fcbergeben. Bevor ein Ingestor dem Hash-Ring beitreten, wartet dieser im PENDING Status auf eine \u00dcbergabe. Nach einer konfigurierbaren Zeit\u00fcberschreitung werden Ingestoren im PENDING Zustand, die keine \u00dcbertragung erhalten haben, dem Ring normal beitreten und einen neuen Satz von Tokens einf\u00fcgen. [9]<\/p>\n\n\n\n Die Ruler-Komponente ist daf\u00fcr verantwortlich, eine Reihe konfigurierbarer Abfragen kontinuierlich auszuwerten und auf der Grundlage des Ergebnisses, Aktionen auszuf\u00fchren. Es gibt zwei Haupttypen von Regeln die die Ruler-Komponente unterst\u00fctzt: Alerting Rules und Recording Rules. Diese k\u00f6nnen selbst konfiguriert, jedoch kann auch auf vorgefertigte Sets zur\u00fcckgegriffen, werden (s. Beispielkonfiguration<\/a>). [10]<\/p>\n\n\n\n Das Query Frontend ist ein optionaler Dienst der die Api-Endpunkte f\u00fcr Leseanfragen bereitstellt. Ist ein Query Frontend vorhanden, sollten eingehende Abfragen an das Frontend und nicht an die Queriers geleitet werden. Der Querier-Dienst wird weiterhin innerhalb des Clusters ben\u00f6tigt um die eigentlichen Abfragen auszuf\u00fchren. Das Frontend f\u00fchrt intern einige Anpassungen an die Abfragen durch und h\u00e4lt diese in einer internen Warteschlange. Gr\u00f6\u00dfere Abfragen werden beispielsweise in mehrere kleinere Abfragen aufgeteilt. Diese k\u00f6nnen dann parallel auf nachgelagerten Queriers ausgef\u00fchrt werden. Das Frontend f\u00fcgt die Ergebnisse nach Bearbeitung wieder zusammen. Dies verhindert Speicher\u00fcberl\u00e4ufe bei gro\u00dfen Abfragen in einem einzelnen Querier. Zudem k\u00f6nnen Ergebnisse schneller geliefert werden. Das Query Frontend ist zudem in der Lage Abfrageergebnisse zwischenzuspeichern (Caching) und diese bei nachfolgenden Abfragen erneut zu verwenden. [9]<\/p>\n\n\n\n Der Querier verarbeitet Abfragen mithilfe von LogQL. Dies ist eine Abfragesprache mit der er in der Lage ist auf Protokolle im Langzeitspeicher, sowie auf In-Memory-Daten der Ingestoren, zuzugreifen. Die Abfrage kann direkt im Grafana erfolgen, welches die Logs visualisiert. [9]<\/p>\n\n\n\n Der ELK-Stack verwendet Logstash als Log Kollektor. Im Vergleich hierzu verwendet Grafana Loki standardm\u00e4\u00dfig Promtail – kann aber auch mit anderen Log-Kollektoren wie Fluentd oder Logstash arbeiten. Als Dashboard im ELK-Stack wird Kibana eingesetzt. Verwendet man f\u00fcrs Monitoring Prometheus mit Grafana wird mit Loki kein zus\u00e4tzliches Dashboard ben\u00f6tigt, da dieses ebenfalls Grafana nutzt. Statt einem Objectstore (Loki) wie S3 oder Cassandra verwendet der ELK-Stack das ressourcenhungrige Elasticsearch. Hierbei werden die Logs als unstrukturierte JSON-Objekte gespeichert. Loki macht keine Volltextindexierung sondern speichert lediglich die Metadaten. Ein direkter Vergleich zwischen dem ELK-Stack, Splunk (ein weiteres Log-Aggregation-System) und Loki zeigt einen deutlich geringeren Speicherbedarf bei Loki. <\/p>\n\n\n\n Loki stellt somit eine echte Alternative zu bereits bestehenden Systemen dar.<\/p>\n\n\n\n<\/a>Funktionsweise<\/h1>\n\n\n\n
Indexierung<\/h2>\n\n\n\n
<\/a>10.185.248.71 - - [09\/Jan\/2015:19:12:06 +0000] 808840 "GET \/inventoryService\/purchaseItem?userId=20253471&itemId=23434300 HTTP\/1.1" 500 17 "-" "Apache-HttpClient\/4.2.6 (java 1.5)"<\/code><\/pre>\n\n\n\nElasticsearch<\/strong><\/h3>\n\n\n\n
<\/a>Grafana Loki<\/strong><\/h3>\n\n\n\n
<\/a>Log-Kollektoren<\/h2>\n\n\n\n
<\/a><\/a><\/a>Komponenten<\/h1>\n\n\n\n
<\/a>Distributor<\/h2>\n\n\n\n
<\/a>Ingestor<\/h2>\n\n\n\n
Ruler<\/h2>\n\n\n\n
Query Frontend<\/h2>\n\n\n\n
Querier<\/h2>\n\n\n\n
Zusammenfassung und Vergleich zum ELK-Stack<\/h1>\n\n\n\n
<\/a>Quellenangaben<\/h1>\n\n\n\n