Betrachten Sie das Konzept der Kubernetes-Überwachung, machen Sie sich mit dem Prometheus-Tool vertraut und sprechen Sie über Alarmierung.
Das Thema Überwachung ist umfangreich und kann nicht in einem Artikel zerlegt werden. Der Zweck dieses Textes besteht darin, einen Überblick über die Tools, Konzepte und Ansätze zu geben.
Das Material des Artikels ist ein Knaller . Wenn Sie eine umfassende Ausbildung erhalten möchten, melden Sie sich für einen Kurs an .
Was wird in einem Kubernetes-Cluster überwacht?
Physische Server. Wenn ein Kubernetes-Cluster auf seinen eigenen Servern bereitgestellt wird, müssen Sie deren Zustand überwachen. Zabbix übernimmt diese Aufgabe; Wenn Sie mit ihm zusammenarbeiten, besteht kein Grund zur Ablehnung, es wird keine Konflikte geben. Es ist Zabbix, das den Zustand unserer Server überwacht.
Kommen wir zur Überwachung auf Clusterebene.
Komponenten der Kontrollebene: API, Scheduler und andere. Sie müssen mindestens überwachen, dass die Server-API oder etcd größer als 0 ist. Etcd kann viele Metriken bereitstellen: zu den Festplatten, auf denen es läuft, zum Zustand seines etcd-Clusters und andere.
Docker ist schon vor langer Zeit aufgetaucht und jeder kennt seine Probleme: Viele Container verursachen Einfrierungen und andere Probleme. Daher sollte auch Docker selbst als System kontrolliert werden, zumindest hinsichtlich der Verfügbarkeit.
DNS Wenn DNS in einem Cluster ausfällt, fällt auch der gesamte Discovery-Dienst aus und Aufrufe von Pods zu Pods funktionieren nicht mehr. In meiner Praxis gab es keine derartigen Probleme, was jedoch nicht bedeutet, dass der DNS-Status nicht überwacht werden muss. Die Anforderungslatenz und einige andere Metriken können auf CoreDNS verfolgt werden.
Ingress. Es ist notwendig, die Verfügbarkeit von Ingresses (einschließlich des Ingress Controllers) als Einstiegspunkte für das Projekt zu kontrollieren.
Die Hauptkomponenten des Clusters wurden zerlegt – gehen wir nun tiefer, auf die Ebene der Abstraktionen.
Es scheint, dass Anwendungen in Pods laufen, was bedeutet, dass sie kontrolliert werden müssen, aber in Wirklichkeit ist dies nicht der Fall. Pods sind kurzlebig: Heute laufen sie auf einem Server, morgen auf einem anderen; Heute sind es 10, morgen 2. Daher überwacht niemand die Pods. In einer Microservice-Architektur ist es wichtiger, die Verfügbarkeit der Anwendung als Ganzes zu kontrollieren. Überprüfen Sie insbesondere die Verfügbarkeit der Service-Endpunkte: Funktioniert etwas? Wenn die Anwendung verfügbar ist, was passiert dann dahinter, wie viele Replikate gibt es jetzt – das sind Fragen zweiter Ordnung. Eine Überwachung einzelner Instanzen ist nicht erforderlich.
Auf der letzten Ebene müssen Sie den Betrieb der Anwendung selbst steuern und Geschäftskennzahlen erfassen: Anzahl der Bestellungen, Benutzerverhalten usw.
Prometheus
Das beste System zur Überwachung eines Clusters ist . Ich kenne kein Tool, das in puncto Qualität und Benutzerfreundlichkeit mit Prometheus mithalten kann. Es eignet sich hervorragend für agile Infrastrukturen. Wenn also von „Kubernetes-Überwachung“ die Rede ist, meinen sie normalerweise Prometheus.
Für den Einstieg in Prometheus gibt es mehrere Möglichkeiten: Mit Helm können Sie einen regulären Prometheus oder Prometheus-Operator installieren.
- Regelmäßiger Prometheus. Bei ihm ist alles in Ordnung, aber Sie müssen ConfigMap konfigurieren – tatsächlich schreiben Sie textbasierte Konfigurationsdateien, wie wir es zuvor vor der Microservice-Architektur getan haben.
- Der Prometheus-Operator ist etwas umfangreicher und in Bezug auf die interne Logik etwas komplizierter, aber es ist einfacher, damit zu arbeiten: Es gibt separate Objekte, Abstraktionen werden dem Cluster hinzugefügt, sodass sie viel bequemer zu steuern und zu konfigurieren sind.
Um das Produkt zu verstehen, empfehle ich, zunächst das reguläre Prometheus zu installieren. Sie müssen alles über die Konfiguration konfigurieren, aber das ist von Vorteil: Sie werden verstehen, was zu was gehört und wie es konfiguriert ist. In Prometheus Operator steigen Sie sofort zu einer höheren Abstraktion auf, können aber, wenn Sie möchten, auch in die Tiefe vordringen.
Prometheus ist gut in Kubernetes integriert: Es kann auf den API-Server zugreifen und mit ihm interagieren.
Prometheus ist beliebt und wird von einer Vielzahl von Anwendungen und Programmiersprachen unterstützt. Unterstützung ist erforderlich, da Prometheus über ein eigenes Metrikformat verfügt und für die Übertragung entweder eine Bibliothek innerhalb der Anwendung oder ein vorgefertigter Exporter erforderlich ist. Und es gibt eine ganze Reihe solcher Exporteure. Es gibt zum Beispiel den PostgreSQL Exporter: Er übernimmt Daten von PostgreSQL und konvertiert sie in das Prometheus-Format, damit Prometheus damit arbeiten kann.
Prometheus-Architektur
Prometheus-Server – das ist der Serverteil, das Gehirn von Prometheus. Hier werden Kennzahlen gespeichert und verarbeitet.
Die Metriken werden in der Zeitreihendatenbank (TSDB) gespeichert. TSDB ist keine separate Datenbank, sondern ein Go-Paket, das in Prometheus integriert ist. Grob gesagt ist alles in einer Binärdatei.
Speichern Sie Daten nicht für längere Zeit in der TSDB
Die Prometheus-Infrastruktur ist nicht für die langfristige Speicherung von Metriken geeignet. Die Standardaufbewahrungsfrist beträgt 15 Tage. Sie können dieses Limit überschreiten, aber bedenken Sie: Je mehr Daten Sie in der TSDB speichern und je länger Sie dies tun, desto mehr Ressourcen werden verbraucht. Das Speichern historischer Daten in Prometheus gilt als schlechte Praxis.
Wenn Sie großen Datenverkehr haben und die Anzahl der Messwerte Hunderttausende pro Sekunde beträgt, ist es besser, deren Speicherung nach Speicherplatz oder Zeitraum zu begrenzen. Typischerweise speichert TSDB „Hot Data“, also Metriken, im wahrsten Sinne des Wortes für ein paar Stunden. Für eine längere Speicherung wird externer Speicher in den Datenbanken verwendet, die dafür wirklich geeignet sind, zum Beispiel InfluxDB, ClickHouse usw. Ich habe weitere gute Bewertungen über ClickHouse gesehen.
Prometheus Server funktioniert nach dem Modell ziehen: Er sucht nach Metriken zu den Endpunkten, die wir ihm gegeben haben. Sie sagten: „Gehen Sie zum API-Server“, und alle n-ten Sekunden geht er dorthin und nimmt die Metriken auf.
Für Objekte mit kurzer Lebensdauer (Job oder Cronjob), die zwischen den Scraping-Zeiträumen erscheinen können, gibt es eine Pushgateway-Komponente. Metriken von kurzfristigen Objekten werden hineingeschoben: Der Job stieg, die Aktion wurde abgeschlossen, die Metriken wurden an Pushgateway gesendet und abgeschlossen. Nach einiger Zeit wird Prometheus in seinem eigenen Tempo vorgehen und diese Kennzahlen von Pushgateway übernehmen.
Um Benachrichtigungen in Prometheus zu konfigurieren, gibt es eine separate Komponente – Alarmmanager. Und die Alarmierungsregeln. Beispielsweise müssen Sie eine Warnung erstellen, wenn die Server-API 0 ist. Wenn das Ereignis ausgelöst wird, wird die Warnung zum weiteren Senden an den Warnungsmanager übergeben. Der Alarmmanager verfügt über recht flexible Routing-Einstellungen: Eine Gruppe von Alarmen kann an den Telegram-Chat der Administratoren gesendet werden, eine andere an den Chat der Entwickler und eine dritte an den Chat der Infrastrukturarbeiter. Benachrichtigungen können an Slack, Telegram, E-Mail und andere Kanäle gesendet werden.
Und zum Schluss erzähle ich Ihnen von der Killerfunktion von Prometheus – Discovering. Wenn Sie mit Prometheus arbeiten, müssen Sie keine spezifischen Adressen von zu überwachenden Objekten angeben, es reicht aus, deren Typ festzulegen. Das heißt, Sie müssen nicht schreiben „Hier ist die IP-Adresse, hier ist der Port – Monitor“, sondern Sie müssen festlegen, nach welchen Prinzipien diese Objekte gefunden werden sollen (Ziele - Ziele). Prometheus selbst ruft je nachdem, welche Objekte gerade aktiv sind, die benötigten auf und fügt sie dem Monitoring hinzu.
Dieser Ansatz passt gut zur Struktur von Kubernetes, wo auch alles schwebt: Heute gibt es 10 Server, morgen 3. Um nicht jedes Mal die IP-Adresse des Servers anzugeben, haben wir einmal geschrieben, wie man sie findet – und Discovering wird es tun.
Die Prometheus-Sprache heißt PromQL. Mit dieser Sprache können Sie die Werte bestimmter Metriken abrufen, diese dann umwandeln und darauf basierend analytische Berechnungen erstellen.
https://prometheus.io/docs/prometheus/latest/querying/basics/
Простой запрос
container_memory_usage_bytes
Математические операции
container_memory_usage_bytes / 1024 / 1024
Встроенные функции
sum(container_memory_usage_bytes) / 1024 / 1024
Уточнение запроса
100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)Prometheus-Weboberfläche
Prometheus verfügt über eine eigene, recht minimalistische Weboberfläche. Nur zum Debuggen oder zur Demonstration geeignet.
In der Ausdruckszeile können Sie eine Abfrage in der PromQL-Sprache schreiben.
Die Registerkarte „Warnungen“ enthält Warnregeln und sie haben drei Status:
- inaktiv – wenn die Warnung im Moment nicht aktiv ist, das heißt, alles ist in Ordnung und es hat nicht funktioniert;
- ausstehend – Dies ist der Fall, wenn die Warnung ausgelöst wurde, der Versand jedoch noch nicht erfolgt ist. Die Verzögerung ist so eingestellt, dass sie das Blinken des Netzwerks kompensiert: Wenn der angegebene Dienst innerhalb einer Minute angestiegen ist, besteht noch keine Notwendigkeit, den Alarm auszulösen;
- Das Auslösen ist der dritte Status, wenn der Alarm aufleuchtet und Nachrichten sendet.
Im Statusmenü finden Sie Zugriff auf Informationen darüber, was Prometheus ist. Es gibt auch einen Übergang zu den Zielen (Targets), über die wir oben gesprochen haben.
Eine detailliertere Übersicht über die Prometheus-Schnittstelle finden Sie unter .
Integration mit Grafana
Im Prometheus-Webinterface findet man keine schönen und verständlichen Grafiken, aus denen man Rückschlüsse auf den Zustand des Clusters ziehen kann. Um sie zu erstellen, wird Prometheus in Grafana integriert. Wir bekommen solche Dashboards.
Das Einrichten der Prometheus- und Grafana-Integration ist überhaupt nicht schwierig, Anweisungen finden Sie in der Dokumentation: , nun, ich mache damit Schluss.
In den folgenden Artikeln werden wir das Thema Überwachung fortsetzen: Wir werden über das Sammeln und Analysieren von Protokollen mit Grafana Loki und alternativen Tools sprechen.
Autor: Marcel Ibraev, zertifizierter Kubernetes-Administrator, praktizierender Ingenieur im Unternehmen , Referent und Kursentwickler Slurm.
Source: habr.com