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.

Voraussetzungen zur API-Nutzung

In einigen der folgenden Abschnitte werden Sie eventuell nctl und kubectl nutzen wollen um mit den nine Prometheus API Ressourcen zu arbeiten. Bevor Sie dies tun sollten Sie sicherstellen, dass Sie erfolgreich auf der API eingeloggt sind und eine Prometheus Instanz selektiert haben, an welcher Sie Änderungen vornehmen wollen. Nach einem erfolgreichen API Login können Sie den kubeconfig Context nineapis.ch nutzen um kubectl Befehle gegen die nine API auszuführen.

Stellen Sie sicher dass Sie kubectl und nctl installiert haben.
Authentifizieren Sie sich gegen unsere API mittels nctl:
```
nctl auth login
```

Sie können 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 angwendet werden sollen. Um die dokumentierten Befehle zu vereinfachen, sollten sie den Namen und das Projekt via einer Umgebungsvariable exportieren.

Erstellen Sie eine Liste aller Prometheus Instanzen und selektieren Sie eine Instanz.

$ nctl get all --kinds=Prometheus -A

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

Exportieren Sie 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 gespeichterten Metriken ihrer Prometheus Instanz zu zugreifen. Sie werden in den folgenden Abschnitten erklärt.

Grafana

Der Zugriff über eine nine managed Grafana Instanz ist unser empfohlener Weg um auf ihre Prometheus Instanz(en) zu zugreifen. Erstellen Sie einfach eine Grafana Instanz und all Ihre 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, müssen Sie zuerst die Zugangsdaten auslesen.

Kubectl
Cockpit

Führen Sie die vorbereitenden Schritte zur API Nutzung aus.
Überprüfen Sie 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 Sie auf die Prometheus Instanz zugreifen können.
```
kubectl get prometheus.observability.nine.ch $PROMNAME \
        --context nineapis.ch \
        -n $PROMPROJECT \
        -o template --template={{.spec.writeConnectionSecretToRef}}
```
Sollten Sie die Ausgabe <no value> erhalten, so müssen Sie noch eine Referenz zu einem "Connection Secret" setzen. Andernfalls können Sie die Zugangsdaten direkt über den weiter unten stehenden kubectl Befehl erhalten.
Falls Sie eine Referenz zu einem "Connection Secret" setzen müssen, so können Sie kubectl dafür nutzen. Im folgenden Beispiel werden wir ein Kubernetes Secret namens 'my-prometheus-connection-details' dafür nutzen. Sie können jedoch auch einen anderen Namen wählen. Stellen Sie 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'"}}}'
```

Sobald die "Connection Secret" Referenz gesetzt ist, können Sie die Zugangsdaten aus dem referenzierten "Connection Secret" auslesen. Falls Sie einen anderen Namen als 'my-prometheus-connection-details' genutzt haben, so sollten Sie 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 können Sie das Prometheus Web UI in einem Browser nun aufrufen.

Interner Zugriff auf Prometheus

Aktivieren des internen Zugriffs

Falls Sie auf ihre Prometheus Instanz von innerhalb ihres NKE Clusters zugreifen wollen, müssen Sie 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 Sie eine selbst verwaltete Grafana Instanz in ihrem Cluster betreiben wollen, welche die Metriken Ihrer Prometheus Instanz darstellen soll.

Kubectl
Cockpit

Führen Sie die vorbereitenden Schritte zur API Nutzung aus.

Konfigurieren Sie den internen Zugriff. Überprüfen Sie 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 Sie der obigen Ausgabe entnehmen können, wurde der Zugriff noch nicht aktiviert (das Feld "enabled" ist auf false gesetzt).

Sobald Sie den internen Zugriff aktivieren, wird jeder Pod des Clusters zu ihrer Prometheus Instanz eine Verbindung aufbauen können. Sie können 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 können Sie der offiziellen Kubernetes Dokumentation entnehmen. Um beispielsweise alle Pods des Namespaces "grafana" zu erlauben, können Sie 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"}}}}}}}'

Sobald Sie den internen Zugriff aktiviert haben, finden Sie 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 können Sie dann benutzen um von den erlaubten Pods des Clusters auf Prometheus zu zugreifen.

Deaktivieren des internen Zugriffs auf Prometheus

Kubectl
Cockpit

Führen Sie die vorbereitenden Schritte zur API Nutzung aus.

Deaktivieren Sie den internen Zugang.

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

Deaktiveren des externen Zugriffs auf Prometheus

Eventuell ist es für Sie erforderlich den externen Zugriff auf das Prometheus Web UI zu deaktivieren. Falls Sie beispielsweise eine selbst verwaltete Grafana Instanz in ihrem Cluster betreiben, welche ausschliesslich Zugriff auf Prometheus haben soll, so können Sie den externen Zugang deaktivieren. Bitte beachten Sie, dass bei deaktiviertem externen Zugriff auch nine verwaltete Grafana Instanzen keinen Zugriff mehr auf ihre Prometheus Instanz haben.

Kubectl
Cockpit

Führen Sie die vorbereitenden Schritte zur API Nutzung aus.

Deaktivieren Sie den externen Zugang.

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

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.

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 finden Sie 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 Ihrer 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 Ihrem 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, verwenden Sie 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, sollten Sie prometheus.demo.do.prometheus.io:9090 im Feld targets eingeben.

Für weitere Details lesen Sie 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 finden Sie 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, Ihre 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, können Sie die Ziel-Liste der Endpunkte verlieren. Weitere Informationen finden Sie in der Anforderungen an HTTP-SD-Endpunkte Dokumentation.

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

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.

Dokumentation und Links

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.

Verfügbarkeit​

Nutzung​

Allgemeine Informationen zum Setup​

Exporter und Metriken​

Voraussetzungen zur API-Nutzung​

Login​

Selektieren einer Prometheus Instanz​

Zugriff auf Metriken​

Grafana​

Prometheus Webinterface​

Interner Zugriff auf Prometheus​

Aktivieren des internen Zugriffs​

Deaktivieren des internen Zugriffs auf Prometheus​

Deaktiveren des externen Zugriffs auf Prometheus​

Instrumentierung Ihrer Applikation​

Prometheus Applikations-Metriken hinzufügen​

Verwendung von ScrapeConfig zum Scrapen eines externen Ziels​

Beispiel für static_config​

Beispiel für http_sd​

Abfragen von Metriken​

Regeln zu Prometheus hinzufügen​

Dokumentation und Links​

Videoanleitungen​

Verfügbarkeit

Nutzung

Allgemeine Informationen zum Setup

Exporter und Metriken

Voraussetzungen zur API-Nutzung

Login

Selektieren einer Prometheus Instanz

Zugriff auf Metriken

Grafana

Prometheus Webinterface

Interner Zugriff auf Prometheus

Aktivieren des internen Zugriffs

Deaktivieren des internen Zugriffs auf Prometheus

Deaktiveren des externen Zugriffs auf Prometheus

Instrumentierung Ihrer Applikation

Prometheus Applikations-Metriken hinzufügen

Verwendung von ScrapeConfig zum Scrapen eines externen Ziels

Beispiel für `static_config`

Beispiel für `http_sd`

Abfragen von Metriken

Regeln zu Prometheus hinzufügen

Dokumentation und Links

Videoanleitungen