Lassen Sie uns das Konzept des Kubernetes-Monitorings betrachten, das Tool Prometheus kennenlernen und über das Alerting sprechen.
Das Thema Monitoring ist umfangreich und kann nicht in einem einzigen Artikel vollständig behandelt werden. Ziel dieses Textes ist es, einen Überblick über Werkzeuge, Konzepte und Ansätze zu geben.
Das Material des Artikels ist eine Zusammenfassung aus . Wenn Sie eine vollständige Ausbildung absolvieren möchten, melden Sie sich für den Kurs zu .
Was wird im Kubernetes-Cluster überwacht
Physische Server. Wenn das Kubernetes-Cluster auf eigenen Servern bereitgestellt wird, muss deren Gesundheit überwacht werden. Diese Aufgabe übernimmt Zabbix; wenn Sie damit arbeiten, müssen Sie nicht auf es verzichten, es wird keine Konflikte geben. Der Zustand unserer Server wird genau von Zabbix überwacht.
Kommen wir zum Monitoring auf der Cluster-Ebene.
Control Plane-Komponenten: API, Scheduler und andere. Mindestens sollte überwacht werden, dass die Anzahl der API-Server oder etcd größer als 0 ist. Etcd kann viele Metriken bereitstellen: bezüglich der Festplatten, auf denen es läuft, zur Gesundheit seines etcd-Clusters und andere.
Docker existiert schon lange und seine Probleme sind allgemein bekannt: zahlreiche Container führen zu Hängern und anderen Problemen. Daher sollte auch Docker als System überwacht werden, auch wenn es nur um die Verfügbarkeit geht.
DNS. Wenn im Cluster DNS ausfällt, wird auch der gesamte Service Discovery ausfallen, und die Anfragen von Pods zu Pods werden nicht mehr funktionieren. In meiner Praxis gab es solche Probleme nicht, das bedeutet jedoch nicht, dass der Zustand des DNS nicht überwacht werden sollte. Verzögerungen bei Anfragen und einige andere Metriken können bei CoreDNS überwacht werden.
Ingress. Die Verfügbarkeit von Ingressen (einschließlich Ingress Controller) als Einstiegspunkte in das Projekt sollte überwacht werden.
Wir haben die Hauptkomponenten des Clusters behandelt – jetzt lassen Sie uns auf eine tiefere Ebene der Abstraktionen eingehen.
Es scheint, dass Anwendungen in Pods ausgeführt werden, daher müssen sie überwacht werden, aber das ist nicht der Fall. Pods sind flüchtig: heute laufen sie auf einem Server, morgen auf einem anderen; heute sind es 10, morgen 2. Daher überwacht niemand einfach nur die Pods. Im Rahmen einer Microservices-Architektur ist es wichtiger, die Verfügbarkeit der Anwendung insgesamt zu überwachen. Insbesondere sollte die Verfügbarkeit der Endpunkte des Dienstes überprüft werden: Funktioniert überhaupt etwas? Wenn die Anwendung verfügbar ist, sind Fragen, was dahinter passiert, wie viele Replikate aktuell vorhanden sind, von zweitrangiger Bedeutung. Es ist nicht notwendig, einzelne Instanzen zu überwachen.
Auf der letzten Ebene muss die Funktionalität der Anwendung selbst überwacht und Geschäftsmessungen erfasst werden: die Anzahl der Bestellungen, das Nutzerverhalten und anderes.
Prometheus
Das beste System zur Überwachung eines Clusters ist . Ich kenne kein anderes Werkzeug, das sich hinsichtlich Qualität und Benutzerfreundlichkeit mit Prometheus vergleichen kann. Es eignet sich hervorragend für flexible Infrastrukturen, weshalb, wenn von „Kubernetes-Überwachung“ die Rede ist, in der Regel genau Prometheus gemeint ist.
Es gibt einige Möglichkeiten, wie man mit Prometheus arbeiten kann: Mit Helm kann man entweder das normale Prometheus oder den Prometheus Operator installieren.
- Normales Prometheus. Es funktioniert gut, aber man muss das ConfigMap einrichten – essentially, man muss Textkonfigurationsdateien erstellen, wie wir es früher vor der Microservices-Architektur gemacht haben.
- Der Prometheus Operator ist etwas umfangreicher, etwas komplexer in der internen Logik, aber die Arbeit mit ihm ist einfacher: Er bietet separate Objekte, Abstraktionen werden dem Cluster hinzugefügt, wodurch sie viel bequemer zu überwachen und zu konfigurieren sind.
Um sich mit dem Produkt vertraut zu machen, empfehle ich zunächst die Installation des normalen Prometheus. Man muss alles über die Konfiguration einstellen, aber das wird von Vorteil sein: Man wird verstehen, was zu was gehört und wie man es konfiguriert. Beim Prometheus Operator steigt man sofort in eine Abstraktionsebene höher ein, obwohl man bei Wunsch auch in die Tiefe gehen kann.
Prometheus ist gut in Kubernetes integriert: Es kann auf die API-Server zugreifen und mit ihnen interagieren.
Prometheus ist populär und wird daher von einer Vielzahl von Anwendungen und Programmiersprachen unterstützt. Unterstützung ist notwendig, da Prometheus sein eigenes Format für Metriken hat, und für die Übertragung ist entweder eine Bibliothek innerhalb der Anwendung oder ein fertiger Exporteur erforderlich. Und es gibt eine ganze Reihe solcher Exporteure. Zum Beispiel gibt es den PostgreSQL Exporter: Er holt Daten aus PostgreSQL und konvertiert sie in das Prometheus-Format, damit Prometheus damit arbeiten kann.
Architektur von Prometheus
Prometheus Server — das ist der Serverteil, das Gehirn von Prometheus. Hier werden die Metriken gespeichert und verarbeitet.
Die Metriken werden in einer Zeitreihe-Datenbank (TSDB) gespeichert. Eine TSDB ist keine separate Datenbank, sondern ein Paket in der Programmiersprache Go, das in Prometheus integriert ist. Grob gesagt, alles befindet sich in einer einzigen Binärdatei.
Lagern 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 Einschränkung überschreiten, muss sich jedoch bewusst sein: 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 enormen Datenverkehr haben und die Anzahl der Metriken sich in Hunderttausenden pro Sekunde bemisst, ist es besser, deren Speicherung nach Speicherplatz oder nach Dauer zu begrenzen. In der Regel werden in der TSDB „heiße Daten“ gespeichert, Metriken, die nur wenige Stunden alt sind. Für eine längere Speicherung werden externe Speicherlösungen in Datenbanken verwendet, die wirklich dafür geeignet sind, wie zum Beispiel InfluxDB, ClickHouse usw. Ich habe überwiegend positive Rückmeldungen zu ClickHouse gesehen.
Der Prometheus Server arbeitet nach dem Modell pull: er holt sich die Metriken von den Endpunkten, die wir ihm übergeben haben. Wir haben gesagt: „geh zum API Server“, und er fragt in einem festgelegten Intervall nach den Metriken.
Für Objekte mit kurzer Lebensdauer (Job oder Cron-Job), die zwischen Scraping-Zeiten auftreten können, gibt es die Komponente Pushgateway. Metriken von kurzfristigen Objekten werden an ihn gepusht: Der Job wurde gestartet, hat eine Aktion ausgeführt, hat die Metriken an das Pushgateway gesendet und wurde beendet. Nach einer Weile wird Prometheus im eigenen Rhythmus die Metriken vom Pushgateway abholen.
Für die Konfiguration von Benachrichtigungen in Prometheus gibt es eine separate Komponente — Alertmanager. Und die Regeln für das Alerting sind alerting rules. Zum Beispiel muss ein Alert erstellt werden, wenn API-Server 0 ausgefallen sind. Wenn ein Ereignis eintritt, wird der Alert an den Alert-Manager zur weiteren Zustellung übermittelt. Der Alert-Manager bietet flexible Routing-Einstellungen: Eine Gruppe von Alerts kann in den Telegram-Chat der Administratoren gesendet werden, eine andere in den Chat der Entwickler, eine dritte in den Chat der Infrastrukturmitarbeiter. Benachrichtigungen können über Slack, Telegram, per E-Mail und über andere Kanäle empfangen werden.
Und schließlich erzähle ich von dem Killer-Feature von Prometheus — Discovering. Bei der Arbeit mit Prometheus ist es nicht nötig, konkrete Adressen von Objekten zum Überwachen anzugeben, es reicht aus, ihren Typ festzulegen. Das heißt, es muss nicht geschrieben werden: „Hier ist die IP-Adresse, hier ist der Port – überwache das“, stattdessen muss festgelegt werden, nach welchen Prinzipien diese Objekte gefunden werden sollen (targets — Ziele). Prometheus zieht selbst, abhängig davon, welche Objekte gerade aktiv sind, die benötigten Objekte an und fügt sie zur Überwachung hinzu.
Dieser Ansatz passt gut zur Struktur von Kubernetes, wo auch alles Schwankungen unterliegt: heute 10 Server, morgen 3. Damit nicht jedes Mal die IP-Adresse des Servers angegeben werden muss, wird einmal festgelegt, wie man ihn findet — und Discovering erledigt das.
Die Sprache von Prometheus heißt PromQL. Mit dieser Sprache können Werte bestimmter Metriken abgerufen und dann umgewandelt werden, um analytische Auswertungen zu 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
Präzisierung der Abfrage
100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)Weboberfläche von Prometheus
Prometheus hat eine eigene, recht minimalistische Weboberfläche. Sie eignet sich höchstens für Debugging oder Demonstration.
In der Zeile Expression können Abfragen in der Sprache PromQL geschrieben werden.
Im Tab Alerts befinden sich die Regeln für Alerts — alerting rules, und sie haben drei Status:
- inactive — wenn der Alert im Moment nicht aktiv ist, das heißt, alles in Ordnung ist und er nicht ausgelöst wurde;
- pending — dies ist der Fall, wenn der Alert ausgelöst wurde, die Zustellung jedoch noch nicht erfolgt ist. Die Verzögerung wird festgelegt, um Netzwerkflackern auszugleichen: Wenn der betreffende Dienst innerhalb einer Minute wieder hochgefahren wurde, muss die Alarmierung zunächst ausbleiben;
- firing — das ist der dritte Status, wenn der Alert ausgelöst wird und Nachrichten sendet.
Im Menü Status finden Sie Zugriff auf Informationen über das, was Prometheus ausmacht. Dort gibt es auch einen Zugang zu den Zielen (targets), über die wir zuvor gesprochen haben.
Eine detailliertere Übersicht über die Benutzeroberfläche von Prometheus finden Sie .
Integration mit Grafana
In der Weboberfläche von Prometheus finden Sie keine ansprechenden und verständlichen Diagramme, aus denen man den Zustand des Clusters ablesen könnte. Um diese zu erstellen, wird Prometheus mit Grafana integriert. Es entstehen solche Dashboards.
Die Integration von Prometheus und Grafana einzurichten, ist ganz einfach, Anleitungen finden Sie in der Dokumentation: , aber ich beende damit.
In den nächsten Artikeln werden wir das Thema Überwachung fortsetzen: Wir werden über das Sammeln und Analysieren von Protokollen mit Grafana Loki und alternativen Tools sprechen.
Autor: Marsel Ibraev, zertifizierter Kubernetes-Administrator, praktizierender Ingenieur bei der Firma , Referent und Kursentwickler bei Slurm.
Quelle: habr.com
