Lassen Sie uns das Konzept des Kubernetes-Monitorings betrachten, das Tool Prometheus kennenlernen und über das Alerting sprechen.
Das Thema Monitoring ist umfangreich, und es lässt sich nicht in einem einzigen Artikel vollständig abdecken. Ziel dieses Textes ist es, einen Überblick über die Werkzeuge, Konzepte und Ansätze zu geben.
Der Material des Artikels ist eine Zusammenfassung aus . Wenn Sie eine vollständige Schulung absolvieren möchten, melden Sie sich für den Kurs über .
Was im Kubernetes-Cluster überwacht wird
Physische Server. Wenn der Kubernetes-Cluster auf eigener Hardware bereitgestellt wird, muss deren Zustand überwacht werden. Diese Aufgabe übernimmt Zabbix; wenn Sie damit arbeiten, müssen Sie nicht wechseln, es gibt keine Konflikte. Zabbix überwacht den Zustand unserer Server.
Kommen wir zur Überwachung auf Cluster-Ebene.
Control Plane-Komponenten: API, Scheduler und andere. Mindestens sollten Sie sicherstellen, dass die Anzahl der API-Server oder etcd größer als 0 ist. Etcd kann viele Metriken bereitstellen: über die Festplatten, auf denen es läuft, über den Gesundheitszustand seines etcd-Clusters und andere.
Docker existiert schon seit langem und seine Probleme sind allgemein bekannt: viele Container verursachen Störungen und andere Probleme. Daher sollte auch Docker als System überwacht werden, zumindest hinsichtlich der Verfügbarkeit.
Die Unterstützung für neue WAV-Dateiformate wurde zu den Dienstprogrammen audioplay und audiorecord hinzugefügt. Wenn im Cluster DNS ausfällt, wird auch der gesamte Service Discovery davon betroffen sein, und die Anfragen zwischen Pods werden nicht mehr funktionieren. In meiner Erfahrung gab es solche Probleme nicht, aber das bedeutet nicht, dass der Zustand des DNS nicht überwacht werden sollte. Verzögerungen bei Anfragen und einige andere Kennzahlen können in CoreDNS überwacht werden.
Ingress. Die Verfügbarkeit der Ingress-Punkte (einschließlich des Ingress Controllers) als Eingabepunkte für das Projekt sollte überwacht werden.
Die grundlegenden Komponenten des Clusters haben wir besprochen — nun wollen wir tiefer einsteigen, auf die Ebene der Abstraktionen.
Es scheint, als würden Anwendungen in Pods ausgeführt, was deren Überwachung erforderlich macht. In Wirklichkeit ist das jedoch nicht der Fall. Pods sind ephemer: Heute laufen sie auf einem Server, morgen auf einem anderen; heute gibt es zehn, morgen zwei. Daher werden Pods einfach nicht überwacht. In einer Mikrodienstarchitektur ist es wichtiger, die Verfügbarkeit der Anwendung insgesamt zu überwachen. Insbesondere sollte die Erreichbarkeit der Service-Endpunkte überprüft werden: Funktioniert überhaupt etwas? Wenn die Anwendung verfügbar ist, sind die Fragen, was im Hintergrund geschieht und wie viele Replikate es derzeit gibt, von zweitrangiger Bedeutung. Es ist nicht notwendig, einzelne Instanzen zu überwachen.
Auf der letzten Ebene muss die Funktionsweise der Anwendung selbst überwacht und Geschäftsmetriken erfasst werden: Anzahl der Bestellungen, Benutzerverhalten und Ähnliches.
Prometheus
Das beste System zur Überwachung des Clusters ist . Ich kenne kein anderes Tool, das sich mit Prometheus hinsichtlich Qualität und Benutzerfreundlichkeit vergleichen lässt. Es eignet sich hervorragend für flexible Infrastrukturen, weshalb bei der Erwähnung von "Kubernetes-Überwachung" in der Regel genau auf Prometheus verwiesen wird.
Es gibt ein paar Optionen, um mit Prometheus zu arbeiten: Mit Helm lässt sich entweder ein herkömmlicher Prometheus oder ein Prometheus Operator installieren.
- Der einfache Prometheus funktioniert gut, benötigt jedoch die Konfiguration von ConfigMaps – im Grunde müssen Textkonfigurationsdateien erstellt werden, so wie wir es früher gemacht haben, bevor die mikroservicebasierte Architektur eingeführt wurde.
- Der Prometheus Operator ist etwas komplexer und hat eine umfangreichere interne Logik, bietet jedoch eine einfachere Handhabung: Es gibt separate Objekte, Abstraktionen werden zum Cluster hinzugefügt, wodurch sie viel besser kontrolliert und konfiguriert werden können.
Um mit dem Produkt vertraut zu werden, empfehle ich zunächst die Installation des einfachen Prometheus. Es wird alles über die Konfiguration eingestellt werden müssen, aber das ist nützlich: So verstehen Sie, was wohin gehört und wie es konfiguriert wird. Mit dem Prometheus Operator gehen Sie sofort eine Ebene höher in der Abstraktion, auch wenn Sie bei Bedarf tiefer eintauchen können.
Prometheus ist gut in Kubernetes integriert: Es kann auf den API-Server zugreifen und mit ihm interagieren.
Prometheus ist beliebt und wird daher von einer Vielzahl von Anwendungen und Programmiersprachen unterstützt. Unterstützung ist erforderlich, da Prometheus sein eigenes Metrikformat hat, und um diese zu übertragen, benötigt man entweder eine Bibliothek innerhalb der Anwendung oder einen fertigen Exporter. Und es gibt viele solcher Exporter. Zum Beispiel gibt es den PostgreSQL Exporter: Er holt Daten aus PostgreSQL und konvertiert sie in das Prometheus-Format, damit Prometheus mit ihnen arbeiten kann.
Architektur von Prometheus
Prometheus Server — das ist der serverseitige Teil, das Gehirn von Prometheus. Hier werden die Metriken gespeichert und verarbeitet.
Die Metriken werden in einer Time Series Database (TSDB) gespeichert. Die TSDB ist keine separate Datenbank, sondern ein Paket in der Programmiersprache Go, das in Prometheus integriert ist. Grob gesagt, alles befindet sich in einer Binärdatei.
Speichern Sie Daten nicht lange in der TSDB
Die Infrastruktur von Prometheus ist nicht für die langfristige Speicherung von Metriken geeignet. Standardmäßig beträgt die Speicherdauer 15 Tage. Man kann diese Begrenzung überschreiten, aber man muss beachten: Je mehr Daten Sie in der TSDB speichern und je länger Sie dies tun, desto mehr Ressourcen wird sie verbrauchen. Historische Daten in Prometheus zu speichern, gilt als schlechte Praxis.
Wenn Sie ein enormes Verkehrsaufkommen haben und die Anzahl der Metriken sich in Hunderttausenden pro Sekunde beläuft, sollten Sie deren Speicherung nach Speicherplatz oder Zeitraum begrenzen. In der Regel werden in TSDB nur ‚heiße Daten‘ gespeichert, Metriken, die buchstäblich nur wenige Stunden alt sind. Für eine längere Aufbewahrung werden externe Speicherlösungen in Datenbanken verwendet, die tatsächlich dafür geeignet sind, wie InfluxDB, ClickHouse usw. Über ClickHouse habe ich die besten Bewertungen gesehen.
Der Prometheus-Server funktioniert nach dem Modell pull: er holt die Metriken selbst von den Endpunkten, die wir ihm übergeben haben. Wir haben gesagt: 'Gehe zum API-Server', und er geht in einem bestimmten Intervall dorthin und holt die Metriken.
Für Objekte mit kurzer Lebensdauer (Job oder Cron-Job), die zwischen den Scraping-Intervallen auftreten können, gibt es die Komponente Pushgateway. Hier werden Metriken von kurzfristigen Objekten gepusht: Der Job wird gestartet, führt eine Aktion aus, sendet Metriken an Pushgateway und wird beendet. Nach einer gewissen Zeit holt Prometheus in seinem Rhythmus diese Metriken aus dem Pushgateway.
Zum Einrichten von Benachrichtigungen in Prometheus gibt es eine separate Komponente — Alertmanager. Und die Regeln für das Alertsystem — alerting rules. Zum Beispiel muss ein Alert erstellt werden, wenn der API-Server 0 steht. Wenn das Ereignis eintritt, wird der Alert an den Alert Manager zur weiteren Zustellung weitergeleitet. Der Alert Manager bietet flexible Routing-Einstellungen: Eine Gruppe von Alerts kann an den Telegram-Chat der Administratoren gesendet werden, eine andere an den Chat der Entwickler, eine dritte an den Chat der Infrastrukturmitarbeiter. Benachrichtigungen können über Slack, Telegram, E-Mail und andere Kanäle empfangen werden.
Und zum Schluss möchte ich die Killer-Funktion von Prometheus vorstellen — Entdeckung. Bei der Arbeit mit Prometheus müssen keine spezifischen Adressen für die zu überwachenden Objekte angegeben werden, es reicht aus, ihren Typ zu bestimmen. Das heißt, man muss nicht schreiben: „Hier ist die IP-Adresse, hier ist der Port — überwachen“, stattdessen muss man definieren, nach welchen Kriterien diese Objekte gefunden werden sollen (targets — Ziele). Prometheus zieht automatisch je nach aktiven Objekten die benötigten Informationen und fügt sie zur Überwachung hinzu.
Dieser Ansatz passt gut zur Struktur von Kubernetes, wo ebenfalls alles dynamisch ist: heute 10 Server, morgen 3. Damit man nicht jedes Mal die IP-Adresse eines Servers angeben muss, hat man einmal festgelegt, wie er gefunden wird — und die Entdeckung wird dies erledigen.
Die Sprache von Prometheus heißt PromQL. Mit dieser Sprache können Sie spezifische Metrikwerte abrufen, sie anschließend transformieren und analytische Berichte erstellen.
https://prometheus.io/docs/prometheus/latest/querying/basics/
Einfache Abfrage
container_memory_usage_bytes
Mathematische Operationen
container_memory_usage_bytes / 1024 / 1024
Eingebaute Funktionen
sum(container_memory_usage_bytes) / 1024 / 1024
Abfrage verfeinern
100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)Weboberfläche von Prometheus
Prometheus verfügt über eine recht minimalistische Weboberfläche. Sie eignet sich bestenfalls für Debugging oder Demonstrationen.
In der Zeile Expression können Sie Abfragen in der Sprache PromQL schreiben.
Im Tab Alerts befinden sich die Alarmregeln — alerting rules, und sie haben drei Status:
- inactive — wenn der Alarm derzeit nicht aktiv ist, das heißt, alles in Ordnung ist und er nicht ausgelöst wurde;
- pending — dies ist der Fall, wenn der Alarm ausgelöst wurde, die Benachrichtigung jedoch noch nicht gesendet wurde. Die Verzögerung wird eingerichtet, um Netzwerkausfälle auszugleichen: Wenn der festgelegte Dienst innerhalb einer Minute wieder hochgefahren ist, sollte der Alarm vorerst nicht ausgelöst werden;
- firing — dies ist der dritte Status, wenn der Alarm aktiviert wird und Nachrichten sendet.
Im Menü Status finden Sie Zugang zu Informationen über die Funktionsweise von Prometheus. Dort gibt es auch einen Link zu den Zielen (targets), über die wir vorher gesprochen haben.
Eine detailliertere Übersicht über die Benutzeroberfläche von Prometheus finden Sie .
Integration mit Grafana
Im Web-Interface von Prometheus finden Sie keine ansprechenden und verständlichen Diagramme, aus denen der Zustand des Clusters ersichtlich wird. Um solche Diagramme zu erstellen, wird Prometheus mit Grafana integriert. Es entstehen Dashboards wie diese.
Die Integration von Prometheus und Grafana ist ganz einfach einzurichten, die Anleitungen finden Sie in der Dokumentation: , damit beende ich meine Ausführungen.
In den nächsten Artikeln werden wir das Thema Monitoring fortsetzen: Wir werden über das Sammeln und Analysieren von Logs mit Grafana Loki und alternativen Werkzeugen sprechen.
Autor: Marsel Ibraev, zertifizierter Kubernetes-Administrator, praktizierender Ingenieur bei der Firma , Sprecher und Entwickler von Slurm-Kursen.
Quelle: habr.com
