Protokolle von Loki sammeln

Wir bei Badoo überwachen ständig neue Technologien und prüfen, ob wir sie in unserem System verwenden möchten oder nicht. Wir möchten eine dieser Studien mit der Community teilen. Es ist Loki gewidmet, einem Protokollaggregationssystem.

Loki ist eine Lösung zum Speichern und Anzeigen von Protokollen. Darüber hinaus bietet dieser Stack ein flexibles System für deren Analyse und das Senden von Daten an Prometheus. Im Mai wurde ein weiteres Update veröffentlicht, das von den Machern aktiv beworben wird. Uns interessierte, was Loki kann, welche Funktionen es bietet und inwieweit es als Alternative zu ELK, dem Stack, den wir jetzt verwenden, fungieren kann.

Was ist Loki?

Grafana Loki ist eine Reihe von Komponenten für ein komplettes Protokollierungssystem. Im Gegensatz zu anderen ähnlichen Systemen basiert Loki auf der Idee, nur Protokollmetadaten – Etiketten (genau wie in Prometheus) – zu indizieren und die Protokolle selbst nebeneinander in separate Blöcke zu komprimieren.

Startseite, GitHub

Bevor ich darauf eingehe, was man mit Loki machen kann, möchte ich klarstellen, was mit „der Idee, nur Metadaten zu indizieren“ gemeint ist. Vergleichen wir den Loki-Ansatz und den Indexierungsansatz in traditionellen Lösungen wie Elasticsearch am Beispiel einer Zeile aus dem Nginx-Protokoll:

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"

Herkömmliche Systeme analysieren die gesamte Zeile, einschließlich Feldern mit vielen eindeutigen user_id- und item_id-Werten, und speichern alles in großen Indizes. Der Vorteil dieses Ansatzes besteht darin, dass Sie komplexe Abfragen schnell ausführen können, da sich fast alle Daten im Index befinden. Allerdings muss man dafür bezahlen, dass der Index groß wird, was sich in einem Speicherbedarf niederschlägt. Dadurch ist der Volltextindex der Protokolle in der Größe mit den Protokollen selbst vergleichbar. Um ihn schnell durchsuchen zu können, muss der Index in den Speicher geladen werden. Und je mehr Protokolle vorhanden sind, desto schneller steigt der Index und desto mehr Speicher verbraucht er.

Der Loki-Ansatz erfordert, dass nur die notwendigen Daten aus der Zeichenfolge extrahiert werden, deren Anzahl an Werten gering ist. Auf diese Weise erhalten wir einen kleinen Index und können die Daten durchsuchen, indem wir sie nach Zeit und indizierten Feldern filtern und den Rest dann mit regulären Ausdrücken oder Teilzeichenfolgensuchen durchsuchen. Der Prozess scheint nicht der schnellste zu sein, aber Loki teilt die Anfrage in mehrere Teile auf und führt sie parallel aus, wodurch eine große Datenmenge in kurzer Zeit verarbeitet wird. Die Anzahl der Shards und parallelen Anfragen darin ist konfigurierbar; Somit hängt die Datenmenge, die pro Zeiteinheit verarbeitet werden kann, linear von der Menge der bereitgestellten Ressourcen ab.

Dieser Kompromiss zwischen einem großen schnellen Index und einem kleinen parallelen Brute-Force-Index ermöglicht es Loki, die Kosten des Systems zu kontrollieren. Es lässt sich je nach Bedarf flexibel konfigurieren und erweitern.

Der Loki-Stack besteht aus drei Komponenten: Promtail, Loki, Grafana. Promtail sammelt Protokolle, verarbeitet sie und sendet sie an Loki. Loki behält sie. Und Grafana kann Daten von Loki anfordern und zeigen. Im Allgemeinen kann Loki nicht nur zum Speichern und Durchsuchen von Protokollen verwendet werden. Der gesamte Stack bietet großartige Möglichkeiten für die Verarbeitung und Analyse eingehender Daten im Prometheus-Stil.
Eine Beschreibung des Installationsprozesses finden Sie hier hier.

Protokollsuche

Sie können die Protokolle in einer speziellen Schnittstelle Grafana – Explorer durchsuchen. Die Abfragen verwenden die LogQL-Sprache, die dem von Prometheus verwendeten PromQL sehr ähnlich ist. Im Prinzip kann man es sich als verteiltes grep vorstellen.

Die Suchoberfläche sieht folgendermaßen aus:

Die Abfrage selbst besteht aus zwei Teilen: Selektor und Filter. „Selektor“ ist eine Suche nach indizierten Metadaten (Beschriftungen), die Protokollen zugewiesen sind, und „Filter“ ist eine Suchzeichenfolge oder ein regulärer Ausdruck, der durch den Selektor definierte Datensätze herausfiltert. Im gegebenen Beispiel: In geschweiften Klammern – der Selektor, alles danach – der Filter.

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

Aufgrund der Funktionsweise von Loki können Sie keine Abfragen ohne Selektor durchführen, Beschriftungen können jedoch beliebig generisch gestaltet werden.

Der Selektor ist der Schlüsselwert des Werts in geschweiften Klammern. Sie können Selektoren kombinieren und unterschiedliche Suchbedingungen angeben, indem Sie die Operatoren =, != oder reguläre Ausdrücke verwenden:

{instance=~"kafka-[23]",name!="kafka-dev"} 
// Найдёт логи с лейблом instance, имеющие значение kafka-2, kafka-3, и исключит dev 

Ein Filter ist ein Text oder ein regulärer Ausdruck, der alle vom Selektor empfangenen Daten herausfiltert.

Im Metrikmodus ist es möglich, Ad-hoc-Grafiken basierend auf den empfangenen Daten zu erhalten. Sie können beispielsweise die Häufigkeit des Auftretens eines Eintrags in den Nginx-Protokollen ermitteln, der die Indexzeichenfolge enthält:

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

Protokollanalyse

Es gibt verschiedene Möglichkeiten, Protokolle zu sammeln:

• Mit Hilfe von Promtail, einer Standardkomponente des Stapels zum Sammeln von Protokollen.
• Direkt aus dem Docker-Container mit Loki Docker-Protokollierungstreiber.
• Verwenden Sie Fluentd oder Fluent Bit, die Daten an Loki senden können. Im Gegensatz zu Promtail verfügen sie über vorgefertigte Parser für fast jede Art von Protokoll und können auch mehrzeilige Protokolle verarbeiten.

Normalerweise wird Promtail zum Parsen verwendet. Es bewirkt drei Dinge:

• Findet Datenquellen.
• Befestigen Sie Etiketten daran.
• Sendet Daten an Loki.

Derzeit kann Promtail Protokolle aus lokalen Dateien und aus dem Systemd-Journal lesen. Es muss auf jedem Computer installiert werden, von dem Protokolle erfasst werden.

Es gibt eine Integration mit Kubernetes: Promtail ermittelt automatisch den Status des Clusters über die Kubernetes-REST-API, sammelt Protokolle von einem Knoten, Dienst oder Pod und veröffentlicht sofort Labels basierend auf Metadaten von Kubernetes (Pod-Name, Dateiname usw.).

Sie können mit Pipeline auch Etiketten basierend auf Daten aus dem Protokoll anhängen. Pipeline Promtail kann aus vier Arten von Phasen bestehen. Weitere Details - in amtliche Dokumentation, einige Nuancen fallen mir sofort auf.

1. Parsing-Stufen. Dies ist die Phase von RegEx und JSON. In dieser Phase extrahieren wir Daten aus den Protokollen in die sogenannte extrahierte Karte. Sie können aus JSON extrahieren, indem Sie einfach die benötigten Felder in die extrahierte Karte kopieren oder indem Sie reguläre Ausdrücke (RegEx) verwenden, bei denen benannte Gruppen in die extrahierte Karte „abgebildet“ werden. Die extrahierte Karte ist ein Schlüssel-Wert-Speicher, wobei Schlüssel der Name des Felds und Wert sein Wert aus den Protokollen ist.
2. Stufen transformieren. In dieser Phase gibt es zwei Optionen: „Transformieren“, wo wir die Transformationsregeln festlegen, und „Quelle“ – die Datenquelle für die Transformation aus der extrahierten Karte. Wenn in der extrahierten Karte kein solches Feld vorhanden ist, wird es erstellt. Somit ist es möglich, Beschriftungen zu erstellen, die nicht auf der extrahierten Karte basieren. In diesem Stadium können wir die Daten in der extrahierten Karte mit einem ziemlich leistungsstarken Tool manipulieren Golang-Vorlage. Darüber hinaus müssen wir bedenken, dass die extrahierte Karte beim Parsen vollständig geladen wird, was es beispielsweise ermöglicht, den darin enthaltenen Wert zu überprüfen: „{{if .tag}Tag-Wert existiert{End}}“. Die Vorlage unterstützt Bedingungen, Schleifen und einige Zeichenfolgenfunktionen wie Ersetzen und Trimmen.
3. Aktionsphasen. In diesem Stadium können Sie mit dem extrahierten Inhalt etwas anfangen:
   • Erstellen Sie aus den extrahierten Daten ein Etikett, das von Loki indiziert wird.
   • Ändern oder legen Sie die Ereigniszeit im Protokoll fest.
   • Ändern Sie die Daten (Protokolltext), die an Loki gehen.
   • Erstellen Sie Metriken.
4. Filterstufen. Die Match-Phase, in der wir Datensätze, die wir nicht benötigen, entweder an /dev/null senden oder sie zur weiteren Verarbeitung senden können.

Am Beispiel der Verarbeitung gewöhnlicher Nginx-Protokolle zeige ich, wie Sie Protokolle mit Promtail analysieren können.

Für den Test nehmen wir ein modifiziertes Nginx-Image jwilder/nginx-proxy:alpine als nginx-proxy und einen kleinen Daemon, der sich selbst über HTTP abfragen kann. Der Daemon verfügt über mehrere Endpunkte, an die er Antworten unterschiedlicher Größe, mit unterschiedlichem HTTP-Status und mit unterschiedlichen Verzögerungen geben kann.

Wir werden Protokolle von Docker-Containern sammeln, die sich im Pfad /var/lib/docker/containers/ befinden. / -json.log

In docker-compose.yml richten wir Promtail ein 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 den Pfad zu den Protokollen zu promtail.yml hinzu (es gibt eine „Docker“-Option in der Konfiguration, die das Gleiche in einer Zeile tut, aber es wäre nicht so offensichtlich):

scrape_configs:
 - job_name: containers

   static_configs:
       labels:
         job: containerlogs
         __path__: /var/lib/docker/containers/*/*log  # for linux only

Wenn diese Konfiguration aktiviert ist, empfängt Loki Protokolle von allen Containern. Um dies zu vermeiden, ändern wir die Test-Nginx-Einstellungen in docker-compose.yml – fügen Sie die Protokollierung zum Tag-Feld hinzu:

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

Bearbeiten Sie promtail.yml und richten Sie die Pipeline ein. Die Protokolle lauten wie folgt:

{"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-Stufen:

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

Wir extrahieren die Felder stream, attrs und attrs.tag (falls vorhanden) aus dem eingehenden JSON und fügen sie in die extrahierte Karte ein.

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

Wenn es möglich war, das Tag-Feld in die extrahierte Karte einzufügen, extrahieren wir mithilfe des regulären Ausdrucks die Namen des Bildes und des Containers.

 - labels:
     image_name:
     container_name:

Wir vergeben Labels. 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, für die die Bezeichnungen Bildname und Containername nicht festgelegt sind.

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

Für alle Protokolle, deren Bildname gleich nginx.promtail.test ist, extrahieren wir das Protokollfeld aus dem Quellprotokoll und fügen es mit dem Zeilenschlüssel in die extrahierte Karte ein.

  - regex:
         # suppress forego colors
         expression: .+nginx.+|.+[0m(?P<virtual_host>[a-z_.-]+) +(?P<nginxlog>.+)
         source: logrow

Wir löschen die Eingabezeichenfolge mit regulären Ausdrücken und ziehen den virtuellen Nginx-Host und die Nginx-Protokollzeile heraus.

     - regex:
         source: nginxlog
         expression: ^(?P<ip>[w.]+) - (?P<user>[^ ]*) [(?P<timestamp>[^ ]+).*] "(?P<method>[^ ]*) (?P<request_url>[^ ]*) (?P<request_http_protocol>[^ ]*)" (?P<status>[d]+) (?P<bytes_out>[d]+) "(?P<http_referer>[^"]*)" "(?P<user_agent>[^"]*)"( "(?P<response_time>[d.]+)")?

Analysieren Sie das Nginx-Protokoll mit regulären Ausdrücken.

    - regex:
           source: request_url
           expression: ^.+.(?P<static_type>jpg|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<photo>[^/?.]+).*$
       - regex:
           source: request_url
           expression: ^/api/(?P<api_request>[^/?.]+).*$

Analysieren Sie request_url. Mit Hilfe von Regexp ermitteln wir den Zweck der Anfrage: zur Statik, zu Fotos, zur API und setzen den entsprechenden Schlüssel in der extrahierten Karte.

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

Mithilfe von Bedingungsoperatoren in Template überprüfen wir die installierten Felder in der extrahierten Karte und legen die erforderlichen Werte für das Feld „request_type“ fest: Foto, statisch, API. Weisen Sie andere zu, wenn dies fehlschlägt. Jetzt enthält request_type den Anfragetyp.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

Wir legen die Bezeichnungen api_request, virtual_host, request_type und status (HTTP-Status) basierend auf dem fest, was wir in die extrahierte Karte einfügen konnten.

       - output:
           source: nginx_log_row

Ausgabe ändern. Nun geht das bereinigte Nginx-Protokoll aus der extrahierten Karte an Loki.

Nachdem Sie die obige Konfiguration ausgeführt haben, können Sie sehen, dass jeder Eintrag basierend auf den Daten aus dem Protokoll beschriftet ist.

Bedenken Sie, dass das Extrahieren von Etiketten mit einer großen Anzahl von Werten (Kardinalität) Loki erheblich verlangsamen kann. Das heißt, Sie sollten beispielsweise nicht user_id in den Index einfügen. Lesen Sie mehr dazu im ArtikelWie Labels in Loki Protokollabfragen schneller und einfacher machen können". Dies bedeutet jedoch nicht, dass Sie ohne Indizes nicht nach user_id suchen können. Bei der Suche müssen Filter verwendet werden („nach Daten greifen“), und der Index fungiert hier als Stream-Identifikator.

Protokollvisualisierung

Loki kann mithilfe von LogQL als Datenquelle für Grafana-Diagramme fungieren. Die folgenden Funktionen werden unterstützt:

• Rate – Anzahl der Datensätze pro Sekunde;
• count über die Zeit – die Anzahl der Datensätze im angegebenen Bereich.

Es gibt auch Aggregationsfunktionen Sum, Avg und andere. Sie können recht komplexe Diagramme erstellen, beispielsweise ein Diagramm der Anzahl von HTTP-Fehlern:

Die Standarddatenquelle von Loki ist etwas weniger funktional als die Prometheus-Datenquelle (Sie können beispielsweise die Legende nicht ändern), aber Loki kann als Quelle vom Typ Prometheus verbunden werden. Ich bin mir nicht sicher, ob es sich hierbei um dokumentiertes Verhalten handelt, aber nach der Antwort der Entwickler zu urteilen:Wie konfiguriere ich Loki als Prometheus-Datenquelle? · Ausgabe Nr. 1222 · grafana/loki“, zum Beispiel ist es völlig legal und Loki ist vollständig mit PromQL kompatibel.

Fügen Sie Loki als Datenquelle mit dem Typ Prometheus hinzu und hängen Sie die URL /loki an:

Und Sie können Diagramme erstellen, als würden wir mit Metriken von Prometheus arbeiten:

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

Metriken

Loki bietet die Möglichkeit, numerische Metriken aus Protokollen zu extrahieren und an Prometheus zu senden. Das Nginx-Protokoll enthält beispielsweise die Anzahl der Bytes pro Antwort und mit einer bestimmten Modifikation des Standardprotokollformats auch 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 promtail.yml einen weiteren Abschnitt hinzu:

- match:
   selector: '{request_type="api"}'
   stages:
     - metrics:
         http_nginx_response_time:
           type: Histogram
           description: "response time 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: "response bytes sum"
           source: bytes_out
           config:
             action: add
         http_nginx_response_bytes_count:
           type: Counter
           description: "response bytes count"
           source: bytes_out
           config:
             action: inc

Mit dieser Option können Sie Metriken basierend auf Daten aus der extrahierten Karte definieren und aktualisieren. Diese Metriken werden nicht an Loki gesendet – sie erscheinen im Promtail /metrics-Endpunkt. Prometheus muss für den Empfang von Daten aus dieser Phase konfiguriert sein. Im obigen Beispiel erfassen wir für request_type="api" eine Histogrammmetrik. Mit dieser Art von Metriken ist es praktisch, Perzentile zu erhalten. Für Statistiken und Fotos erfassen wir die Summe der Bytes und die Anzahl der Zeilen, in denen wir Bytes empfangen haben, um den Durchschnitt zu berechnen.

Erfahren Sie mehr über Metriken hier.

Öffnen Sie einen Port auf Promtail:

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

Wir stellen sicher, dass die Metriken mit dem Präfix promtail_custom angezeigt werden:

Prometheus einrichten. Stellenangebot hinzufügen:

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

Und zeichne ein Diagramm:

So können Sie beispielsweise die vier langsamsten Anfragen herausfinden. Sie können auch die Überwachung dieser Metriken konfigurieren.

Skalierung

Loki kann sowohl im Single-Binary-Modus als auch im Shard-Modus (horizontal skalierbarer Modus) sein. Im zweiten Fall können Daten in der Cloud gespeichert werden, wobei die Blöcke und der Index separat gespeichert werden. In Version 1.5 ist die Möglichkeit zur Speicherung an einem Ort implementiert, die Verwendung in der Produktion wird jedoch noch nicht empfohlen.

Chunks können in S3-kompatiblem Speicher gespeichert werden und horizontal skalierbare Datenbanken können zum Speichern von Indizes verwendet werden: Cassandra, BigTable oder DynamoDB. Andere Teile von Loki – Distributors (zum Schreiben) und Querier (für Abfragen) – sind zustandslos und werden ebenfalls horizontal skaliert.

Auf der DevOpsDays Vancouver 2019-Konferenz gab einer der Teilnehmer Callum Styan bekannt, dass sein Projekt mit Loki Petabytes an Protokollen mit einem Index von weniger als 1 % der Gesamtgröße hat: „Wie Loki Metriken und Protokolle korreliert – und Ihnen Geld spart".

Vergleich von Loki und ELK

Indexgröße

Um die resultierende Indexgröße zu testen, habe ich Protokolle aus dem Nginx-Container entnommen, für den die Pipeline oben konfiguriert wurde. Die Protokolldatei enthielt 406 Zeilen mit einem Gesamtvolumen von 624 MB. Protokolle wurden innerhalb einer Stunde generiert, etwa 109 Datensätze pro Sekunde.

Ein Beispiel für zwei Zeilen aus dem Protokoll:

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

Im Fall von Loki ergab dies etwa 128 KB Index und etwa 3,8 MB Daten in Blöcken. Es ist erwähnenswert, dass das Protokoll künstlich erstellt wurde und keine große Datenvielfalt enthielt. Ein einfaches gzip auf dem ursprünglichen Docker-JSON-Protokoll mit Daten ergab eine Komprimierung von 95,4 %, und wenn man bedenkt, dass nur das bereinigte Nginx-Protokoll an Loki selbst gesendet wurde, ist die Komprimierung auf 4 MB verständlich. Die Gesamtzahl der eindeutigen Werte für Loki-Labels betrug 35, was die geringe Größe des Index erklärt. Für ELK wurde das Protokoll ebenfalls gelöscht. Somit komprimierte Loki die Originaldaten um 96 % und ELK um 70 %.

Speicherverbrauch

Wenn wir den gesamten Stapel von Prometheus und ELK vergleichen, dann „frisst“ Loki um ein Vielfaches weniger. Es ist klar, dass der Go-Dienst weniger verbraucht als der Java-Dienst, und ein Vergleich der Größe der Heap-Elasticsearch-JVM und des zugewiesenen Speichers für Loki ist falsch, aber dennoch ist es erwähnenswert, dass Loki viel weniger Speicher verbraucht. Der CPU-Vorteil ist nicht so offensichtlich, aber er ist vorhanden.

Geschwindigkeit

Loki „verschlingt“ Protokolle schneller. Die Geschwindigkeit hängt von vielen Faktoren ab – von der Art der Protokolle, wie anspruchsvoll wir sie analysieren, vom Netzwerk, von der Festplatte usw. – aber sie ist definitiv höher als die von ELK (in meinem Test etwa das Zweifache). Dies erklärt sich aus der Tatsache, dass Loki deutlich weniger Daten in den Index einfügt und dementsprechend weniger Zeit für die Indizierung aufwendet. In diesem Fall ist die Situation bei der Suchgeschwindigkeit umgekehrt: Loki wird bei Daten größer als ein paar Gigabyte merklich langsamer, während bei ELK die Suchgeschwindigkeit nicht von der Datengröße abhängt.

Protokollsuche

Loki ist ELK in Bezug auf die Protokollsuchfunktionen deutlich unterlegen. Grep mit regulären Ausdrücken ist eine starke Sache, aber einer Datenbank für Erwachsene unterlegen. Das Fehlen von Bereichsabfragen, die Aggregation nur nach Labels, die Unfähigkeit, ohne Labels zu suchen – all das schränkt uns bei der Suche nach interessanten Informationen in Loki ein. Dies bedeutet nicht, dass mit Loki nichts gefunden werden kann, aber es definiert den Ablauf der Arbeit mit Protokollen, wenn Sie zuerst ein Problem in Prometheus-Diagrammen finden und dann anhand dieser Beschriftungen in den Protokollen nach dem suchen, was passiert ist.

Schnittstelle

Zunächst einmal ist es wunderschön (tut mir leid, ich konnte nicht widerstehen). Grafana hat eine gut aussehende Benutzeroberfläche, aber Kibana ist viel funktionaler.

Loki Vor- und Nachteile

Von den Pluspunkten ist anzumerken, dass Loki in Prometheus integriert ist bzw. wir sofort Metriken und Benachrichtigungen erhalten. Es ist praktisch, Protokolle zu sammeln und mit Kubernetes-Pods zu speichern, da es über eine von Prometheus geerbte Serviceerkennung verfügt und automatisch Labels anfügt.

Von den Minuspunkten - schlechte Dokumentation. Einige Dinge, wie die Funktionen und Fähigkeiten von Promtail, habe ich erst beim Studium des Codes entdeckt, die Vorteile von Open Source. Ein weiterer Nachteil sind die schwachen Parsing-Fähigkeiten. Loki kann beispielsweise keine mehrzeiligen Protokolle analysieren. Zu den Nachteilen gehört auch die Tatsache, dass es sich bei Loki um eine relativ junge Technologie handelt (Release 1.0 erfolgte im November 2019).

Abschluss

Loki ist eine zu 100 % interessante Technologie, die für kleine und mittlere Projekte geeignet ist und es Ihnen ermöglicht, viele Probleme der Protokollaggregation, Protokollsuche, Überwachung und Analyse von Protokollen zu lösen.

Wir nutzen Loki bei Badoo nicht, da wir einen ELK-Stack haben, der zu uns passt und der im Laufe der Jahre mit diversen Individuallösungen überwuchert wurde. Der Stolperstein ist für uns die Suche in den Protokollen. Bei fast 100 GB Protokollen pro Tag ist es für uns wichtig, alles und noch etwas mehr zu finden und es schnell zu erledigen. Für die Darstellung und Überwachung nutzen wir andere Lösungen, die auf unsere Bedürfnisse zugeschnitten und miteinander integriert sind. Der Loki-Stack hat greifbare Vorteile, aber er wird uns nicht mehr bringen, als wir haben, und seine Vorteile werden die Kosten der Migration nicht gerade überwiegen.

Und obwohl sich nach der Recherche herausstellte, dass wir Loki nicht verwenden können, hoffen wir, dass Ihnen dieser Beitrag bei der Auswahl hilft.

Das Repository mit dem im Artikel verwendeten Code befindet sich hier.

Source: habr.com