Wie Monitoring funktioniert

Der Prometheus Operator beobachtet die Erstellung von ServiceMonitors, PodMonitors und PrometheusRules. Wenn die Konfigurationsressourcen von Prometheus erstellt werden, ruft der Prometheus Operator die Prometheus API auf, um die neue Konfiguration zu synchronisieren. Wie das Diagramm am Ende dieses Abschnitts zeigt, fungiert der Prometheus Operator als Vermittler zwischen Prometheus und Kubernetes, indem er die Prometheus API aufruft, um Prometheus mit den monitoringbezogenen Ressourcen in Kubernetes zu synchronisieren.

ServiceMonitors und PodMonitors spezifizieren deklarativ Ziele, wie Services und Pods, die überwacht werden müssen.

PrometheusRules ermöglichen es Benutzern, Regeln zu definieren, für welche Metriken oder Zeitreihen-Datenbankabfragen Alarme ausgelöst werden sollen. Regeln werden in einem Intervall ausgewertet.

Sobald Prometheus feststellt, dass ein Alarm ausgelöst werden muss, werden die Alarme an Alertmanager weitergeleitet.

Nachdem Metriken von Exportern gesammelt wurden, speichert Prometheus die Zeitreihen in einer lokalen, auf der Festplatte befindlichen Zeitreihendatenbank. Prometheus integriert sich optional mit entfernten Systemen, verwendet jedoch rancher-monitoring lokalen Speicher für die Zeitreihendatenbank.

Sobald sie gespeichert sind, können Benutzer diese TSDB mit PromQL abfragen, der Abfragesprache für Prometheus.

PromQL-Abfragen können auf zwei Arten visualisiert werden:

Regeln definieren Abfragen, die Prometheus regelmäßig evaluationInterval ausführen muss, um bestimmte Aktionen durchzuführen, wie das Auslösen einer Warnung (Alarmierungsregeln) oder das Vorberechnen einer Abfrage basierend auf anderen, die in seiner TSDB vorhanden sind (Aufzeichnungsregeln). Diese Regeln sind in benutzerdefinierten Ressourcen vom Typ PrometheusRules kodiert. Wenn benutzerdefinierte Ressourcen vom Typ PrometheusRules erstellt oder aktualisiert werden, beobachtet der Prometheus-Operator die Änderung und ruft die Prometheus-API auf, um die Menge der Regeln zu synchronisieren, die Prometheus derzeit in regelmäßigen Abständen bewertet.

Eine PrometheusRule ermöglicht es Ihnen, eine oder mehrere RuleGroups zu definieren. Jede RuleGroup besteht aus einer Menge von Regelobjekten, die jeweils entweder eine Alarmierungs- oder eine Aufzeichnungsregel mit den folgenden Feldern darstellen können:

Bei der Auswertung einer Regel führt Prometheus die bereitgestellte PromQL-Abfrage aus, fügt die bereitgestellten Labels hinzu und führt die entsprechende Aktion für die Regel aus. Wenn die Regel einen Alarm auslöst, fügt Prometheus auch die bereitgestellten Annotationen hinzu. Zum Beispiel wird eine Alarmierungsregel, die team: front-end als Label zur bereitgestellten PromQL-Abfrage hinzufügt, dieses Label zum ausgelösten Alarm hinzufügen, was es dem Alertmanager ermöglicht, den Alarm an den richtigen Empfänger weiterzuleiten.

Prometheus verwaltet nicht den Zustand, ob Alarme aktiv sind. Es löst Alarme wiederholt in jedem Bewertungsintervall aus und verlässt sich darauf, dass der Alertmanager die Alarme in sinnvolle Benachrichtigungen gruppiert und filtert.

Die evaluation_interval-Konstante definiert, wie oft Prometheus seine Alarmierungsregeln gegen die Zeitreihendatenbank auswertet. Ähnlich wie die scrape_interval hat auch die evaluation_interval standardmäßig eine Minute.

Die Regeln sind in einer Reihe von Regeldateien enthalten. Regeldateien enthalten sowohl Alarmierungsregeln als auch Aufzeichnungsregeln, aber nur Alarmierungsregeln führen nach ihrer Auswertung zu ausgelösten Alarmen.

Für Aufzeichnungsregeln führt Prometheus eine Abfrage aus und speichert sie dann als Zeitreihe. Diese synthetische Zeitreihe ist nützlich, um die Ergebnisse einer teuren oder zeitaufwändigen Abfrage zu speichern, damit sie in Zukunft schneller abgefragt werden kann.

Alarmierungsregeln werden häufiger verwendet. Immer wenn eine Alarmierungsregel zu einer positiven Zahl evaluiert, löst Prometheus einen Alarm aus.

Die Regeldatei fügt den Alarmen vor dem Auslösen Labels und Annotationen hinzu, abhängig vom Anwendungsfall:

Wenn alertingDrivers installiert sind, wird ein Service erstellt, das als URL des Empfängers für Teams oder SMS verwendet werden kann, basierend auf der Konfiguration des alertingDrivers. Die URL im Empfänger verweist auf die alertingDrivers; der Alertmanager sendet die Benachrichtigung zuerst an den alertingDriver, dann leitet der alertingDriver die Benachrichtigung an das richtige Ziel weiter oder sendet sie dorthin.

Der Alertmanager koordiniert, wohin Benachrichtigungen gesendet werden. Er ermöglicht es Ihnen, Benachrichtigungen basierend auf Etiketten zu gruppieren und sie auszulösen, basierend darauf, ob bestimmte Etiketten übereinstimmen. Eine oberste Route akzeptiert alle Benachrichtigungen. Von dort aus setzt der Alertmanager die Weiterleitung von Benachrichtigungen an Empfänger fort, basierend darauf, ob sie die Bedingungen der nächsten Route erfüllen.

Während die Formulare der Rancher-Benutzeroberfläche nur das Bearbeiten eines Routing-Baums ermöglichen, der zwei Ebenen tief ist, können Sie tiefer verschachtelte Routing-Strukturen konfigurieren, indem Sie das Alertmanager-Secret bearbeiten.

Durch das Bearbeiten der Formulare in der Rancher-Benutzeroberfläche können Sie eine Empfängerressource einrichten, die alle Informationen enthält, die der Alertmanager benötigt, um Benachrichtigungen an Ihr Benachrichtigungssystem zu senden.

Durch das Bearbeiten von benutzerdefiniertem YAML in der Alertmanager- oder Receiver-Konfiguration können Sie auch Warnungen an mehrere Benachrichtigungssysteme senden. Für weitere Informationen siehe den Abschnitt zur Konfiguration von Empfänger.

Standardmäßig wird eine Reihe von Ressourcen, die vom kube-prometheus Projekt kuratiert werden, auf Ihrem Cluster bereitgestellt, wenn die Rancher Monitoring-Anwendung installiert wird, um einen grundlegenden Überwachungs-/Alarmierungs-Stack einzurichten.

Die Ressourcen, die auf Ihrem Cluster bereitgestellt werden, um diese Lösung zu unterstützen, finden Sie im rancher-monitoring Helm-Chart, das sich eng am Upstream kube-prometheus-stack Helm-Chart orientiert, das von der Prometheus-Community mit bestimmten Änderungen im CHANGELOG.md gepflegt wird.

Monitoring V2 stellt drei Standard-Exporter bereit, die zusätzliche Metriken liefern, die Prometheus speichern kann:

ServiceMonitors und PodMonitors werden diese Exporter abfragen, wie hier definiert. Prometheus speichert diese Metriken, und Sie können die Ergebnisse entweder über die Benutzeroberfläche von Prometheus oder Grafana abfragen.

Siehe den Abschnitt Architektur für weitere Informationen zu Aufzeichnungsregeln, Alarmierungsregeln und Alertmanager.

Wenn die Überwachungsanwendung installiert ist, können Sie die folgenden Komponenten in der Rancher-Benutzeroberfläche bearbeiten:

PushProx ermöglicht es Prometheus, Metriken über eine Netzwerkgrenze hinweg zu scrapen, wodurch verhindert wird, dass Benutzer Metrikports für interne Kubernetes-Komponenten auf jedem Knoten in einem Kubernetes-Cluster freigeben müssen.

Da die Metriken für Kubernetes-Komponenten im Allgemeinen im Hostnetzwerk der Knoten im Cluster bereitgestellt werden, implementiert PushProx ein DaemonSet von Clients, die im Hostnetzwerk jedes Knotens sitzen und eine ausgehende Verbindung zu einem einzelnen Proxy herstellen, der sich an der Kubernetes-API befindet. Prometheus kann dann so konfiguriert werden, dass es Scrape-Anfragen über den Proxy an jeden Client weiterleitet, was es ihm ermöglicht, Metriken von den internen Kubernetes-Komponenten abzufragen, ohne dass eingehende Knotenports geöffnet werden müssen.

Siehe Scraping Metrics mit PushProx für weitere Informationen.

ServiceMonitors und PodMonitors definieren Ziele, die für Prometheus zum Abfragen vorgesehen sind. Die benutzerdefinierte Ressource von Prometheus sagt Prometheus, welche ServiceMonitors oder PodMonitors es verwenden soll, um herauszufinden, wo Metriken abgefragt werden sollen.

Der Prometheus-Operator beobachtet die ServiceMonitors und PodMonitors. Wenn es beobachtet, dass sie erstellt oder aktualisiert werden, ruft es die Prometheus-API auf, um die Scrape-Konfiguration in der Prometheus-Custom-Resource zu aktualisieren und sie mit der Scrape-Konfiguration in den ServiceMonitors oder PodMonitors synchron zu halten. Diese Scrape-Konfiguration sagt Prometheus, von welchen Endpunkten es Metriken abfragen soll und wie es die Metriken von diesen Endpunkten kennzeichnen wird.

Prometheus ruft alle Metriken ab, die in seiner Scrape-Konfiguration definiert sind, in jedem scrape_interval, was standardmäßig jede Minute erfolgt.

Die Scrape-Konfiguration kann als Teil der benutzerdefinierten Ressource von Prometheus angesehen werden, die in der Rancher-Benutzeroberfläche angezeigt wird.

Das Prometheus-Deployment oder StatefulSet ruft Metriken ab, und die Konfiguration von Prometheus wird durch die benutzerdefinierten Ressourcen von Prometheus gesteuert. Der Prometheus-Operator überwacht Prometheus- und Alertmanager-Ressourcen, und wenn sie erstellt werden, erstellt der Prometheus-Operator ein Deployment oder StatefulSet für Prometheus oder Alertmanager mit der benutzerdefinierten Konfiguration.

Wenn der Prometheus-Operator ServiceMonitors, PodMonitors und PrometheusRules beobachtet, die erstellt werden, weiß er, dass die Konfiguration in Prometheus aktualisiert werden muss. Er aktualisiert Prometheus, indem er zuerst die Konfiguration und die Regeldateien in den Volumes des Deployments oder StatefulSets von Prometheus aktualisiert. Dann ruft er die Prometheus-API auf, um die neue Konfiguration zu synchronisieren, was dazu führt, dass das Prometheus-Deployment oder StatefulSet vor Ort geändert wird.

Prometheus ruft Metriken von Deployments ab, die als exporters, bekannt sind und die Zeitreihendaten in einem Format exportieren, das Prometheus verarbeiten kann. In Prometheus bestehen Zeitreihen aus Datenströmen von zeitgestempelten Werten, die zur gleichen Metrik und zum gleichen Satz von mit denselben Bezeichnungen versehenen Dimensionen gehören.

Bestimmte interne Kubernetes-Komponenten werden über einen Proxy abgefragt, der als Teil von Monitoring V2 namens PushProx bereitgestellt wird. Für detaillierte Informationen zu PushProx siehe hier und den obigen Abschnitt Architektur.

Die folgenden Kubernetes-Komponenten werden direkt von Prometheus erfasst:

Metriken werden je nach Kubernetes-Distribution unterschiedlich erfasst. Für Hilfe mit der Terminologie siehe hier. Für Details siehe die Tabelle unten: