Zum Hauptinhalt springen

Metrics Agent

Metrics Agent ist eine Komponente von NKE, die Anwendungen überwacht. Es ist der Nachfolger der Lösung basierend auf dem Prometheus Produkt.

Verwendung​

NKE stellt bei der Erstellung eine neue Metrics Agent Instanz im nine-system Namespace bereit. Die Pods laufen auf Control-Plane-Nodes, sodass Node Pools vollständig für Anwendungen verfügbar bleiben.

Der Metrics Agent basiert auf Victoria Metrics.

Verwende zur Verwaltung der Konfiguration die Ressourcen des [Prometheus-Operators] (https://github.com/coreos/prometheus-operator). Dabei kannst du die folgenden Ressourcentypen verwenden, um Scraping-Konfigurationen, Alerting- und Recording-Regeln zu konfigurieren:

  • ServiceMonitors
  • PodMonitors
  • PrometheusRules

Der Agent sammelt Metriken und sendet sie an einen externen Metrics Cluster. Dies entlastet die Ressourcen der NKE Cluster Control-Plane im Vergleich zum vorherigen Prometheus Produkt.

Migration von Prometheus​

tip

Um eine nahtlose Migration zu gewährleisten, benenne deinen Metrics Agent genauso wie deine vorhandene Prometheus Instanz. Dadurch entfällt die Notwendigkeit, Labels auf ServiceMonitors und PodMonitors zu aktualisieren.

Wenn du derzeit Prometheus verwendest und zu Metrics Agent migrieren möchtest, ist der Prozess unkompliziert:

  1. Wähle deinen Kubernetes Cluster im Cockpit aus, öffne den Tab Metriken und notiere den Namen deiner aktuellen Prometheus Instanz.

  2. Klicke auf Metrics Agent hinzufügen und definiere den gleichen Namen wie deine vorhandene Prometheus Instanz, damit Metrics Agent automatisch alle vorhandenen ServiceMonitors und PodMonitors ohne Konfigurationsänderungen übernimmt.

    Wenn du einen anderen Namen verwendest, musst du das Label auf deinen vorhandenen ServiceMonitors und PodMonitors aktualisieren, damit es dem neuen Metrics Agent Namen entspricht. Wenn deine Prometheus Instanz beispielsweise prometheus hiess und du einen Metrics Agent namens metrics-agent erstellst, ändere das Label von prometheus.nine.ch/prometheus: scrape zu prometheus.nine.ch/metrics-agent: scrape.

  3. Gib Metrics Agent etwas Zeit, um die Monitore zu entdecken und mit dem Sammeln von Metriken zu beginnen.

  4. Aktualisiere die Datenquelle in Grafana, damit sie auf den neuen Metrics Agent verweist.

  5. Nachdem du überprüft hast, dass die Metrikerfassung ordnungsgemäss funktioniert, lösche die alte Prometheus Instanz.

Exporter und Metriken​

Der Agent sammelt automatisch einen Satz von Standardmetriken. Du kannst optional zusätzliche Metriken von den folgenden Exportern aktivieren:

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

Bitte kontaktiere uns, um spezifische Exporter zu aktivieren. Zukünftige Updates werden eine Selbstbedienungsaktivierung über Cockpit ermöglichen.

Visualisieren von Metriken mit Grafana​

note

Metrics Agent unterstützt derzeit kein Grafana Alerting. Bitte verwende stattdessen den Alertmanager.

Erstelle eine Grafana Instanz, um Metriken zu visualisieren.

Wenn du die Grafana Instanz im Standardprojekt (gleicher Name wie die Organisation) erstellst, sind alle Metriken der Organisation sichtbar.

Wenn du die Instanz in einem anderen Projekt erstellst, sind nur Metriken desselben Projekts sichtbar.

Instrumentierung deiner Anwendung​

Um das Scrapen von Metriken zu ermöglichen, musst du die Anwendung so instrumentieren, dass sie Metriken in einem unterstützten Format exportiert. Details findest du in der offiziellen Prometheus Dokumentation.

Nachdem du Unterstützung für Metriken hinzugefügt hast, verwende ServiceMonitors oder PodMonitors, um das Scraping zu konfigurieren.

ServiceMonitors scrapen alle Pods, die von einem oder mehreren Services angesprochen werden. Verwende diese Ressource in den meisten Fällen. Definiere einen Label-Selektor im ServiceMonitor, um die gewünschten Services zu finden. Erstelle den ServiceMonitor im selben Namespace wie die Services, die er auswählt. Setze zusätzlich zum Label-Selektor das Label prometheus.nine.ch/<Name deines Metrics Agent>: scrape mit dem Namen der Metrics Agent Instanz. Betrachte das folgende Beispiel für die Definition von ServiceMonitor und Service:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: my-app
  namespace: my-app
  labels:
    prometheus.nine.ch/mymetricsagent01: 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 angegebene ServiceMonitor Definition wählt den Service „my-app-service“ aus, da das Label „app: my-app“ auf diesem Service existiert. Der Metrics Agent sucht dann nach allen Pods, die von diesem Service angesprochen werden, und scrapt sie auf Port 8080 nach Metriken (der ServiceMonitor definiert den Port im Feld endpoints).

PodMonitors scrapen alle Pods, die durch den angegebenen Label-Selektor ausgewählt wurden. Dies funktioniert ähnlich wie die ServiceMonitor Ressource (aber ohne tatsächliche Service Ressource). Verwende die PodMonitor Ressource, wenn die Anwendung keine Service Ressource benötigt (wie einige Exporter). Führe die Pods im selben Namespace aus, in dem du den PodMonitor definierst. Hier ist 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/mymetricsagent01: 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 angegebenen PodMonitor Ressource generiert der Metrics Agent eine Scrape-Konfiguration, die den angezeigten Pod „my-app” auf Port 8080 nach Metriken scrapt.

Der Metrics Agent erstellt für jede definierte ServiceMonitor oder PodMonitor Ressource einen Job. Der Agent fügt ein Job-Label zu allen gescrapten Metriken hinzu, die im entsprechenden Job gesammelt wurden. Verwende dieses Label, um zu identifizieren, von welchen Services oder Pods eine bestimmte Metrik gescrapt wurde.

Externe Ziele Scrapen​

Verwende die ScrapeConfig CRD, 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), werden derzeit nur static_config und http_sd Konfigurationen unterstützt. Die CRD entwickelt sich ständig weiter (derzeit im v1alpha1 Stadium) und fügt regelmässig neue Funktionen und Unterstützung für zusätzliche Service-Discoveries hinzu.

Beispiel für static_config​

Das folgende Beispiel bietet eine grundlegende Konfiguration und deckt nicht alle unterstützten Optionen ab. Um beispielsweise das Ziel unter http://metricsagent.demo.do.metricsagent.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/mymetricsagent01: scrape
spec:
  staticConfigs:
    - labels:
        job: metricsagent
      targets:
        - metricsagent.demo.do.metricsagent.io:9090
note

Gib das Ziel als Hostname an, nicht als HTTP(S)-URL. Um beispielsweise das Ziel unter http://metricsagent.demo.do.metricsagent.io:9090 zu scrapen, gib metricsagent.demo.do.metricsagent.io:9090 im Feld targets ein.

Weitere Informationen findest du in der Konfiguration und der API Dokumentation.

Beispiel für http_sd​

Die HTTP-basierte Service-Discovery bietet eine generische Möglichkeit, statische Ziele zu konfigurieren, und dient als Schnittstelle 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 die folgenden Anforderungen erfüllen:

  • Antwort mit HTTP 200
  • HTTP-Header Content-Type auf application/json setzen
  • Gültigen JSON-Body enthalten
  • Antwort in UTF-8 formatieren
  • Wenn keine Ziele existieren, ebenfalls HTTP 200 mit einer leeren Liste [] ausgeben
  • Ziellisten sind ungeordnet

Weitere Informationen findest du unter Anforderungen an HTTP-SD-Endpunkte. Im Allgemeinen lautet der Inhalt der Antwort wie folgt:

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

Beispiel für eine Antwort:

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

Die HTTP SD URL ist nicht geheim. Übergib Authentifizierung und alle API-Schlüssel mit den entsprechenden Authentifizierungsmechanismen. Metrics Agent unterstützt TLS-Authentifizierung, Basisauthentifizierung, OAuth2 und Autorisierungsheader.

Der Endpunkt wird in regelmässigen Abständen mit dem angegebenen Aktualisierungsintervall abgefragt.

Gib bei jedem Scrape die gesamte Liste der Ziele zurück. Metrics Agent unterstützt keine inkrementellen Aktualisierungen. Eine Metrics Agent Instanz sendet ihren Hostnamen nicht und SD-Endpunkte können nicht erkennen, ob die SD-Anfrage die erste nach einem Neustart ist.

Jedes Ziel hat ein Meta-Label __meta_url während der Relabeling Phase. Der Wert enthält die URL, aus 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/mymetricsagent01: scrape
spec:
  httpSDConfigs:
    - url: http://my-external-api/discovery
      refreshInterval: 15s

Der Metrics Agent speichert Ziellisten im Cache und verwendet weiterhin die aktuelle Liste, wenn beim Abrufen einer aktualisierten Liste ein Fehler auftritt. Neustarts erhalten die Zielliste jedoch nicht. Daher überwache deine HTTP Service Discovery (HTTP SD) Endpunkte auf Ausfallzeiten. Bei einem Neustart des Metrics Agent, der während regulärer Wartungsfenster erfolgen kann, löscht der Agent den Cache. Wenn zu diesem Zeitpunkt auch die HTTP SD Endpunkte ausgefallen sind, kannst du die Endpunkt-Zielliste verlieren. Weitere Informationen findest du in der Dokumentation zu den Anforderungen an HTTP SD-Endpunkte.

Weitere Details findest du in der Konfiguration und der API Dokumentation.

Abfragen von Metriken​

Verwende PromQL, um Metriken abzufragen. Auf der offiziellen Prometheus-Seite findest du einige Beispiele. Frage Metriken mit Grafana in der Explore-Ansicht ab. Achte bei der Verwendung von Grafana darauf, die Datenquelle auszuwählen, die zu deiner Metrics Agent Instanz passt. Der Name der Datenquelle lautet <DEIN PROJEKTNAME>/.

Regeln hinzufügen​

Metrics Agent unterstützt zwei Arten von Regeln: Recording Rules und Alerting Rules. Beide haben eine ähnliche Syntax, aber unterschiedliche Anwendungsfälle.

Recording Rules berechnen aus vorhandenen Metriken neue Metriken. Dies ist nützlich für rechenintensive Abfragen in Dashboards. Um diese zu beschleunigen, erstelle eine Recording Rule, die die Abfrage in einem definierten Intervall auswertet und das Ergebnis als neue Metrik speichert. Verwende diese neue Metrik dann in Dashboard-Abfragen.

Alerting Rules definieren Alarmbedingungen (basierend auf PromQL). Wenn diese Bedingungen zutreffen, sendet Metrics Agent einen Alarm an die verbundenen Alertmanager Instanzen. Alertmanager sendet dann Benachrichtigungen über Alarme an die Benutzer.

Beim Erstellen von Alert- oder Recordingrules füge das Label prometheus.nine.ch/<Name deines Metrics Agent>: scrape mit dem Namen der Metrics Agent Instanz hinzu. Dies weist die erstellte Regel der Metrics Agent Instanz zu.

Die folgende Beispiel-Alerting Rule löst einen Alarm aus, sobald ein Job die konfigurierten Pods (Ziele) nicht mehr erreichen kann:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  labels:
    prometheus.nine.ch/mymetricsagent01: 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."

Diese Alerting Rule Definition löst einen Alarm aus, sobald eine up-Metrik den Wert 0 erhält. Die up-Metrik ist speziell, da der Metrics Agent sie selbst für jedes Jobziel (Pod) hinzufügt. Wenn ein Pod nicht mehr gescrapt werden kann, wird die entsprechende up-Metrik auf 0 gesetzt. Wenn die up-Metrik länger als 5 Minuten (in diesem Fall) den Wert 0 hat, löst Metrics Agent eine Warnmeldung aus. Verwende die angegebenen „Labels" und „Annotationen" im Alertmanager, um Benachrichtigungen und Routing-Entscheidungen anzupassen.

Die vollständige Spezifikation für die Definition von PrometheusRule findest du in der prometheus-operator Dokumentation.

Hier ist ein Beispiel für eine Recording Rule:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  labels:
    prometheus.nine.ch/mymetricsagent01: 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 namens „namespace:containercpu_usage_seconds_total:sum_rate“, die die Summe der verwendeten CPU aller Container pro Namespace anzeigt. Diese Metrik kann einfach in einem Grafana-Dashboard angezeigt werden, um einen Überblick über die CPU-Auslastung aller Pods pro Namespace zu erhalten.

Das kubernetes-mixins Projekt enthält Beispielwarnungen und -regeln für verschiedene Exporter. Es ist eine gute Quelle, um sich für Alert- oder Recordingrules inspirieren zu lassen.

Einschränkungen​

Der Metrics Agent ist auf 100'000 Time Series pro Tag begrenzt. Diese Begrenzung verhindert eine Überlastung unseres zentralen Metriken Clusters.

Videoanleitung​

Sieh dir unsere Videoanleitungsserie für GKE Application Monitoring an. Die Videos wurden zwar mit unserem GKE-Produkt mit Prometheus erstellt, die Konzepte sind jedoch dieselben.