Mit zunehmender Komplexität verteilter Systeme ist Monitoring zu einem sehr wichtigen Bestandteil wachsender Cloud-Lösungen geworden. Es ist notwendig, ihr Verhalten zu verstehen. Wir brauchen skalierbare Tools, die Daten von allen Diensten sammeln können – und Spezialisten eine einzige Schnittstelle mit Leistungsanalyse, Fehlerdemonstration, Verfügbarkeit und Protokollen bieten.
Dieselben Tools müssen effizient und produktiv sein. In diesem Artikel werden wir uns zwei beliebte Technologie-Stacks ansehen: EFK (Elasticsearch) und PLG (Loki) und ihre Architekturen und Unterschiede analysieren.
EFK-Stack
Möglicherweise haben Sie bereits vom sehr beliebten ELK oder EFK gehört. Der Stack besteht aus mehreren separaten Teilen: Elasticsearch (Objektspeicher), Logstash oder FluentD (Sammlung und Aggregation von Protokollen) und Kibana zur Visualisierung.
Ein typischer Arbeitsablauf sieht so aus:
Elasticsearch – verteilter Objektspeicher mit Echtzeitsuche und -analyse. Eine hervorragende Lösung für halbstrukturierte Daten wie Protokolle. Die Informationen werden als JSON-Dokumente gespeichert, in Echtzeit indiziert und über die Clusterknoten verteilt. Es wird ein invertierter Index verwendet, der alle eindeutigen Wörter und zugehörigen Dokumente für die Volltextsuche enthält, der wiederum auf der Suchmaschine Apache Lucene basiert.
FließendD ist ein Datensammler, der Daten vereinheitlicht, während sie erfasst und verbraucht werden. Es wird versucht, die Daten so weit wie möglich in JSON zu organisieren. Seine Architektur ist erweiterbar, es gibt noch mehr , unterstützt von der Community, für alle Gelegenheiten.
Kibana ist ein Datenvisualisierungstool für Elasticsearch mit verschiedenen Zusatzfunktionen wie Zeitreihenanalyse, Diagrammen, maschinellem Lernen und mehr.
Elasticsearch-Architektur
Die Daten des Elasticsearch-Clusters werden über alle Knoten verteilt gespeichert. Der Cluster besteht aus mehreren Knoten, um die Verfügbarkeit und Ausfallsicherheit zu verbessern. Jeder Knoten kann alle Clusterrollen ausführen, aber in großen, skalierbaren Bereitstellungen werden den Knoten normalerweise separate Aufgaben zugewiesen.
Clusterknotentypen:
- Masterknoten – verwaltet den Cluster, Sie benötigen mindestens drei, einer ist immer aktiv;
- Datenknoten – speichert indizierte Daten und führt damit verschiedene Aufgaben aus;
- Aufnahmeknoten – organisiert Pipelines für die Datentransformation vor der Indizierung;
- Koordinierungsknoten – Anforderungsweiterleitung, Reduzierung der Suchverarbeitungsphase, Koordinierung der Massenindizierung;
- Alarmierungsknoten – Benachrichtigungsaufgaben starten;
- Knoten für maschinelles Lernen – Verarbeitung von Aufgaben für maschinelles Lernen.
Das folgende Diagramm zeigt, wie Daten zwischen Knoten beibehalten und repliziert werden, um eine höhere Datenverfügbarkeit zu erreichen.
Die Daten jedes Replikats werden in einem invertierten Index gespeichert. Das folgende Diagramm zeigt, wie das geschieht:
Einstellung
Details können eingesehen werden , ich werde das Ruderdiagramm verwenden:
$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elasticsPLG-Stack
Seien Sie nicht überrascht, wenn Sie dieses Akronym nicht finden, denn es ist besser bekannt als Grafana Loki. Auf jeden Fall erfreut sich dieser Stack zunehmender Beliebtheit, da er auf gut abgestimmte technische Lösungen setzt. Möglicherweise haben Sie bereits von Grafana gehört, einem beliebten Visualisierungstool. Seine von Prometheus inspirierten Schöpfer entwickelten Loki, ein horizontal skalierbares, leistungsstarkes Protokollaggregationssystem. Loki indiziert nur die Metadaten, nicht die Zeitschriften selbst. Diese technische Lösung hat die Verwendung einfach und kostengünstig gemacht.
Abschlussball – ein Agent zum Senden von Protokollen vom Betriebssystem an den Loki-Cluster. Grafana ist ein Visualisierungstool, das auf Daten von Loki basiert.
Loki basiert auf den gleichen Prinzipien wie Prometheus und eignet sich daher gut zum Speichern und Parsen von Kubernetes-Protokollen.
Loki-Architektur
Loki kann als einzelner Prozess oder als mehrere Prozesse ausgeführt werden, was eine horizontale Skalierung ermöglicht.
Es kann auch sowohl als monolithische Anwendung als auch als Microservice funktionieren. Die Ausführung als einzelner Prozess kann für die lokale Entwicklung oder für eine differenzierte Überwachung nützlich sein. Für die industrielle Umsetzung und skalierbare Arbeitslast empfiehlt sich der Einsatz der Microservice-Option. Die Datenschreib- und Lesepfade sind getrennt, sodass sie je nach Bedarf fein abgestimmt und skaliert werden können.
Schauen wir uns die Architektur des Protokollerfassungssystems ohne Details an:
Und hier ist die Beschreibung (Microservice-Architektur):
Komponenten:
Abschlussball – ein auf Knoten installierter Agent (als eine Reihe von Diensten), der Protokolle aus Aufgaben entfernt und auf die Kubernetes-API zugreift, um Metadaten abzurufen, die zum Markieren der Protokolle verwendet werden. Anschließend wird das Protokoll an den Hauptdienst von Loki gesendet. Für den Metadatenabgleich werden die gleichen Tagging-Regeln wie in Prometheus unterstützt.
Vertriebspartner - Service-Verteiler, der als Puffer fungiert. Um Millionen von Datensätzen zu verarbeiten, werden eingehende Daten gepackt und beim Eintreffen in Blöcken komprimiert. Mehrere Datensenken werden gleichzeitig ausgeführt, aber Protokolle, die zum selben eingehenden Datenstrom gehören, sollten für alle seine Blöcke nur in einer von ihnen landen. Dies ist als Ring von Empfängern und sequentiellem Hashing organisiert. Aus Gründen der Fehlertoleranz und Redundanz wird dies n-mal durchgeführt (3, wenn nicht konfiguriert).
Einnahme — Dienstempfänger. Datenblöcke werden mit zusätzlichen Protokollen komprimiert. Sobald der Block eine ausreichende Größe hat, wird er in die Datenbank geschrieben. Die Metadaten gehen an den Index und die Daten aus dem Protokollblock gehen an Chunks (normalerweise Objektspeicher). Nach dem Zurücksetzen erstellt der Empfänger einen neuen Block, in dem neue Datensätze hinzugefügt werden.
Index - Datenbank, DynamoDB, Cassandra, Google BigTable und mehr.
Stücke - Protokollblöcke in komprimierter Form, die normalerweise im Objektspeicher, beispielsweise S3, gespeichert werden.
Querier ist ein Lesepfad, der die ganze Drecksarbeit erledigt. Es prüft den Zeitbereich und den Zeitstempel und anschließend den Index, um nach Übereinstimmungen zu suchen. Als nächstes liest es Datenblöcke und filtert sie, um das Ergebnis zu erhalten.
Sehen wir uns nun alles bei der Arbeit an.
Einstellung
Der einfachste Weg zur Installation auf Kubernetes ist die Verwendung von Helm. Wir gehen davon aus, dass Sie es bereits installiert und konfiguriert haben ( ca. Übersetzer)
Wir fügen ein Repository hinzu und legen einen Stapel ab.
$ 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=falseUnten finden Sie ein Beispiel-Dashboard mit Daten von Prometheus für Etcd und Loki-Metriken für Etcd-Pod-Protokolle.
Lassen Sie uns nun die Architektur beider Systeme besprechen und ihre Fähigkeiten miteinander vergleichen.
Vergleich
Abfragesprache
Elasticsearch verwendet die Abfragesprache Query DSL und Lucene, um eine Volltextsuchfunktion bereitzustellen. Es handelt sich um eine etablierte leistungsstarke Suchmaschine mit breiter Betreiberunterstützung. Damit können Sie nach Kontext suchen und nach Relevanz sortieren.
Auf der anderen Seite des Rings steht Lokis LogQL, ein Nachfolger von PromQL (Prometheus-Abfragesprache). Es verwendet Protokollbezeichnungen, um Protokolldaten zu filtern und auszuwählen. Es ist möglich, einige Operatoren und Arithmetik wie beschrieben zu verwenden , aber in Bezug auf die Fähigkeiten bleibt es hinter der Elastic-Sprache zurück.
Da Anfragen in Loki mit Labels verknüpft sind, lassen sie sich leicht mit Metriken korrelieren, wodurch es einfacher ist, die Betriebsüberwachung mit ihnen zu organisieren.
Skalierbarkeit
Beide Stacks sind horizontal skalierbar, aber mit Loki ist es einfacher, da es über separate Lese- und Schreibpfade verfügt und über eine Microservice-Architektur verfügt. Loki kann an Ihre Bedürfnisse angepasst werden und kann für sehr große Protokolldatenmengen verwendet werden.
Mandantenfähigkeit
Cluster-Mehrmandantenfähigkeit ist ein häufiges Thema für die OPEX-Reduzierung, beide Stacks bieten Mehrmandantenfähigkeit. Es gibt mehrere für Elasticsearch Kundentrennung: separater Index pro Kunde, kundenbasiertes Routing, kundenspezifische Felder, Suchfilter. Loki hat als HTTP-X-Scope-OrgID-Header.
Kosten
Loki ist sehr kostengünstig, da es keine Daten, sondern nur Metadaten indiziert. Daher, und Speicher (Cache), da Objektspeicher günstiger ist als Blockspeicher, der in Elasticsearch-Clustern verwendet wird.
Abschluss
Der EFK-Stack kann für verschiedene Zwecke verwendet werden und bietet maximale Flexibilität und eine umfangreiche Kibana-Schnittstelle für Analysen, Visualisierung und Abfragen. Es kann durch maschinelle Lernfunktionen weiter verbessert werden.
Der Loki-Stack ist im Kubernetes-Ökosystem aufgrund des Mechanismus zur Metadatenerkennung nützlich. Sie können Daten für die Überwachung einfach anhand von Zeitreihen in Grafana und Protokollen korrelieren.
Wenn es um Kosten und langfristige Protokollaufbewahrung geht, ist Loki eine ausgezeichnete Wahl für den Einstieg in die Cloud.
Es gibt mehr Alternativen auf dem Markt – einige könnten für Sie besser sein. GKE verfügt beispielsweise über eine Stackdriver-Integration, die eine großartige Überwachungslösung bietet. Wir haben sie nicht in unsere Analyse in diesem Artikel einbezogen.
Links:
Der Artikel wurde von Mitarbeitern für Habr übersetzt und aufbereitet — Intensivkurse, Videokurse und Unternehmensschulungen von Praktikern (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
Source: habr.com