Hallo, Habr-Bewohner! Im Vorfeld des Starts eines neuen Kurses haben wir für Sie eine interessante Übersetzung vorbereitet.
Dieser Artikel ist eine kurze Einführung in Loki. Das Projekt Loki und zielt darauf ab, Protokolle zentral zu sammeln (von Servern oder Containern).
Die Hauptquelle der Inspiration für Loki war mit der Idee, seine Ansätze für das Log-Management anzuwenden:
- Verwendung von Labels zur Datenspeicherung
- geringer Ressourcenverbrauch
Wir werden noch auf die Funktionsweisen von Prometheus zurückkommen und einige Beispiele für seine Verwendung im Kontext von Kubernetes anführen.
Ein paar Worte über Prometheus
Um vollständig zu verstehen, wie Loki funktioniert, ist es wichtig, einen Schritt zurückzutreten und sich ein wenig an Prometheus zu erinnern.
Eine der herausragenden Eigenschaften von Prometheus ist das Abrufen von Metriken aus den Sammlungspunkten (über Exporteure) und deren Speicherung in einer TSDB (Time Series Data Base, Datenbank für Zeitreihen) mit dem Hinzufügen von Metadaten in Form von Labels.
Warum ist das notwendig?
In letzter Zeit hat sich Prometheus als De-facto-Standard in der Welt der Container und von Kubernetes etabliert: Die Installation ist sehr einfach, und im Kubernetes-Cluster ist standardmäßig ein Endpunkt für Prometheus vorhanden. Prometheus kann auch Metriken aus Anwendungen abrufen, die in Containern bereitgestellt werden, während bestimmte Labels beibehalten werden. Daher ist die Überwachung von Anwendungen sehr leicht umzusetzen.
Leider gibt es für die Protokollverwaltung bisher keine „Plug-and-Play“-Lösung, und Sie müssen selbst eine Lösung finden:
- verwalteter Cloud-Service zur Zentralisierung von Protokollen (AWS, Azure oder Google)
- Überwachungsdienst „Monitoring as a Service“ (zum Beispiel Datadog)
- Erstellung Ihres eigenen Protokollsammlungsdienstes.
Für die dritte Option habe ich traditionell Elasticsearch verwendet, obwohl ich nicht immer zufrieden war (insbesondere aufgrund seiner Schwere und der schwierigen Konfiguration).
Loki wurde entwickelt, um die Implementierung gemäß den folgenden Prinzipien zu vereinfachen:
- einfach zu starten
- wenig Ressourcen zu konsumieren
- selbstständig ohne spezielle Wartung zu arbeiten
- als Ergänzung zu Prometheus zu dienen, um bei der Fehlersuche zu helfen
Diese Einfachheit wird jedoch durch einige Kompromisse erreicht. Einer davon besteht darin, keinen Inhalt zu indexieren. Daher ist die Textsuche nicht besonders effizient oder umfangreich und erlaubt keine statistischen Auswertungen des Textinhalts. Da Loki jedoch das Äquivalent von grep und eine Ergänzung zu Prometheus sein möchte, stellt dies keinen Nachteil dar.
Incident Investigation
Um besser zu verstehen, warum Loki keine Indizierung benötigt, lassen Sie uns auf die Methode der Vorfalluntersuchung zurückblicken, die die Entwickler von Loki verwendet haben:

1 Alert → 2 Dashboard → 3 Adhoc Query → 4 Log Aggregation → 5 Distributed Tracing → 6 Fix!
(1 Benachrichtigung → 2 Dashboard → 3 Adhoc-Abfrage → 4 Protokollaggregation → 5 Verteilte Nachverfolgung → 6 Behebung!)
Die Idee ist, dass wir eine Art Alert (Slack-Benachrichtigung, SMS usw.) erhalten und dann:
- die Grafana-Dashboards überprüfen
- die Metriken der Dienste ansehen (z. B. in Prometheus)
- die Protokolle einsehen (z. B. in Elasticsearch)
- möglicherweise einen Blick auf die verteilten Traces werfen (Jaeger, Zipkin usw.)
- und schließlich das ursprüngliche Problem beheben.
Hier, im Fall des Stacks Grafana + Prometheus + Elasticsearch + Zipkin, wird es erforderlich sein, vier verschiedene Werkzeuge zu verwenden. Um die Zeit zu verkürzen, wäre es sinnvoll, alle Schritte mit einem einzigen Werkzeug, Grafana, durchführen zu können. Es ist erwähnenswert, dass ein solcher Ansatz zur Datenanalyse in Grafana seit Version 6 umgesetzt ist. Somit ist es möglich, direkt auf die Prometheus-Daten aus Grafana zuzugreifen.

Der Explorer-Bildschirm ist zwischen Prometheus und Loki aufgeteilt.
Auf diesem Bildschirm können Protokolle in Loki, die mit den Metriken von Prometheus verbunden sind, im Splitscreen-Modus angezeigt werden. Seit Version 6.5 ermöglicht Grafana die Verarbeitung der Trace-ID in den Loki-Logeinträgen, um Links zu Ihren bevorzugten Werkzeugen für die verteilte Nachverfolgung (Jaeger) zu erstellen.
Lokaler Loki-Test
Der einfachste Weg, Loki lokal zu testen, besteht darin, docker-compose zu verwenden. Die docker-compose-Datei befindet sich im Loki-Repository. Sie können das Repository mit dem folgenden Befehl abrufen: git:
$ git clone https://github.com/grafana/loki.gitDann müssen Sie in das Produktionsverzeichnis wechseln:
$ cd productionAnschließend können Sie die neueste Version der Docker-Images abrufen:
$ docker-compose pullSchließlich wird Loki mit folgendem Befehl gestartet:
$ docker-compose upArchitektur von Loki
Hier ist ein kleines Diagramm zur Architektur von Loki:

Prinzipien der Architektur von Loki
Der Web-Client startet Anwendungen auf dem Server, Promtail sammelt Protokolle und sendet sie an Loki, der Web-Client sendet auch Metadaten an Loki. Loki aggregiert alles und überträgt es an Grafana.
Loki ist gestartet. Um die verfügbaren Komponenten anzuzeigen, führen Sie den folgenden Befehl aus:
$ docker psIm Falle einer neu installierten Docker-Umgebung sollte der Befehl folgendes Ergebnis zurückgeben:
IMAGE PORTS NAMES
grafana/promtail: production_promtail_1
grafana/grafana: m 0.0.0.0:3000->3000/tcp production_grafana_1
grafana/loki: late 80/tcp,0.0.0.0:3100... production_loki_1Wir sehen folgende Komponenten:
- Promtail: Agent, verantwortlich für die Zentralisierung von Protokollen
- Grafana: bekanntes Tool für Dashboards
- Loki: Daemon zur Zentralisierung von Daten
Im Rahmen einer klassischen Infrastruktur (z. B. auf virtuellen Maschinen) muss auf jeder Maschine der Promtail-Agent installiert sein. Grafana und Loki können auf einer Maschine installiert werden.
Deployment in Kubernetes
Die Installation der Loki-Komponenten in Kubernetes beinhaltet folgendes:
- daemonSet zur Bereitstellung des Promtail-Agenten auf jeder Maschine im Server-Cluster
- Bereitstellung (Deployment) von Loki
- und schließlich — Bereitstellung von Grafana.
Glücklicherweise ist Loki als Helm-Paket verfügbar, was die Bereitstellung erleichtert.
Installation über Helm
Helm sollte bereits auf Ihrem System installiert sein. Sie können es aus dem GitHub-Repository des Projekts herunterladen. Die Installation erfolgt durch Entpacken des entsprechenden Archivs für Ihre Architektur und Hinzufügen von Helm zu $PATH.
Hinweis: Die Version 3.0.0 von Helm wurde kürzlich veröffentlicht. Da es viele Änderungen gab, wird den Lesern empfohlen, etwas zu warten, bevor sie es verwenden..
Hinzufügen einer Quelle für Helm
Der erste Schritt besteht darin, das “loki”-Repository mit dem folgenden Befehl hinzuzufügen:
$ helm add loki https://grafana.github.io/loki/chartsNach diesem Schritt können Sie nach Paketen mit dem Namen “loki” suchen:
$ helm search lokiDas Ergebnis:
loki/loki 0.17.2 v0.4.0 Loki: wie Prometheus, aber für Logs.
loki/loki-stack 0.19.1 v0.4.0 Loki: wie Prometheus, aber für Logs.
loki/fluent-bit 0.0.2 v0.0.1 Verwendet das fluent-bit Loki Go-Plugin für...
loki/promtail 0.13.1 v0.4.0 Verantwortlich für das Sammeln von Logs und...Diese Pakete haben folgende Funktionen:
- Paket loki/loki entspricht nur dem Loki-Server
- Paket loki/fluent-bit ermöglicht Ihnen die Bereitstellung eines DaemonSets mit fluent-bit zum Sammeln von Logs anstelle von Promtail
- Paket loki/promtail enthält den Log-Datei-Sammlungsagenten
- Paket loki/loki-stack, ermöglicht es, Loki zusammen mit Promtail bereitzustellen.
Loki installieren
Um Loki in Kubernetes bereitzustellen, führen Sie den folgenden Befehl im Namensraum „monitoring“ aus:
$ helm upgrade --install loki loki/loki-stack --namespace monitoringUm die Speicherung auf der Festplatte zu aktivieren, fügen Sie das Argument hinzu --set loki.persistence.enabled=true:
$ helm upgrade --install loki loki/loki-stack
--namespace monitoring
--set loki.persistence.enabled=trueHinweis: Wenn Sie Grafana gleichzeitig bereitstellen möchten, fügen Sie das Argument hinzu
--set grafana.enabled=true
Wenn Sie diesen Befehl ausführen, sollten Sie folgende Ausgabe erhalten:
LETZTE BEREITSTELLUNG: Di, 19. Nov 2019 15:56:54
NAMESPACE: monitoring
STATUS: BEREITGESTELLT
RESSOURCEN:
==> v1/ClusterRole
NAME ALTER
loki-promtail-clusterrole 189d
…
HINWEISE:
Der Loki-Stack wurde in Ihrem Cluster bereitgestellt. Loki kann jetzt als Datenquelle in Grafana hinzugefügt werden.
Siehe <a href="http://docs.grafana.org/features/datasources/loki/">http://docs.grafana.org/features/datasources/loki/</a> für weitere Details.Schauen wir uns den Status der Pods im Namensraum „monitoring“ an, sehen wir, dass alles bereitgestellt ist:
$ kubectl -n monitoring get pods -l release=lokiDas Ergebnis:
NAME READY STATUS RESTARTS AGE
loki-0 1/1 Running 0 147m
loki-promtail-9zjvc 1/1 Running 0 3h25m
loki-promtail-f6brf 1/1 Running 0 11h
loki-promtail-hdcj7 1/1 Running 0 3h23m
loki-promtail-jbqhc 1/1 Running 0 11h
loki-promtail-mj642 1/1 Running 0 62m
loki-promtail-nm64g 1/1 Running 0 24mAlle Pods laufen. Jetzt ist es an der Zeit, einige Tests durchzuführen!
Verbindung zu Grafana
Um sich mit Grafana unter Kubernetes zu verbinden, müssen Sie einen Tunnel zu seinem Pod öffnen. Unten steht der Befehl zum Öffnen des Ports 3000 für den Grafana-Pod:
$ kubectl -n port-forward monitoring svc/loki-grafana 3000:80Ein weiterer wichtiger Punkt ist die Notwendigkeit, das Passwort des Grafana-Administrators zurückzusetzen. Das Passwort wird im Geheimen aufbewahrt. loki-grafana im Feld .data.admin-user im base64-Format.
Um es zurückzusetzen, führen Sie den folgenden Befehl aus:
$ kubectl -n monitoring get secret loki-grafana
--template '{{index .data "admin-password" | base64decode}}'; echoVerwenden Sie dieses Passwort zusammen mit dem Standard-Administratorkonto (admin).
Festlegung der Loki-Datenquelle in Grafana
Stellen Sie zunächst sicher, dass eine Loki-Datenquelle erstellt wurde (Konfiguration / Datenquelle).
Hier ein Beispiel:

Beispiel für die Konfiguration einer Loki-Datenquelle
Durch Klicken auf "Test" können Sie die Verbindung zu Loki überprüfen.
Anfragen an Loki stellen
Gehen Sie nun in Grafana zum Bereich „Erkunden“. Beim Empfang von Protokollen von Containern fügt Loki Metadaten aus Kubernetes hinzu. So wird es möglich, die Protokolle eines bestimmten Containers zu betrachten.
Zum Beispiel kann der folgende Befehl verwendet werden, um die Protokolle des Containers promtail auszuwählen: {container_name = "promtail"}.
Vergessen Sie hier auch nicht, die Datenquelle Loki auszuwählen.
Diese Anfrage gibt die Aktivitäten der Container in folgendem Format zurück:

Abfrageergebnis in Grafana
Hinzufügen zum Dashboard
Mit Grafana 6.4 können Sie Protokollinformationen direkt im Dashboard anzeigen. Dadurch kann der Benutzer schnell zwischen der Anzahl der Anfragen auf seiner Website und den Anwendungstraces wechseln.
Hier ist ein Beispiel-Dashboard, das diese Interaktion umsetzt:

Beispiel eines Dashboards mit Prometheus-Metriken und Loki-Logs
Die Zukunft von Loki
Ich begann, Loki im Mai/Juni mit Version 0.1 zu verwenden. Heute ist bereits Version 1, sogar 1.1 und 1.2 veröffentlicht worden.
Es muss anerkannt werden, dass Version 0.1 nicht stabil genug war. Aber 0.3 zeigte bereits echte Anzeichen von Reife, und die folgenden Versionen (0.4, dann 1.0) verstärkten diesen Eindruck nur noch.
Nach 1.0.0 gibt es keine Entschuldigung mehr, dieses großartige Tool nicht zu verwenden.
Zukünftige Verbesserungen sollten sich nicht auf Loki, sondern vielmehr auf die Integration mit dem hervorragenden Grafana konzentrieren. Tatsächlich gibt es in Grafana 6.4 bereits eine gute Integration für Dashboards.
Grafana 6.5, das kürzlich veröffentlicht wurde, verbessert diese Integration noch weiter, indem es den Inhalt der Logs im JSON-Format automatisch erkennt.
Im folgenden Video sehen Sie ein kleines Beispiel dieses Mechanismus:

Anzeige von Loki-Strings in Grafana
Es wird möglich, eines der JSON-Felder zu verwenden, z. B. für:
- Links zu einem externen Tool
- Filtern von Protokollinhalten
Sie können beispielsweise auf traceId klicken, um zu Zipkin oder Jaeger zu gelangen.
Traditionell erwarten wir Ihre Kommentare und laden Sie ein zu , in dem wir darüber sprechen, wie sich die DevOps-Branche im Jahr 2019 entwickelt hat und mögliche Entwicklungswege für 2020 diskutieren.
Quelle: habr.com
