Wer einmal die undankbare Aufgabe hatte, einen ELK Stack stabil zum Laufen zu bringen, wird Tränen der Hoffnung in den Augen gehabt haben, wenn er zum ersten Mal von der Kombination Loki, Promtail und Grafana (PLG) hörte.

Loki ist das Log-Aggregationssystem von den Machern von Grafana, die sich hier sehr von Prometheus haben inspirierenlassen. Es verspricht, horizontal skalierbar, kosteneffektiv und einfach bedienbar zu sein. Gemeinsam mit Loki wird oft Promtail für das Einsammeln von Logs verwendet. Als Frontend dient hier natürlich das bewährte Grafana.

ELK steht für die die Open-Source-Projekte Elasticsearch, Kibana und Logstash. Anstatt Logstash lassen sich für das Sammeln von Logs aber auch z.B. fluentd und filebeat verwenden. Der Einfachheit spreche ich aber weiter von einem ELK Stack, auch wenn es streng genommen auch EFK heißen könnte. Auch Loki unterstützt nicht nur Promtail, sondern auch alle gängigen Log Sammler. Elasticsearch selbst ist mächtig und das nicht nur für das Sammeln von Logs. Zu Recht wird es nicht als Datenbank, sondern schon als Suchmaschine bezeichnet.

In der Praxis jedoch merkt man dem ELK Stack schnell an, dass es ursprünglich nicht für die Cloud gemacht wurde. Unabhängig davon, ob nun etwa logstash oder fluentd eingesetzt werden soll – die Einstiegshürde ist erheblich. Die Tools und die Konfiguration, die hierfür notwendig sind, wirken auf mich alle klobig und wenig einsteigerfreundlich im Vergleich zu dem erfreulichen Bedienkomfort von Kibana selbst. Fairerweise muss ich zugeben, dass hier in den letzten Jahren auch immer wieder etwas verbessert wurde. So kann man zum Beispiel dank Kibanas Index Lifecycle Management (ILM) nun auf den Elasticsearch Curator verzichten.

Aber dennoch ist es keine Aufgabe für nur einen Nachmittag, seinen ersten ELK Stack zum Laufen zu bringen. Und meine Erfahrung zeigt, dass ein ELK Stack auch im Anschluss immer wieder Arbeit macht. Hinzu kommt der enorme Ressourcenbedarf, der dem Einsatz in kleineren Projekten oft im Weg steht.

Kommerzielle Anbieter wie Datadog und Splunk scheinen zwar den Berichten nach ihr Versprechen zu halten, eine benutzerfreundliche Alternative zu sein. Aber vielleicht eröffnet sich nun mit Loki und Promtrail auch eine kostenlose Alternative zu ELK.

Die Architektur von Loki

Loki selbst ist keine Datenbank. Denn Logs werden von Loki in Chunks (die Rohdaten) aufgeteilt und indiziert. Die so entstandenen Indexe und Chunks werden dabei in zwei separaten Datenbanken gespeichert. Hierfür unterstützt Loki eine Vielzahl von Datenbanken, z.B. Cassandra, BigTable und DynamoDB für die Indices und z.B. (wieder) Cassandra, S3 und GCS für die Chunks. Anders als bei Elasticsearch wird aber nicht der gesamte Text indiziert, sondern nur spezifische Labels. Das ermöglicht erst den geringeren Ressourcenbedarf von Loki.

Eine Query, die nicht mit existierenden Labels arbeitet, muss aber daher über alle Daten iterieren. Hinzu kommt, dass Labels eine geringe Kardinalität aufweisen sollten. Dinge wie eine IP-Adresse oder eine User-ID haben hier nichts zu suchen.

In der Praxis ist das Iterieren über alle Daten wie mit Grep aber oft schnell genug. Als Basis von Visualisierungen in Dashboards eignen sich solche Queries aber natürlich schlecht. Architektonisch haben die Macher von Loki deshalb einen anderen Weg als ihre Inspiration Prometheus gewählt. Loki basiert auf Cortex, welches versucht, eine horizontal skalierbare Alternative zu Prometheus zu sein. Denn bekanntlich lässt sich Prometheus nicht skalieren. Das Problem wird in der Praxis oft durch das Anlegen mehrerer Instanzen von Prometheus umgangen. Oder mit Einsatz von Cortex oder Thanos.

Logeinträge werden zunächst von sogenannten Distributoren angenommen. Diese verteilen die Daten dann auf Ingesters. welche die Aufgabe haben, die Indexe zu pflegen und die Logs in Paketen (Chunks) zu sammeln und abzuspeichern.

Abbildung-1-Loki-Architektur
Abbildung 1: Loki Architektur (Quelle: grafana.com)

 

Der lesende Zugriff hingegen wird ausschließlich über sogenannte Queriers abgewickelt. Die Queriers arbeiten dabei direkt mit den Daten aus den Chunks und Indices. Nur was noch nicht in diesen Datenbanken gespeichert wurde, wird direkt bei den Ingesters abgefragt. Martin Fowler hat sicher seine wahre Freude über diese Umsetzung von Command Query Responsibility Segregation (CQRS).

Das Deployment von Loki

Die Installation von Loki mit dem Paketmanager Helm gestaltet sich unerwartet einfach. Das Loki-Chart Repository wird hinzugefügt:

helm repo add loki https://grafana.github.io/loki/charts && helm repo update

Und installiert:

helm upgrade --install loki --namespace=loki loki/loki-stack

Das Helm-Chart bietet uns auch Konfiguration für die alternativen Logsammler wie Logstash, Fluent-bit oder Filebeat. Default ist das hauseigene Promtail. Schön ist dabei, dass Promtail alle Logdaten dann auch direkt mit Kubernetes Labels versieht, wie man es schon von Prometheus kennt.

Ist alles im Status „running“ muss man je nach Konfiguration von Grafana noch Loki als Datas Source hinzuzufügen. Hat man hingegen das herrliche Dynamic Configuration Sidecar für Grafana aktiviert, wird die im Helm-Chart beinhaltete ConfigMap automatisch berücksichtigt.

Konfiguration von Loki als Data Source in Grafana
Abbildung 2: Konfiguration von Loki als Data Source in Grafana

Damit hat man in nicht einmal 5 Minuten ein funktionierendes Log Aggregation erstellt. Als nächstes gilt es dann nur noch auf Explore zu klicken, und schon wird man von einem LogQL Cheatsheet begrüßt und kann die ersten Queries abfeuern oder sich ein Dashboard zusammenklicken. Einfacher könnte es nicht sein.

Einfacher Graph über die Anzahl der Logmessages durch Loki  im zeitlichen Verlauf
Abbildung 3: Einfacher Graph über die Anzahl der Logmessages durch Loki  im zeitlichen Verlauf

Filtern, Akkumulieren, Aufsummieren, die wichtigsten Operatoren zum Erstellen von Panels funktionieren wie bekannt aus Kibana oder mit Prometheus.

Mein Fazit

Es ist also tatsächlich so, dass mit Loki die Einrichtung des Loggings nun niemanden mehr Angst machen muss. Für die alltägliche Arbeit lässt Loki kaum etwas zu wünschen übrig. Es ist auch horizontal skalierbar, auch wenn dies mit mehr Arbeit verbunden ist. Und seit kurzem bietet Loki auch Mehrbenutzerfähigkeit, ein Feature, welches Prometheus leider schmerzlich vermissen lässt.

Auch für die Überwachung des LPG Stacks selbst ist gesorgt. Loki Canary misst dazu unter anderem, wie lange es dauert, bis seine Logs abgeholt werden.

Einzig komplexe Anwendungsfälle, die die Volltextindizierung von Elasticsearch erfordern, können mit Loki nicht realisiert werden. In Kibana ist es möglich Graphen auf Basis von komplexen Suchanfragen zu realisieren. Solche Visualisierungen würden aber den LPG Stack schnell in die Knie zwingen. In der Praxis lässt sich so etwas meist auch anders realisieren, zum Beispiel, indem man maßgeschneiderte Metriken für Prometheus ausliefert.

Ich erwarte also zukünftig nicht, dass es viele Situationen geben wird, in denen ich den ELK Stack vermissen werde.


An dieser Stelle möchte ich mich bei Alexander Zimmermann bedanken für seine hilfreichen Anregungen und die konstruktive Kritik bei der Erstellung dieser Arbeit.

Jetzt teilen auf:

2 Comments

  1. Benni 16. Juni 2022 at 10:57 - Reply

    Danke für den interessanten Beitrag. Das Helm Chart ist leider DEPRECATED.

  2. Benni 16. Juni 2022 at 11:11 - Reply

    Neues Repository:

    „`
    helm repo add grafana https://grafana.github.io/helm-charts
    helm repo update
    helm upgrade loki -n loki grafana/loki-stack —install —create-namespace —set „grafana.enabled=true“
    „`
    Der Ingress für Grafana muss selbstständig erstellt werden:

    „`
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
    annotations:
    kubernetes.io/ingress.class: nginx
    name: loki-grafana
    spec:
    rules:
    – host: loki-grafana.MYDOMAIN.de
    http:
    paths:
    – backend:
    service:
    name: loki-grafana
    port:
    number: 80
    path: /
    pathType: Prefix
    „`

Jetzt kommentieren