Logging in Kubernetes: EFK vs. PLG

Logging in Kubernetes: EFK vs. PLG

Monitoring has become an essential component of evolving cloud solutions, especially as the complexity of distributed systems increases. It is crucial for understanding their behavior. Scalable tools are needed to collect data from all services — providing specialists with a unified interface for performance analysis, error demonstration, availability, and logging.

These tools must also be efficient and high-performing. In this article, we will explore two popular technology stacks: EFK (Elasticsearch) and PLG (Loki), examining their architectures and differences.

EFK Stack

You may have already heard of the widely known ELK or EFK. This stack consists of several distinct components: Elasticsearch (object storage), Logstash or FluentD (log collection and aggregation), and Kibana for visualization.

A typical workflow looks like this:

Logging in Kubernetes: EFK vs. PLG

Elasticsearch — ein verteiltes objektbasiertes Speicher- und Analyse-System mit Echtzeit-Suche. Die perfekte Lösung für teilweise strukturierte Daten wie Protokolle. Informationen werden im JSON-Format gespeichert, in Echtzeit indexiert und auf Cluster-Knoten verteilt. Dabei wird ein invertierter Index verwendet, der alle einzigartigen Worte und die entsprechenden Dokumente für die Volltextsuche enthält, die auf der Suchmaschine Apache Lucene basiert.

FluentD — ein Datenaggregator, der Daten bei ihrer Erfassung und Nutzung vereinheitlicht. Er zielt darauf ab, Daten so weit wie möglich im JSON-Format zu organisieren. Seine Architektur ist erweiterbar, und es stehen mehr als Hunderte von verschiedenen Erweiterungen, die von der Community unterstützt werden, für alle Lebenslagen zur Verfügung.

Kibana — ein Visualisierungstool für Elasticsearch mit verschiedenen zusätzlichen Funktionen, wie z.B. Zeitreihenanalysen, Diagrammen, maschinellem Lernen und mehr.

Architektur von Elasticsearch

Die Daten des Elasticsearch-Clusters werden über alle Knoten verteilt gespeichert. Der Cluster besteht aus mehreren Knoten, um die Verfügbarkeit und Stabilität zu verbessern. Jeder Knoten kann alle Rollen im Cluster ausführen, jedoch werden in groß angelegten, skalierbaren Implementierungen den Knoten normalerweise spezifische Aufgaben zugewiesen.

Typen von Clusterknoten:

  • Master-Knoten — verwaltet den Cluster, mindestens drei werden benötigt, wobei immer einer aktiv ist;
  • Daten-Knoten — speichert indizierte Daten und führt verschiedene Aufgaben mit ihnen aus;
  • Ingest-Knoten — organisiert Pipelines zur Datenumwandlung vor der Indizierung;
  • Koordinationsknoten — leitet Anfragen weiter, verringert die Suchverarbeitungsphase und koordiniert die Massendatenspeicherung;
  • Alarmknoten — führt Benachrichtigungsaufgaben aus;
  • Machine-Learning-Knoten — verarbeitet Machine-Learning-Aufgaben.

Im folgenden Diagramm ist dargestellt, wie die Daten für eine höhere Verfügbarkeit gespeichert und repliziert werden.

Logging in Kubernetes: EFK vs. PLG

Die Daten jeder Replik werden im invertierten Index gespeichert, das folgende Schema zeigt, wie dies geschieht:

Logging in Kubernetes: EFK vs. PLG

Installation von

Details können hier angesehen werden hier, ich werde das Helm-Chart verwenden:

$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elastics

PLG-Stack

Es ist nicht überraschend, wenn Sie dieses Akronym nicht erkennen, denn es ist besser bekannt als Grafana Loki. In jedem Fall gewinnt dieser Stack an Beliebtheit, da er durchdachte technische Lösungen anwendet. Möglicherweise haben Sie bereits von Grafana gehört, einem beliebten Visualisierungstool. Die Entwickler, inspiriert von Prometheus, haben Loki entworfen, ein horizontal skalierbares Hochleistungsaggregationssystem für Protokolle. Loki indiziert nur Metadaten, nicht jedoch die Protokolle selbst, was ihm ermöglicht, einfach in der Bedienung und kosteneffektiv zu sein.

Promtail – ein Agent, der Protokolle von dem Betriebssystem in den Loki-Cluster sendet. Grafana – ein Visualisierungstool, das auf Daten aus Loki basiert.

Logging in Kubernetes: EFK vs. PLG

Loki ist nach denselben Prinzipien aufgebaut wie Prometheus, weshalb es sich gut für die Speicherung und Analyse von Kubernetes-Protokollen eignet.

Architektur von Loki

Loki kann sowohl im Einzelprozess- als auch im Mehrprozessmodus betrieben werden, was horizontale Skalierung ermöglicht.

Logging in Kubernetes: EFK vs. PLG

Es kann sowohl als monolithische Anwendung als auch als Mikrodienst fungieren. Der Betrieb als ein einzelner Prozess kann für die lokale Entwicklung oder für kleinere Überwachungsaufgaben nützlich sein. Für industrielle Implementierungen und skalierbare Lasten wird die Verwendung der Mikrodienst-Variante empfohlen. Die Wege zum Schreiben und Lesen von Daten sind getrennt, sodass eine feine Anpassung und Skalierung nach Bedarf möglich ist.

Lassen Sie uns die Architektur des Log-Sammelsystems ohne Details betrachten:

Logging in Kubernetes: EFK vs. PLG

Hier finden Sie die Beschreibung (Mikrodienstarchitektur):

Logging in Kubernetes: EFK vs. PLG

Bestandteile:

Promtail — Agent, der auf Knoten installiert wird (als Sammlung von Diensten), er erfasst Protokolle aus Aufgaben und ruft die API von Kubernetes ab, um die Metadaten zu erhalten, mit denen die Protokolle gekennzeichnet werden. Anschließend sendet er das Protokoll an den Hauptdienst Loki. Für die Zuordnung der Metadaten gelten die gleichen Regeln für die Kennzeichnung wie in Prometheus.

Distributor — ein Verteilungsdienst, der als Puffer fungiert. Er verarbeitet Millionen von Datensätzen, indem er eingehende Daten paketiert und sie blockweise komprimiert, während sie eintreffen. Gleichzeitig arbeiten mehrere Datenempfänger, jedoch müssen die Protokolle, die zu einem einzelnen eingehenden Datenstrom gehören, nur in einem von ihnen für alle seine Blöcke vorhanden sein. Dies ist als Ring von Empfängern und sequentielle Hashing-Organisation strukturiert. Zur Gewährleistung von Fehlertoleranz und Redundanz geschieht dies n-mal (3, wenn nicht konfiguriert).

Ingester — ein Empfangsdienst. Die Datenblöcke kommen komprimiert mit hinzugefügten Protokollen. Sobald ein Block eine ausreichende Größe erreicht hat, wird der Block in die Datenbank zurückgeschrieben. Die Metadaten gehen in den Index, während die Daten des Blocks mit Protokoll in Chunks (in der Regel ein Objektspeicher) gelangen. Nach dem Zurückschreiben erstellt der Empfänger einen neuen Block, in den neue Einträge hinzugefügt werden.

Logging in Kubernetes: EFK vs. PLG

Index — Datenbank, DynamoDB, Cassandra, Google BigTable und mehr.

Chunks — Blöcke von Protokollen in komprimierter Form, die normalerweise in einem Objektspeicher wie S3 gespeichert werden.

Querier — ein Leseweg, der die gesamte Arbeit im Hintergrund übernimmt. Er analysiert Zeitspannen und Marker, sucht dann im Index nach Übereinstimmungen. Anschließend liest er Datenblöcke und filtert sie, um ein Ergebnis zu erzielen.

Und jetzt schauen wir uns alles in Aktion an.

Installation von

Für die Installation in Kubernetes ist es am einfachsten, helm zu verwenden. Wir gehen davon aus, dass Sie es bereits installiert und konfiguriert haben (und die dritte Version! Anm. der Übersetzer)

Fügen Sie das Repository hinzu und installieren Sie den Stack.

$ helm repo add loki https://grafana.github.io/loki/charts
$ helm repo update
$ helm upgrade --install loki loki/loki-stack --set grafana.enabled=true,prometheus.enabled=true,prometheus.alertmanager.persistentVolume.enabled=false,prometheus.server.persistentVolume.enabled=false

Unten sehen Sie ein Beispiel für ein Dashboard, das Daten aus Prometheus für Metriken von Etcd und Loki für die Protokolle von Etcd-Pods anzeigt.

Logging in Kubernetes: EFK vs. PLG

Jetzt lassen Sie uns die Architektur beider Systeme diskutieren und ihre Funktionen miteinander vergleichen.

Der Vergleich

Abfragesprache

In Elasticsearch wird die Query DSL und die Lucene-Abfragesprache verwendet, die die Durchführung von Volltextsuche ermöglichen. Dies ist eine etablierte leistungsstarke Suchmaschine mit breiter Unterstützung für Operatoren. Damit können Sie kontextbasierte Suchen durchführen und nach Relevanz sortieren.

Auf der anderen Seite des Rings steht LogQL, das in Loki verwendet wird, der Nachfolger von PromQL (Prometheus-Abfragesprache). Es nutzt Protokoll-Tags zur Filterung und Abfrage von Protokolldaten. Es gibt die Möglichkeit, einige Operatoren und Arithmetik zu verwenden, wie beschrieben. hier, aber in Bezug auf Funktionen bleibt es hinter der Elastic-Sprache zurück.

Da Abfragen in Loki mit Tags verbunden sind, lassen sie sich leicht mit Metriken verknüpfen, was eine einfachere Organisation des operativen Monitorings ermöglicht.

Skalierbarkeit

Beide Stacks sind horizontal skalierbar, aber mit Loki ist es einfacher, da es separate Lese- und Schreibpfade für Daten hat und eine Mikroservice-Architektur nutzt. Loki kann auf Ihre Anforderungen zugeschnitten werden und kann für sehr große Datenmengen von Protokollen verwendet werden.

Multitenancy

Die Multitenancy des Clusters ist ein gemeinsames Thema zur Senkung der OPEX; beide Stacks bieten Multitenancy. Für Elasticsearch gibt es mehrere Methoden zur Trennung von Kunden: einen separaten Index für jeden Kunden, clientbasierte Routen, eindeutige Kundenfelder, Suchfilter. In Loki erfolgt dies поддержка über den HTTP-Header X-Scope-OrgID.

Kosten

Loki ist wirtschaftlich sehr effizient, da er keine Datenindizierung, sondern nur die Indizierung von Metadaten durchführt. Dadurch wird erreicht, dass Speicherplatz und Arbeitsspeicher (Cache) eingespart werden, da objektbasierter Speicher kostengünstiger ist als blockbasierter Speicher, der in Elasticsearch-Clustern verwendet wird.

Fazit

Der EFK-Stack kann für verschiedene Zwecke eingesetzt werden und bietet dank Kibana eine flexible und multifunktionale Benutzeroberfläche für Analytics, Visualisierung und Abfragen. Er kann außerdem mit maschinellen Lernfunktionen erweitert werden.

Der Loki-Stack ist in der Kubernetes-Umgebung aufgrund der Metadatenentdeckung nützlich. Es ist einfach, Daten für die zeitbasierte Überwachung in Grafana und Protokollen abzugleichen.

Wenn es um die Kosten und die langfristige Speicherung von Protokollen geht, ist Loki eine hervorragende Wahl für den Einstieg in Cloud-Lösungen.

Es gibt auf dem Markt weitere Alternativen – einige könnten besser für Sie geeignet sein. Zum Beispiel gibt es für GKE die Integration von Stackdriver, die eine ausgezeichnete Überwachungslösung bietet. Diese haben wir in unserer Analyse in diesem Artikel nicht berücksichtigt.

Links:

Der Artikel wurde von den Mitarbeitern des Schulungszentrums Slyerm für Habr übersetzt und vorbereitet. — Intensivkurse, Video-Trainings und Unternehmensschulungen von erfahrenen Fachleuten (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)

Quelle: habr.com

Zuverlässiges Webhosting mit DDoS-Schutz, VPS- und VDS-Server kaufen 🔥 Zuverlässiges Webhosting mit DDoS-Schutz, VPS- und VDS-Server kaufen | ProHoster