🥇Logs mit Loki sammeln

Bei Badoo beobachten wir ständig neue Technologien und prüfen, ob es sinnvoll ist, diese in unserem System zu implementieren. Ein solches Projekt möchten wir nun mit der Community teilen. Es handelt sich um eine Untersuchung zu Loki – einem System zur Aggregation von Logs.

Loki ist eine Lösung zur Speicherung und Anzeige von Logs. Dieses System bietet zudem eine flexible Analyse- und Datensendefunktion für Prometheus. Im Mai wurde ein weiteres Update veröffentlicht, das von den Entwicklern aktiv gefördert wird. Uns interessierte, welche Funktionen Loki bietet, welche Möglichkeiten es eröffnet und inwieweit es als Alternative zum ELK-Stack dienen kann, den wir derzeit nutzen.

Was ist Loki

Grafana Loki ist ein Set von Komponenten für ein umfassendes Logs-Management-System. Im Gegensatz zu anderen ähnlichen Systemen basiert Loki auf der Idee, nur Metadaten der Logs – Labels (ähnlich wie in Prometheus) – zu indexieren, während die eigentlichen Logs in separaten Chunks komprimiert werden.

Startseite, GitHub

Bevor wir beschreiben, was man mit Loki alles tun kann, möchte ich erläutern, was mit der Idee gemeint ist, nur Metadaten zu indizieren. Lassen Sie uns den Ansatz von Loki mit dem traditionellen Indexierungsansatz in Lösungen wie Elasticsearch anhand eines Beispiels aus einem nginx-Log vergleichen:

172.19.0.4 - - [01/Jun/2020:12:05:03 +0000] "GET /purchase?user_id=75146478&item_id=34234 HTTP/1.1" 500 8102 "-" "Stub_Bot/3.0" "0.001"

Traditionelle Systeme parsen die gesamte Zeile, einschließlich der Felder mit einer großen Anzahl einzigartiger Werte wie user_id und item_id, und speichern alles in großen Indizes. Der Vorteil dieses Ansatzes liegt darin, dass komplexe Abfragen schnell ausgeführt werden können, da fast alle Daten im Index vorhanden sind. Dafür muss jedoch der Index groß werden, was den Speicherbedarf erhöht. Letztendlich ist der Volltextindex der Protokolle in etwa so groß wie die Protokolle selbst. Damit man schnell darin suchen kann, muss der Index im Speicher geladen sein. Je mehr Protokolle es gibt, desto schneller wächst der Index und desto mehr Speicher benötigt er.

Die Loki-Anforderungen verlangen, dass aus der Zeichenkette nur die notwendigen Daten extrahiert werden, deren Anzahl gering ist. Dadurch erhalten wir einen kleinen Index und können Daten suchen, indem wir sie nach Zeit und nach indizierten Feldern filtern und dann den Rest mit regulären Ausdrücken oder durch Substring-Suche scannen. Der Prozess scheint nicht der schnellste zu sein, aber Loki teilt die Abfrage in mehrere Teile auf und führt sie parallel aus, wodurch eine große Menge an Daten in kurzer Zeit verarbeitet werden kann. Die Anzahl der Shards und der parallelen Abfragen darin kann konfiguriert werden; somit hängt die Datenmenge, die pro Zeiteinheit verarbeitet werden kann, linear von der Anzahl der bereitgestellten Ressourcen ab.

Dieser Kompromiss zwischen einem großen schnellen Index und einem kleinen Index mit paralleler Vollprüfung ermöglicht es Loki, die Systemkosten zu kontrollieren. Es kann flexibel an die Bedürfnisse angepasst und erweitert werden.

Der Loki-Stack besteht aus drei Komponenten: Promtail, Loki und Grafana. Promtail sammelt Protokolle, verarbeitet sie und sendet sie an Loki. Loki speichert sie. Grafana kann die Daten aus Loki abfragen und visualisieren. Im Grunde kann Loki jedoch nicht nur zur Speicherung von Protokollen und deren Durchsuchung verwendet werden. Der gesamte Stack bietet umfangreiche Möglichkeiten zur Verarbeitung und Analyse der eingehenden Daten, basierend auf dem Prometheus-Ansatz.
Eine Beschreibung des Installationsprozesses finden Sie hier.

Protokollsuche

Die Suche in den Protokollen kann über die spezielle Grafana-Oberfläche – Explorer – erfolgen. Für Abfragen wird die LogQL-Sprache verwendet, die sehr ähnlich zu PromQL ist, welche in Prometheus zum Einsatz kommt. Grundsätzlich kann man sie als verteiltes grep betrachten.

Die Suchoberfläche sieht folgendermaßen aus:

Die Abfrage selbst besteht aus zwei Teilen: Selector und Filter. Der Selector bezieht sich auf den Suchvorgang in den indizierten Metadaten (Labels), die den Protokollen zugewiesen sind, während der Filter eine Suchzeile oder ein RegEx ist, mit dem die durch den Selector bestimmten Einträge gefiltert werden. Im angegebenen Beispiel: In geschweiften Klammern befindet sich der Selector, alles, was danach kommt, ist der Filter.

{image_name="nginx.promtail.test"} |= "index"

Aufgrund der Funktionsweise von Loki können Abfragen ohne Selector nicht durchgeführt werden, aber die Labels können so allgemein wie nötig gestaltet werden.

Ein Selector ist eine key-value Zuordnung in geschweiften Klammern. Sie können Selector kombinieren und unterschiedliche Suchbedingungen festlegen, indem Sie Operatoren wie =, != oder reguläre Ausdrücke verwenden.

{instance=~"kafka-[23]",name!="kafka-dev"} 
// Sucht nach Logs mit dem Label instance, die die Werte kafka-2, kafka-3 enthalten, und schließt dev aus.

Ein Filter ist ein Text oder ein regulärer Ausdruck, der alle Daten, die durch den Selector erhalten wurden, herausfiltert.

Es besteht die Möglichkeit, ad-hoc-Diagramme aus den erhaltenen Daten im metrics-Modus zu erstellen. Zum Beispiel kann die Häufigkeit eines Logeintrags, der den String index enthält, in den nginx-Logs ermittelt werden:

Eine vollständige Beschreibung der Funktionen finden Sie in der Dokumentation. LogQL.

Log-Parsing

Es gibt mehrere Möglichkeiten, Logs zu sammeln:

Durch Promtail, ein Standardkomponente des Stacks zur Log-Sammlung.
Direkt vom Docker-Container über den Loki Docker Logging Driver.
Verwenden Sie Fluentd oder Fluent Bit, die in der Lage sind, Daten an Loki zu senden. Im Gegensatz zu Promtail verfügen sie über fertige Parser für praktisch jeden Logtyp und können auch mit Multiline-Logs umgehen.

Üblicherweise wird Promtail für das Parsing verwendet. Es macht drei Dinge:

Es findet Datenquellen.
Es fügt Labels hinzu.
Es sendet die Daten an Loki.

Aktuell kann Promtail Protokolle von lokalen Dateien und aus dem systemd-Journal lesen. Er muss auf jeder Maschine installiert werden, von der Protokolle gesammelt werden.

Es gibt eine Integration mit Kubernetes: Promtail erfährt automatisch über die Kubernetes REST API den Status des Clusters und sammelt Protokolle von Knoten, Diensten oder Pods, während es Labels basierend auf den Metadaten aus Kubernetes (Pod-Name, Dateiname usw.) hinzufügt.

Labels können auch basierend auf Daten aus dem Protokoll mithilfe von Pipelines hinzugefügt werden. Eine Promtail-Pipeline kann aus vier Arten von Phasen bestehen. Mehr dazu in der offiziellen Dokumentation, hier seien einige Besonderheiten erwähnt.

Parsing-Stufen. Dies sind RegEx- und JSON-Phasen. In diesem Schritt extrahieren wir Daten aus den Protokollen in eine sogenannte extrahierte Map. Wir können entweder aus JSON die benötigten Felder in die extrahierte Map kopieren oder durch reguläre Ausdrücke (RegEx) extrahieren, wobei in der extrahierten Map die benannten Gruppen „gemappt“ werden. Die extrahierte Map ist ein Key-Value-Speicher, wobei der Key der Feldname und der Value dessen Wert aus den Protokollen ist.
Transformationsphasen. Diese Phase bietet zwei Optionen: transform, in der wir die Transformationsregeln festlegen, und source – die Datenquelle für die Transformation aus der extrahierten Map. Wenn in der extrahierten Map kein solches Feld vorhanden ist, wird es erstellt. So können Labels erstellt werden, die nicht auf der extrahierten Map basieren. In diesem Schritt können wir die Daten in der extrahierten Map manipulieren und dabei eine ausreichende Flexibilität nutzen. Golang Template. Zudem ist zu beachten, dass die extrahierte Map beim Parsen vollständig geladen wird, was beispielsweise die Möglichkeit bietet, einen Wert darin zu überprüfen: “{{if .tag}tag-Wert existiert{end}}”. Das Template unterstützt Bedingungen, Schleifen und einige Stringfunktionen wie Replace und Trim.
Aktionsphasen. In dieser Phase kann etwas mit den extrahierten Daten gemacht werden:
- Ein Label aus den extrahierten Daten erstellen, das in Loki indiziert wird.
- Die Zeit des Ereignisses im Log ändern oder festlegen.
- Die Daten (Log-Text) ändern, die an Loki gesendet werden.
- Metriken erstellen.
Filterphasen. Die Match-Phase, in der wir entweder unerwünschte Einträge an /dev/null senden oder sie zur weiteren Verarbeitung leiten können.

Ich werde am Beispiel der Verarbeitung von regulären nginx-Logs zeigen, wie man Logs mit Promtail parsen kann.

Für den Test verwenden wir das modifizierte nginx-Proxy-Image jwilder/nginx-proxy:alpine und einen kleinen Daemon, der in der Lage ist, sich selbst über HTTP zu befragen. Der Daemon hat mehrere Endpunkte, auf die er mit verschiedenen Antwortgrößen, HTTP-Statuscodes und unterschiedlichen Verzögerungen reagieren kann.

Die Protokolle sammeln wir von den Docker-Containern, die unter dem Pfad /var/lib/docker/containers//-json.log zu finden sind.

In der docker-compose.yml konfigurieren wir Promtail und geben den Pfad zur Konfiguration an:

promtail:
  image: grafana/promtail:1.4.1
 // ...
 volumes:
   - /var/lib/docker/containers:/var/lib/docker/containers:ro
   - promtail-data:/var/lib/promtail/positions
   - ${PWD}/promtail/docker.yml:/etc/promtail/promtail.yml
 command:
   - '-config.file=/etc/promtail/promtail.yml'
 // ...

Fügen Sie in promtail.yml den Pfad zu den Protokollen hinzu (in der Konfiguration gibt es die Option "docker", die dasselbe in einer Zeile tun würde, aber dies wäre nicht so anschaulich):

scrape_configs:
 - job_name: containers

   static_configs:
       labels:
         job: containerlogs
         __path__: /var/lib/docker/containers/*/*log  # nur für Linux

Wenn diese Konfiguration aktiviert ist, landen die Protokolle aller Container in Loki. Um dies zu vermeiden, ändern wir die Einstellungen des Test-nginx in der docker-compose.yml — wir fügen das Logging-Feld tag hinzu:

proxy:
 image: nginx.test.v3
//…
 logging:
   driver: "json-file"
   options:
     tag: "{{.ImageName}}|{{.Name}}"

Wir erstellen die promtail.yml und konfigurieren die Pipeline. Die Eingabedaten sind Protokolle folgender Art:

{"log":"u001b[0;33;1mnginx.1 | u001b[0mnginx.test 172.28.0.3 - - [13\/Jun\/2020:23:25:50 +0000] \"GET \/api\/index HTTP\/1.1\" 200 0 \"-\" \"Stub_Bot\/0.1\" \"0.096\"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.66740443Z"}
{"log":"u001b[0;33;1mnginx.1 | u001b[0mnginx.test 172.28.0.3 - - [13\/Jun\/2020:23:25:50 +0000] \"GET \/200 HTTP\/1.1\" 200 0 \"-\" \"Stub_Bot\/0.1\" \"0.000\"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.702925272Z"}

Pipeline-Stufe:

 - json:
     expressions:
       stream: stream
       attrs: attrs
       tag: attrs.tag

Wir extrahieren die Felder stream, attrs und attrs.tag aus dem eingehenden JSON (sofern vorhanden) und legen sie in einer extrahierten Map ab.

 - regex:
     expression: ^(?P([^|]+))|(?P([^|]+))$
     source: "tag"

Falls das Feld tag in die extrahierte Map abgelegt werden konnte, extrahieren wir mit Regex die Namen von Image und Container.

 - labels:
     image_name:
     container_name:

Wir weisen Labels zu. Wenn in den extrahierten Daten die Schlüssel image_name und container_name gefunden werden, werden deren Werte den entsprechenden Labels zugewiesen.

 - match:
     selector: '{job="docker",container_name="",image_name=""}'
     action: drop

Wir verwerfen alle Protokolle, bei denen die festgelegten Labels image_name und container_name nicht gefunden wurden.

  - match:
     selector: '{image_name="nginx.promtail.test"}'
     stages:
       - json:
           expressions:
             row: log

Für alle Logs, bei denen der image_name nginx.promtail.test ist, extrahieren wir aus dem Quell-Log das Feld log und fügen es der extracted map mit dem Schlüssel row hinzu.

  - regex:
         # unterdrücke Farben von forego
         expression: .+nginx.+|.+[0m(?P[a-z_.-]+) +(?P.+)
         source: logrow

Wir bereinigen die Eingangszeile mit regulären Ausdrücken und extrahieren den nginx Virtual Host sowie die nginx Log-Zeile.

     - regex:
         source: nginxlog
         expression: ^(?P[w.]+) - (?P[^ ]*) [(?P[^ ]+).*] "(?P[^ ]*) (?P[^ ]*) (?P[^ ]*)" (?P[d]+) (?P[d]+) "(?P[^"]*)" "(?P[^"]*)"( "(?P[d.]+)")?

Wir parsen das nginx-Log mit regulären Ausdrücken.

    - regex:
           source: request_url
           expression: ^.+.(?Pjpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js|flv|swf|html|htm)$
     - regex:
           source: request_url
           expression: ^/photo/(?P[^/?.]+).*$
       - regex:
           source: request_url
           expression: ^/api/(?P[^/?.]+).*$

Wir analysieren request_url. Mithilfe von regulären Ausdrücken bestimmen wir das Ziel der Anfrage: ob es um statische Inhalte, Fotos oder die API geht und setzen den entsprechenden Schlüssel in die extracted map.

       - template:
           source: request_type
           template: "{{if .photo}}photo{{else if .static_type}}static{{else if .api_request}}api{{else}}other{{end}}"

Mit Hilfe von bedingten Operators in Template überprüfen wir die festgelegten Felder in der extrahierten Map und setzen die erforderlichen Werte für das Feld request_type: photo, static, API. Wir weisen other zu, falls dies nicht gelingt. Nun enthält request_type den Typ der Anfrage.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

Wir setzen die Labels api_request, virtual_host, request_type und Status (HTTP-Status) basierend auf dem, was wir in die extrahierte Map eintragen konnten.

       - output:
           source: nginx_log_row

Wir ändern das Output. Jetzt wird das bereinigte nginx-Log aus der extrahierten Map an Loki gesendet.

Nach dem Start der angegebenen Konfiguration kann man sehen, dass jeder Eintrag basierend auf den Log-Daten mit Labels versehen wurde.

Es ist zu beachten, dass das Extrahieren von Labels mit einer hohen Anzahl von Werten (Cardinality) die Leistung von Loki erheblich verlangsamen kann. Man sollte also beispielsweise user_id nicht indizieren. Weitere Informationen dazu finden Sie im Artikel “Wie Labels in Loki Log-Abfragen schneller und einfacher machen können”. Das bedeutet jedoch nicht, dass man nicht nach user_id ohne Indizes suchen kann. Filtersysteme sollten beim Suchen verwendet werden (z. B. durch die Daten „greppen“), wobei der Index als Stream-Identifikator fungiert.

Visualisierung von Logs

Loki kann als Datenquelle für Grafana-Diagramme über LogQL fungieren. Folgende Funktionen werden unterstützt:

rate — Anzahl der Einträge pro Sekunde;
count over time — Anzahl der Einträge in einem bestimmten Zeitraum.

Zusätzlich stehen aggregierende Funktionen wie Sum, Avg und andere zur Verfügung. Man kann recht komplexe Diagramme erstellen, wie zum Beispiel ein Diagramm der HTTP-Fehleranzahl:

Die Standard-Datenquelle Loki hat im Vergleich zur Datenquelle Prometheus einige Einschränkungen (zum Beispiel kann die Legende nicht geändert werden), aber Loki kann als Quelle vom Typ Prometheus angeschlossen werden. Ich bin mir nicht sicher, ob dieses Verhalten dokumentiert ist, aber laut der Antwort der Entwickler “How to configure Loki as Prometheus datasource? · Issue #1222 · grafana/loki”, scheint dies durchaus legitim zu sein, und Loki ist vollständig mit PromQL kompatibel.

Fügen Sie Loki als Datenquelle vom Typ Prometheus hinzu und ergänzen Sie die URL /loki:

Und man kann Diagramme erstellen, als würden wir mit Metriken aus Prometheus arbeiten:

Ich denke, dass die Diskrepanz in der Funktionalität vorübergehend ist und die Entwickler dies in Zukunft beheben werden.

Metriken

In Loki haben Sie die Möglichkeit, numerische Metriken aus Protokollen zu extrahieren und an Prometheus zu senden. Im nginx-Protokoll sind beispielsweise die Anzahl der Bytes pro Antwort enthalten, sowie, bei einer bestimmten Modifikation des Standard-Logformats, die Zeit in Sekunden, die für die Antwort benötigt wurde. Diese Daten können extrahiert und an Prometheus gesendet werden.

Fügen Sie einen weiteren Abschnitt in die promtail.yml ein:

- match:
   selector: '{request_type="api"}'
   stages:
     - metrics:
         http_nginx_response_time:
           type: Histogram
           description: "Antwortzeit in ms"
           source: response_time
           config:
             buckets: [0.010,0.050,0.100,0.200,0.500,1.0]
- match:
   selector: '{request_type=~"static|photo"}'
   stages:
     - metrics:
         http_nginx_response_bytes_sum:
           type: Counter
           description: "Summe der Antwortbytes"
           source: bytes_out
           config:
             action: add
         http_nginx_response_bytes_count:
           type: Counter
           description: "Anzahl der Antwortbytes"
           source: bytes_out
           config:
             action: inc

Die Option ermöglicht das Festlegen und Aktualisieren von Metriken basierend auf Daten aus der extrahierten Karte. Diese Metriken werden nicht an Loki gesendet – sie erscheinen im Promtail /metrics-Endpunkt. Prometheus muss so konfiguriert werden, dass es die Daten erhält, die in diesem Schritt gesammelt wurden. Im gezeigten Beispiel für request_type="api" erfassen wir eine Histogramm-Metrik. Mit diesem Metriktyp ist es einfach, Perzentile zu erhalten. Für statische Inhalte und Bilder sammeln wir die Byte-Summe sowie die Anzahl der Zeilen, in denen wir Bytes erhalten haben, um den Durchschnitt zu berechnen.

Mehr über Metriken erfahren Sie hier.

Öffnen Sie den Port auf Promtail:

promtail:
     image: grafana/promtail:1.4.1
     container_name: monitoring.promtail
     expose:
       - 9080
     ports:
       - "9080:9080"

Stellen Sie sicher, dass die Metriken mit dem Präfix promtail_custom erschienen sind:

Konfigurieren Sie Prometheus. Fügen Sie den Job promtail hinzu:

- job_name: 'promtail'
 scrape_interval: 10s
 static_configs:
   - targets: ['promtail:9080']

Und erstellen Sie ein Diagramm:

So können beispielsweise die vier langsamsten Anfragen ermittelt werden. Außerdem kann das Monitoring auf diese Metriken eingerichtet werden.

Skalierung

Loki kann sowohl im Einzelmodus (Single-Binary-Mode) als auch im shardbaren (horizontal skalierbaren) Modus betrieben werden. Im zweiten Fall kann er Daten in der Cloud speichern, wobei Chunks und Indizes getrennt aufbewahrt werden. In Version 1.5 wurde die Möglichkeit implementiert, alles an einem Ort zu speichern, jedoch wird empfohlen, diese Funktion vorerst nicht in der Produktionsumgebung zu verwenden.

Chunks können in einem S3-kompatiblen Speicher aufbewahrt werden, während zur Speicherung der Indizes horizontal skalierbare Datenbanken wie Cassandra, BigTable oder DynamoDB verwendet werden sollten. Die anderen Teile von Loki – Distributors (für das Schreiben) und Querier (für Abfragen) – sind zustandslos (stateless) und ebenfalls horizontal skalierbar.

Auf der Konferenz DevOpsDays Vancouver 2019 erwähnte einer der Teilnehmer, Callum Styan, dass sein Projekt mit Loki Petabytes an Logs hat, die einen Index von weniger als 1 % der Gesamtgröße aufweisen: “Wie Loki Metriken und Logs korreliert – und Ihnen Geld spart”.

Vergleich zwischen Loki und ELK

Größe des Index

Um die Größe des erzeugten Indexes zu testen, habe ich Logs vom nginx-Container genommen, für den der oben angegebene Pipeline konfiguriert wurde. Die Logdatei umfasste 406.624 Zeilen mit einem Gesamtvolumen von 109 MB. Die Logs wurden über eine Stunde hinweg mit etwa 100 Einträgen pro Sekunde generiert.

Beispiel von zwei Zeilen aus dem Log:

Bei der Indizierung mit ELK ergab sich eine Indexgröße von 30,3 MB:

Im Fall von Loki ergab sich ein Index von etwa 128 KB und rund 3,8 MB an Daten in den Chunks. Es ist zu bemerken, dass das Log künstlich generiert wurde und nicht besonders vielfältige Daten enthielt. Eine einfache Gzip-Kompression des originalen Docker-JSON-Logs ergab eine Kompression von 95,4 %. Da nur die bereinigten Nginx-Logs an Loki gesendet wurden, ist die Reduzierung auf 4 MB nachvollziehbar. Die Gesamtzahl der einzigartigen Werte für die Labels in Loki betrug 35, was die geringe Größe des Index erklärt. Auch für ELK wurde das Log gereinigt. Somit komprimierte Loki die Ausgangsdaten um 96 %, während ELK eine Reduktion von 70 % erreichte.

Speicherverbrauch

Wenn man den gesamten Stack von Prometheus mit ELK vergleicht, verbraucht Loki deutlich weniger. Offensichtlich benötigt ein Dienst in Go weniger Ressourcen als ein Dienst in Java, und ein Vergleich des JVM-Heaps von Elasticsearch mit dem für Loki reservierten Speicher ist nicht korrekt. Dennoch ist zu erwähnen, dass Loki erheblich weniger Speicher verwendet. Sein Vorteil in Bezug auf CPU ist nicht so offensichtlich, ist aber ebenfalls vorhanden.

Geschwindigkeit

Loki verarbeitet Protokolle wesentlich schneller. Die Geschwindigkeit hängt von vielen Faktoren ab — welche Protokolle vorliegen, wie raffiniert wir sie analysieren, Netzwerk, Festplatte usw. — aber sie ist eindeutig höher als bei ELK (in meinem Test etwa doppelt so schnell). Das liegt daran, dass Loki viel weniger Daten indiziert und dementsprechend weniger Zeit für die Indizierung benötigt. Bei der Suchgeschwindigkeit verhält es sich allerdings umgekehrt: Loki verlangsamt spürbar bei Datenmengen von über mehreren Gigabyte, während die Suche bei ELK unabhängig von der Datenmenge bleibt.

Protokollsuche

Loki hat im Vergleich zu ELK deutlich eingeschränkte Suchmöglichkeiten für Protokolle. Grep mit regulären Ausdrücken ist zwar sehr leistungsfähig, hat aber gegenüber einer vollwertigen Datenbank das Nachsehen. Das Fehlen von Bereichsanfragen, Aggregation nur nach Labels und die Unmöglichkeit, ohne Labels zu suchen, schränken uns in der Suche nach relevanten Informationen in Loki ein. Das bedeutet nicht, dass man mit Loki nichts finden kann, aber es legt den Arbeitsablauf fest, bei dem man zuerst das Problem in den Grafiken von Prometheus identifiziert und dann anhand dieser Labels nach den Ursachen in den Protokollen sucht.

Benutzeroberfläche

Erstens, es ist schön (entschuldigen Sie, ich konnte nicht widerstehen). Grafana hat eine ansprechende Benutzeroberfläche, aber Kibana bietet weitaus mehr Funktionalität.

Vor- und Nachteile von Loki

Zu den Vorteilen gehört, dass Loki sich nahtlos mit Prometheus integriert. Somit erhalten wir Metriken und Alarme direkt out-of-the-box. Es ist benutzerfreundlich für die Sammlung und Speicherung von Logs mit Kubernetes Pods, da es die Service-Entdeckung von Prometheus erbt und automatisch Labels hinzufügt.

Zu den Nachteilen gehört die mangelnde Dokumentation. Einige Aspekte, wie die Funktionen von Promtail, habe ich nur während des Studiums des Codes entdeckt, zum Glück ist es Open Source. Ein weiterer Nachteil sind die schwachen Parsing-Möglichkeiten. Zum Beispiel kann Loki keine Multiline-Logs parsen. Auch die Tatsache, dass Loki eine relativ neue Technologie ist (Release 1.0 war im November 2019), zählt zu den Nachteilen.

Fazit

Loki ist eine zu 100% interessante Technologie, die sich für kleine und mittelgroße Projekte eignet und eine Vielzahl von Aufgaben zur Aggregation, Suche, Überwachung und Analyse von Logs bewältigt.

Wir nutzen Loki in Badoo nicht, da wir ein ELK-Stack haben, der uns zufriedenstellt und über die Jahre mit verschiedenen maßgeschneiderten Lösungen erweitert wurde. Für uns ist die Suche in den Logs eine Herausforderung. Bei fast 100 GB Logs pro Tag ist es für uns wichtig, alles und noch ein bisschen mehr schnell zu finden. Für die Erstellung von Grafiken und das Monitoring verwenden wir andere Lösungen, die auf unsere Bedürfnisse zugeschnitten und miteinander integriert sind. Der Loki-Stack hat spürbare Vorteile, aber er bietet uns nicht mehr als das, was wir bereits haben, und seine Vorteile rechtfertigen nicht die Migrationskosten.

Auch wenn nach der Untersuchung klar wurde, dass wir Loki nicht verwenden können, hoffen wir, dass dieser Beitrag Ihnen bei der Auswahl hilft.

Das Repository mit dem in diesem Artikel verwendeten Code befindet sich hier.

Quelle: habr.com