Zum Hauptinhalt springen

Prometheus

Prometheus ist ein Bestandteil von NKE, der Ihnen die Überwachung Ihrer Applikationen ermöglicht.

Verfügbarkeit

Prometheus ist als optionaler Service für NKE verfügbar und kann im Cockpit auf einem bestehenden NKE Cluster erstellt werden.

Nutzung

Eine Erklärung zur Nutzung von Prometheus finden Sie in den folgenden Abschnitten.

Allgemeine Informationen zum Setup

Wenn Prometheus bestellt wird, wird eine neue Prometheus-Instanz mit zwei Replikaten in Ihren NKE Cluster im nine-system Namespace deployed. Die Pods werden auf den Control-Plane Nodes laufen, sodass Ihre Node-Pools vollständig für Ihre Applikationen zur Verfügung stehen.

Ausserdem wird eine neue Grafana-Datenquelle erstellt und automatisch in Ihrer Grafana Instanz registriert (insofern Sie eine Grafana Instanz deployed haben).

Die Prometheus Instanz basiert auf dem Prometheus-Operator Project. Daher können Sie die folgenden Ressourcen nutzen, um Scraping-Konfigurationen und Aufzeichnungs-/Benachrichtigungsregeln zu erstellen:

  • ServiceMonitors
  • PodMonitors
  • PrometheusRules

Es ist möglich, mehrere Prometheus Instanzen in Ihrem Cluster zu betreiben, wenn Sie dies benötigen.

Exporter und Metriken

Prometheus enthält auch einige vorkonfigurierte Exporter für Metriken:

  • CertManager
  • IngressNginx
  • NodeExporter
  • Kubelet
  • Kubelet cAdvisor
  • KubeStateMetrics
  • NineControllers
  • Velero

Aktuell müssen Sie uns mitteilen, welchen dieser Exporter Sie nutzen möchten. Zukünftig werden Sie diese selbst im Cockpit aktivieren können.

Bitte beachten Sie, dass die Aktivierung aller Metriken eines Exporters den Ressourcenverbrauch des Prometheus-Betriebs erhöht. Um dieses Problem zu umgehen, können Sie auch die Anzahl an getrackten Metriken begrenzen, indem Sie uns eine explizite Liste der gewünschten Metriken zukommen lassen.

Zusammenfassend empfehlen wir den folgenden Workflow:

  • Teilen Sie uns mit, welche Exporter wir aufsetzen sollen und wir aktivieren alle Metriken des jeweiligen Exporters für Sie.
  • Erstellen Sie Ihre Dashboards/Regeln
  • Schauen Sie, welche Metriken Sie brauchen, und teilen Sie uns dies mit. Wir werden die Scraping-Konfiguration anpassen, sodass nur die von Ihnen benötigten Metriken durchsucht werden.

Web UI

Die standardmässige Prometheus Web UI steht nicht mehr zur Verfügung. Allerdings können Sie Grafana nutzen, um Ihre Metriken im Webbrowser anzusehen.

Instrumentierung Ihrer Applikation

Bevor Prometheus Metriken aus Ihrer Applikation ziehen kann, müssen Sie Ihre Applikation instrumentieren, um den Metriken-Export in einem speziell vorgegebenen Format zu ermöglichen. Informationen zur Vorgehensweise finden Sie in der offiziellen Prometheus Dokumentation.

Prometheus Applikations-Metriken hinzufügen

Sobald Ihre Applikation Metriken unterstützt, können Sie ServiceMonitors oder PodMonitors nutzen, um mit Prometheus die Applikations-Metriken zu durchsuchen.

ServiceMonitors durchsuchen alle Pods, auf die ein oder mehrere Services abzielen. Diese Ressource muss in den meisten Fällen genutzt werden. Dazu müssen Sie einen Label Selector im ServiceMonitor definieren, der dazu genutzt wird, alle gewünschten Services zu finden. Der ServiceMonitor sollte im gleichen Namespace erstellt werden wie der/die Service(s), die er auswählt. Neben dem Label Selector sollte Ihr ServiceMonitor auch das Label prometheus.nine.ch/<your prometheus name>: scrape mit dem Namen Ihrer Prometheus Instanz haben. Im Folgenden finden Sie Beispiel-Definitionen für ServiceMonitor und Service:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: my-app
namespace: my-app
labels:
prometheus.nine.ch/myprom01: scrape
spec:
selector:
matchLabels:
app: my-app
endpoints:
- port: web
kind: Service
apiVersion: v1
metadata:
name: my-app-service
namespace: my-app
labels:
app: my-app
spec:
selector:
application: example-app
ports:
- name: web
port: 8080

Die vorgegebene ServiceMonitor Definition wählt den Service "my-app-service" aus, da das Label "app: my-app" auf diesem Service existiert. Prometheus sucht dann nach allen Pods, auf die dieser Service abzielt und beginnt, sie nach Metriken auf dem Port 8080 (der ServiceMonitor definiert den Port im Feld endpoints) zu durchsuchen.

PodMonitors durchsuchen alle Pods, die vom vorgegebenen Label Selector ausgewählt wurden. Das funktioniert sehr ähnlich wie bei der ServiceMonitor Ressource (nur ohne tatsächliche Service Ressource). Sie können die PodMonitor Ressource nutzen, wenn Ihre Applikation aus sonstigen Gründen keine Service Ressource benötigt (wie einige Exporter). Die Pods sollten im gleichen Namespace laufen, in dem auch der PodMonitor definiert wird. Es folgt ein Beispiel für einen PodMonitor mit einem entsprechenden Pod:

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
name: my-pods
namespace: my-app
labels:
prometheus.nine.ch/myprom01: scrape
spec:
selector:
matchLabels:
application: my-app
endpoints:
- port: web
apiVersion: v1
kind: Pod
metadata:
labels:
application: my-app
name: my-app
namespace: my-app
spec:
containers:
- image: mycompany/example-app
name: app
ports:
name: web
containerPort: 8080

Basierend auf der vorgegebenen PodMonitor Ressource generiert der Prometheus-Operator eine Scraping-Konfiguration, welche den gezeigten Pod "my-app" auf dem Port 8080 nach Metriken durchsucht.

Prometheus erstellt einen job für jede ServiceMonitor oder PodMonitor Ressource, die Sie definieren. Zu allen durchsuchten Metriken, die im dazugehörigen Job gesammelt wurden, wird auch ein job Label hinzugefügt. Das Label kann genutzt werden, um herauszufinden, aus welchen Services oder Pods eine bestimmte Metrik extrahiert wurde.

Abfragen von Metriken

Sie können PromQL nutzen, um Metriken anzufragen. Hierzu gibt es einige Beispiele auf der offiziellen Prometheus Seite. Die Abfrage kann mit Grafana in der Explore Ansicht getätigt werden. Bei Benutzung von Grafana stellen Sie bitte sicher, dass Sie die Datenquellen auswählen, die zu Ihrer Prometheus Instanz gehören. Der Name der Datenquelle ist <YOUR PROMETHEUS NAME>/<YOUR ORG NAME>/prometheus.

Regeln zu Prometheus hinzufügen

Prometheus unterstützt zwei Arten von Regeln: recording rules und alerting rules. Beide haben zwar eine ähnliche Syntax, aber unterschiedliche Anwendungsbereiche.

Recording Rules können verwendet werden, um neue Metriken basierend auf bereits existierenden zu berechnen. Das kann hilfreich sein, wenn Sie datenintensive Abfragen in Dashboards verwenden. Um diese zu beschleunigen, können Sie eine Recording Rule erstellen, welche die Abfrage in einem vordefinierten Intervall evaluiert und das Resultat als neue Metrik speichert. Sie können die neue Metrik dann in Ihren Dashboard-Abfragen verwenden.

Alerting Rules ermöglichen es Ihnen, (basierend auf PromQL) die Bedingungen für Warnungen zu definieren. Wenn diese Bedingungen erfüllt sind, sendet Prometheus eine Warnung an die verbundenen Alertmanager Instanzen. Der Alertmanager benachrichtigt dann die Nutzer über diese Warnungen.

Wenn Sie Alerting oder Recording Rules erstellen, stellen Sie bitte sicher, dass das Label prometheus.nine.ch/<your prometheus name>: scrape den Namen Ihrer Prometheus Instanz enthält. Damit wird die erstellte Regel zu Ihrer Prometheus Instanz hinzugefügt.

Das folgende Beispiel zeigt eine Alerting Rule, die eine Warnung versendet, wenn ein Job nicht mehr länger die konfigurierten Pods (Ziele) erreicht.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
labels:
prometheus.nine.ch/myprom01: scrape
role: alert-rules
name: jobs-check
spec:
groups:
- name: ./example.rules
rules:
- alert: InstanceDown
expr: up == 0
for: 5m
labels:
severity: Critical
annotations:
summary: "Instance {{ $labels.instance }} down"
description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes."

Die Definition dieser Alerting Rule führt zu einer Warnung, wenn eine up Metrik den Wert 0 erhält. Bei der up Metrik handelt es sich um eine besondere Metrik, da sie von Prometheus selbst jedem Job-Ziel (Pod) hinzugefügt wird. Sobald ein Pod nicht mehr durchsucht werden kann, wechselt der Wert der up Metrik auf 0. Wenn die up Metrik (in diesem Fall) mehr als 5 Minuten lang 0 beträgt, löst Prometheus eine Warnung aus. Die vorgegebenen "Labels" und "Annotations" können im Altertmanager genutzt werden, um Ihre Benachrichtigungen und deren Kommunikationskanäle zu definieren.

Die kompletten Spezifikationen für die PrometheusRule Definition finden Sie hier.

Es folgt ein Beispiel für eine Recording Rule:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
labels:
prometheus.nine.ch/myprom01: scrape
role: recording-rules
name: cpu-per-namespace-recording
spec:
groups:
- name: ./example.rules
rules:
- record: namespace:container_cpu_usage_seconds_total:sum_rate
expr: sum(rate(container_cpu_usage_seconds_total{job="kubelet", metrics_path="/metrics/cadvisor", image!="", container!="POD"}[5m])) by (namespace)

Diese Recording Rule erstellt eine neue Metrik mit dem Namen namespace:container_cpu_usage_seconds_total:sum_rate, welche die Summe der genutzten CPU aller Container pro Namespace zeigt. Diese Metrik kann sehr einfach in einem Grafana Dashboard angezeigt werden, um einen Überblick über die CPU-Nutzung aller Pods pro Namespace zu gewinnen.

Das Kubernetes-mixins Project enthält Beispiel-Warnungen und -Regeln für unterschiedliche Exporter. Es eignet sich gut als Inspirationsquelle für Alerting und Recording Rules.

Videoanleitungen

Sehen Sie sich unsere Videoanleitungen für die GKE Applikations-Überwachung an. Die Videos basieren zwar auf unserem GKE-Produkt, die Konzepte sind allerdings die gleichen.