Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03562.jsonl.gz/1568

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.
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.