Zum Hauptinhalt springen

Prometheus

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

Verfügbarkeit​

note

Der Nachfolger von Prometheus ist der Metrics Agent und wir empfehlen, diesen stattdessen für neue Setups zu verwenden. Wir planen den Übergang zum Metrics Agent, da dieser das Prometheus-Produkt langfristig ersetzen wird.

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 findest du in den folgenden Abschnitten.

Allgemeine Informationen zum Setup​

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

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

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

  • ServiceMonitors
  • PodMonitors
  • PrometheusRules

Es ist möglich, mehrere Prometheus Instanzen in deinem Cluster zu betreiben, wenn du dies benötigst.

Exporter und Metriken​

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

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

Aktuell musst du uns mitteilen, welchen dieser Exporter du nutzen möchtest. Zukünftig wirst du diese selbst im Cockpit aktivieren können.

Bitte beachte, dass die Aktivierung aller Metriken eines Exporters den Ressourcenverbrauch des Prometheus-Betriebs erhöht. Um dieses Problem zu umgehen, kannst du auch die Anzahl an getrackten Metriken begrenzen, indem du uns eine explizite Liste der gewünschten Metriken zukommen lässt.

Zusammenfassend empfehlen wir den folgenden Workflow:

  • Teile uns mit, welche Exporter wir aufsetzen sollen und wir aktivieren alle Metriken des jeweiligen Exporters für dich.
  • Erstelle deine Dashboards/Regeln
  • Schau, welche Metriken du brauchst, und teile uns dies mit. Wir werden die Scraping-Konfiguration anpassen, sodass nur die von dir benötigten Metriken durchsucht werden.

Voraussetzungen zur API-Nutzung​

In einigen der folgenden Abschnitte wirst du eventuell nctl und kubectl nutzen wollen um mit den nine Prometheus API Ressourcen zu arbeiten. Bevor du dies tust, solltest du sicherstellen, dass du erfolgreich auf der API eingeloggt bist und eine Prometheus Instanz selektiert hast, an welcher du Änderungen vornehmen willst. Nach einem erfolgreichen API Login kannst du den kubeconfig Context nineapis.ch nutzen um kubectl Befehle gegen die nine API auszuführen.

Login​

  1. Stelle sicher, dass du kubectl und

    nctl installiert hast.

  2. Authentifiziere dich gegen unsere API mittels nctl:

    nctl auth login

  3. Du kannst nun kubectl Befehle gegen die API ausführen.

    kubectl --context nineapis.ch get prometheus.observability.nine.ch

Selektieren einer Prometheus Instanz​

Alle kubectl API Befehle benötigen den Namen und das Projekt einer Prometheus Ressource, auf die sie angewendet werden sollen. Um die dokumentierten Befehle zu vereinfachen, solltest du den Namen und das Projekt via einer Umgebungsvariable exportieren.

  1. Erstelle eine Liste aller Prometheus Instanzen und wähle eine Instanz aus.

    $ nctl get all --kinds=Prometheus -A

    PROJECT    NAME                  KIND          GROUP
    acme       example               Prometheus    observability.nine.ch
    acme-prod  production            Prometheus    observability.nine.ch

  2. Exportiere den Namen und das Projekt der Instanz in Umgebungsvariablen.

    export PROMNAME=example PROMPROJECT=acme

Zugriff auf Metriken​

Es gibt verschiedene Möglichkeiten um auf die gespeicherten Metriken deiner Prometheus Instanz zuzugreifen. Diese werden in den folgenden Abschnitten erklärt.

Grafana​

Der Zugriff über eine nine managed Grafana Instanz ist unser empfohlener Weg um auf deine Prometheus Instanz(en) zuzugreifen. Erstelle einfach eine Grafana Instanz und all deine Prometheus Instanzen werden automatisch darin als Datenquellen zur Verfügung stehen.

Prometheus Webinterface​

Jede Prometheus Instanz bietet die Möglichkeit über ein Web UI von ausserhalb des Clusters auf die Metriken zu zugreifen. Der Zugang ist dabei über Basic Authentifizierung gesichert. Um auf die Instanz zugreifen zu können, musst du zuerst die Zugangsdaten auslesen.

  1. Führe die vorbereitenden Schritte zur API Nutzung aus.

  2. Überprüfe ob bereits eine Referenz zu einem "Connection Secret" gesetzt wurde. Ein referenziertes "Connection Secret" enthält die externe URL, den Basic Auth Nutzernamen und das Basic Auth Passwort, mit dem du auf die Prometheus Instanz zugreifen kannst.

    kubectl get prometheus.observability.nine.ch $PROMNAME \
            --context nineapis.ch \
            -n $PROMPROJECT \
            -o template --template={{.spec.writeConnectionSecretToRef}}

    Solltest du die Ausgabe <no value> erhalten, so musst du noch eine Referenz zu einem "Connection Secret" setzen. Andernfalls kannst du die Zugangsdaten direkt über den weiter unten stehenden kubectl Befehl erhalten.

  3. Falls du eine Referenz zu einem "Connection Secret" setzen musst, so kannst du kubectl dafür nutzen. Im folgenden Beispiel werden wir ein Kubernetes Secret namens 'my-prometheus-connection-details' dafür nutzen. Du kannst jedoch auch einen anderen Namen wählen. Stelle dabei bitte sicher, dass der gewählte Name nicht bereits in der Ausgabe des Befehls kubectl --context=nineapis.ch get secret -n $PROMPROJECT vorhanden ist.

    kubectl patch prometheus.observability.nine.ch $PROMNAME \
            --context nineapis.ch \
            -n $PROMPROJECT \
            --type=merge -p '{"spec":{"writeConnectionSecretToRef":{"name":"my-prometheus-connection-details","namespace":"'$PROMPROJECT'"}}}'

  4. Sobald die "Connection Secret" Referenz gesetzt ist, kannst du die Zugangsdaten aus dem referenzierten "Connection Secret" auslesen. Falls du einen anderen Namen als 'my-prometheus-connection-details' genutzt hast, so solltest du diesen im nachfolgenden Befehl verwenden.

    # auslesen der externen URL
    kubectl get secret my-prometheus-connection-details \
            --context nineapis.ch \
            -n $PROMPROJECT \
            -o jsonpath='{.data.url}' | base64 --decode
    # auslesen des Basic Auth Nutzernamens
    kubectl get secret my-prometheus-connection-details \
            --context nineapis.ch \
            -n $PROMPROJECT \
            -o jsonpath='{.data.basicAuthUsername}' | base64 --decode
    # auslesen des Basic Auth Passworts
    kubectl get secret my-prometheus-connection-details \
            --context nineapis.ch \
            -n $PROMPROJECT \
            -o jsonpath='{.data.basicAuthPassword}' | base64 --decode

    Mit den erhaltenen Zugangsdaten kannst du das Prometheus Web UI in einem Browser nun aufrufen.

Interner Zugriff auf Prometheus​

Aktivieren des internen Zugriffs​

Falls du auf deine Prometheus Instanz von innerhalb deines NKE Clusters zugreifen willst, musst du zuerst den internen Zugriff konfigurieren. Da der interne Zugriff keine Authentifizierung benötigt, ist er standardmässig deaktiviert. Ein Anwendungsfall für den internen Zugriff wäre, wenn du eine selbst verwaltete Grafana Instanz in deinem Cluster betreiben willst, welche die Metriken deiner Prometheus Instanz darstellen soll.

  1. Führe die vorbereitenden Schritte zur API Nutzung aus.

  2. Konfiguriere den internen Zugriff. Überprüfe zuerst ob der interne Zugriff bereits aktiviert wurde.

    $ kubectl get prometheus.observability.nine.ch $PROMNAME \
            --context nineapis.ch \
            -n $PROMPROJECT \
            -o jsonpath='{.spec.forProvider.access.internal}'

    {"enabled":false,"namespaceSelector":{},"podSelector":{}}

    Wie du der obigen Ausgabe entnehmen kannst, wurde der Zugriff noch nicht aktiviert (das Feld "enabled" ist auf false gesetzt).

  3. Sobald du den internen Zugriff aktivierst, wird jeder Pod des Clusters zu deiner Prometheus Instanz eine Verbindung aufbauen können. Du kannst jedoch mit den Feldern "namespaceSelector" und "podSelector" eine Einschränkung vornehmen. Diese Felder enthalten Schlüssel-Wert Paare welche Namespaces und/oder Pods anhand von Labels selektieren. Ein leerer "namespaceSelector" selektiert dabei alle Namespaces des Clusters. Ein leerer "podSelector" wählt alle Pods aus allen Namespaces welche mit dem "namespaceSelector" Feld selektiert wurden aus. Weitere Informationen über Labels und Selektoren kannst du der offiziellen Kubernetes Dokumentation entnehmen. Um beispielsweise alle Pods des Namespaces "grafana" zu erlauben, kannst du das spezielle Label kubernetes.io/metadata.name nutzen, welches standardmässig an jeden Namespace angehangen wird. Es enthält dabei den Namen des Namespaces als Wert.

    Hier einige Beispiele um den internen Zugriff für bestimmte Pods zu erlauben.

    # Zugriff auf Prometheus von allen Pods des Clusters erlauben
    kubectl patch prometheus.observability.nine.ch $PROMNAME \
            --context nineapis.ch \
            -n $PROMPROJECT \
            --type=merge -p '{"spec":{"forProvider":{"access":{"internal":{"enabled":true}}}}}'
    # Zugriff für alle Pods des Namespaces "grafana" erlauben
    kubectl patch prometheus.observability.nine.ch $PROMNAME \
            --context nineapis.ch \
            -n $PROMPROJECT \
            --type=merge -p '{"spec":{"forProvider":{"access":{"internal":{"enabled":true,"namespaceSelector":{"matchLabels":{"kubernetes.io/metadata.name":"grafana"}}}}}}}'
    # Zugriff für Pods aus dem Namespace 'grafana' erlauben, welche das Label 'app:grafana' tragen
    kubectl patch prometheus.observability.nine.ch $PROMNAME \
            --context nineapis.ch \
            -n $PROMPROJECT \
            --type=merge -p '{"spec":{"forProvider":{"access":{"internal":{"enabled":true,"namespaceSelector":{"matchLabels":{"kubernetes.io/metadata.name":"grafana"}},"podSelector":{"matchLabels":{"app":"grafana"}}}}}}}'

  4. Sobald du den internen Zugriff aktiviert hast, findest du die interne URL um auf Prometheus zu zugreifen im Status der Prometheus Ressource.

    $ kubectl get prometheus.observability.nine.ch $PROMNAME \
            --context nineapis.ch \
            -n $PROMPROJECT \
            -o jsonpath='{.status.atProvider.internalURL}'

    http://prometheus-internal-3343791.nine-system.svc.cluster.local:9090

    Diese URL kannst du dann benutzen um von den erlaubten Pods des Clusters auf Prometheus zu zugreifen.

Deaktivieren des internen Zugriffs auf Prometheus​

  1. Führe die vorbereitenden Schritte zur API Nutzung aus.

  2. Deaktiviere den internen Zugang.

    kubectl patch prometheus.observability.nine.ch $PROMNAME \
            --context nineapis.ch \
            -n $PROMPROJECT \
            --type=merge -p '{"spec":{"forProvider":{"access":{"internal":{"enabled":false}}}}}'
Deaktivieren des externen Zugriffs auf Prometheus​

Eventuell ist es für dich erforderlich den externen Zugriff auf das Prometheus Web UI zu deaktivieren. Falls du beispielsweise eine selbst verwaltete Grafana Instanz in deinem Cluster betreibst, welche ausschliesslich Zugriff auf Prometheus haben soll, so kannst du den externen Zugang deaktivieren. Bitte beachte, dass bei deaktiviertem externen Zugriff auch nine verwaltete Grafana Instanzen keinen Zugriff mehr auf deine Prometheus Instanz haben.

  1. Führe die vorbereitenden Schritte zur API Nutzung aus.

  2. Deaktiviere den externen Zugang.

    kubectl patch prometheus.observability.nine.ch $PROMNAME \
            --context nineapis.ch \
            -n $PROMPROJECT \
            --type=merge -p '{"spec":{"forProvider":{"access":{"noExternalAccess":true}}}}'

Instrumentierung deiner Applikation​

Bevor Prometheus Metriken aus deiner Applikation ziehen kann, musst du deine Applikation instrumentieren, um den Metriken-Export in einem speziell vorgegebenen Format zu ermöglichen. Informationen zur Vorgehensweise findest du in der offiziellen Prometheus Dokumentation.

Prometheus Applikations-Metriken hinzufügen​

Sobald deine Applikation Metriken unterstützt, kannst du 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 musst du 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 dein ServiceMonitor auch das Label prometheus.nine.ch/<your prometheus name>: scrape mit dem Namen deiner Prometheus Instanz haben. Im Folgenden findest du 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). Du kannst die PodMonitor Ressource nutzen, wenn deine 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 du definierst. 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.

Verwendung von ScrapeConfig zum Scrapen eines externen Ziels​

Die ScrapeConfig CRD kann verwendet werden, um Ziele ausserhalb des Kubernetes-Clusters zu scrapen oder um Scrape-Konfigurationen zu erstellen, die mit höherwertigen Ressourcen wie ServiceMonitor oder PodMonitor nicht erreichbar sind. Derzeit unterstützt ScrapeConfig eine begrenzte Anzahl von Service-Discovery-Mechanismen.

Obwohl zahlreiche Optionen verfügbar sind (eine umfassende Liste findest du in der API-Dokumentation), unterstützen wir derzeit nur static_config und http_sd Konfigurationen. Die CRD entwickelt sich ständig weiter (derzeit im v1alpha1-Stadium), wobei regelmässig neue Funktionen und Unterstützung für zusätzliche Service-Discoveries hinzugefügt werden. Wir müssen sorgfältig bestimmen, welche Felder nützlich sind und langfristig beibehalten werden müssen.

note

Das Hinzufügen von Zielen zu deiner Prometheus-Instanz kann die Ressourcennutzung beeinflussen. Wenn die Anzahl der Ziele oder die Kardinalität der Metriken zunimmt, kann es notwendig werden, die Ressourcen oder die Anzahl der Management-Nodes in deinem Cluster zu skalieren, um den erhöhten Ressourcenbedarf zu decken.

Beispiel für static_config​

Das folgende Beispiel bietet eine grundlegende Konfiguration und deckt nicht alle unterstützten Optionen ab. Zum Beispiel, um das Ziel unter http://prometheus.demo.do.prometheus.io:9090 zu scrapen, verwende die folgende Konfiguration:

apiVersion: monitoring.coreos.com/v1alpha1
kind: ScrapeConfig
metadata:
  name: my-static-config
  namespace: my-namespace
  labels:
    prometheus.nine.ch/myprom01: scrape
spec:
  staticConfigs:
    - labels:
        job: prometheus
      targets:
        - prometheus.demo.do.prometheus.io:9090
note

Das Ziel muss als Hostname angegeben werden, nicht als HTTP(S)-URL. Um beispielsweise das Ziel unter http://prometheus.demo.do.prometheus.io:9090 zu scrapen, solltest du prometheus.demo.do.prometheus.io:9090 im Feld targets eingeben.

Für weitere Details lies die Konfigurationsdokumentation und die API-Dokumentation.

Beispiel für http_sd​

Die HTTP-basierte Service-Discovery bietet eine allgemeinere Möglichkeit, statische Ziele zu konfigurieren, und dient als Interface zum Einbinden benutzerdefinierter Service-Discovery-Mechanismen.

Es ruft Ziele von einem HTTP-Endpunkt ab, der eine Liste von null oder mehr static_configs enthält. Das Ziel muss mit einer HTTP-200 antworten. Der HTTP-Header Content-Type muss application/json sein, und der Body muss gültiges JSON sein. Die Antwort muss im UTF-8-Format vorliegen. Wenn keine Ziele übertragen werden sollen, muss auch eine HTTP-200-Antwort mit einer leeren Liste [] gesendet werden. Ziel-Listen sind ungeordnet. Weitere Informationen findest du in den Anforderungen an HTTP-SD-Endpunkte. Im Allgemeinen sieht der Inhalt der Antwort wie folgt aus:

[
  {
    "targets": [ "<host>", ... ],
    "labels": {
      "<labelname>": "<labelvalue>", ...
    }
  },
  ...
]

Beispiel für eine Antwort:

[
  {
    "targets": ["prometheus.demo.do.prometheus.io:9090"],
    "labels": {
      "job": "prometheus",
      "__meta_test_label": "test_label1"
    }
  }
]
note

Die URL zur HTTP-SD wird nicht als Geheimnis betrachtet. Die Authentifizierung und alle API-Schlüssel sollten mit den entsprechenden Authentifizierungsmechanismen übergeben werden. Prometheus unterstützt TLS-Authentifizierung, Basic-Authentifizierung, OAuth2 und Autorisierungs-Header.

Der Endpunkt wird regelmässig im angegebenen Aktualisierungsintervall abgefragt.

Die gesamte Liste der Ziele muss bei jedem Scrape zurückgegeben werden. Es gibt keine Unterstützung für inkrementelle Updates. Eine Prometheus-Instanz sendet ihren Hostnamen nicht, und es ist nicht möglich, dass ein SD-Endpunkt weiss, ob die SD-Anfragen die ersten nach einem Neustart sind oder nicht.

Jedes Ziel hat ein Meta-Label __meta_url während der Relabeling-Phase. Der Wert ist auf die URL gesetzt, von der das Ziel extrahiert wurde.

Ein einfaches Beispiel:

apiVersion: monitoring.coreos.com/v1alpha1
kind: ScrapeConfig
metadata:
  name: my-http-sd
  namespace: my-namespace
  labels:
    prometheus.nine.ch/myprom01: scrape
spec:
  httpSDConfigs:
    - url: http://my-external-api/discovery
      refreshInterval: 15s

Prometheus cached Ziel-Listen und verwendet die aktuelle Liste weiterhin, wenn ein Fehler beim Abrufen einer aktualisierten Liste auftritt. Die Ziel-Listen werden jedoch nicht über Neustarts hinweg beibehalten. Daher ist es entscheidend, deine HTTP-SD-Endpunkte auf Ausfallzeiten zu überwachen. Während eines Neustarts von Prometheus, der während unseres regelmässigen Wartungsfensters auftreten kann, wird der Cache geleert. Wenn die HTTP-SD-Endpunkte zu diesem Zeitpunkt ebenfalls nicht erreichbar sind, kannst du die Ziel-Liste der Endpunkte verlieren. Weitere Informationen findest du in der Anforderungen an HTTP-SD-Endpunkte Dokumentation.

Für weitere Details lies die Konfigurationsdokumentation und die API-Dokumentation.

Abfragen von Metriken​

Du kannst 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 stelle bitte sicher, dass du die Datenquellen auswählst, die zu deiner 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 du datenintensive Abfragen in Dashboards verwenden. Um diese zu beschleunigen, kannst du eine Recording Rule erstellen, welche die Abfrage in einem vordefinierten Intervall evaluiert und das Resultat als neue Metrik speichert. Du kannst die neue Metrik dann in deinen Dashboard-Abfragen verwenden.

Alerting Rules ermöglichen es dir, (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 du Alerting oder Recording Rules erstellst, stelle bitte sicher, dass das Label prometheus.nine.ch/<your prometheus name>: scrape den Namen deiner Prometheus Instanz enthält. Damit wird die erstellte Regel zu deiner 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 deine Benachrichtigungen und deren Kommunikationskanäle zu definieren.

Die vollständige Spezifikation der PrometheusRule findest du in der prometheus-operator API-Referenz.

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​

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