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.

Verwenden Sie zur Verwaltung der Konfiguration die Ressourcen des [Prometheus-Operators] (https://github.com/coreos/prometheus-operator). Dabei können Sie 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, benennen Sie Ihren Metrics Agent genauso wie Ihre vorhandene Prometheus Instanz. Dadurch entfällt die Notwendigkeit, Labels auf ServiceMonitors und PodMonitors zu aktualisieren.

Wenn Sie derzeit Prometheus verwenden und zu Metrics Agent migrieren möchten, ist der Prozess unkompliziert:

1. Wählen Sie Ihren Kubernetes Cluster im Cockpit aus, öffnen Sie den Tab Metriken und notieren Sie den Namen Ihrer aktuellen Prometheus Instanz.

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

   Wenn Sie einen anderen Namen verwenden, müssen Sie das Label auf Ihren vorhandenen ServiceMonitors und PodMonitors aktualisieren, damit es dem neuen Metrics Agent Namen entspricht. Wenn Ihre Prometheus Instanz beispielsweise prometheus hiess und Sie einen Metrics Agent namens metrics-agent erstellen, ändern Sie das Label von prometheus.nine.ch/prometheus: scrape zu prometheus.nine.ch/metrics-agent: scrape.

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

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

5. Nachdem Sie überprüft haben, dass die Metrikerfassung ordnungsgemäss funktioniert, löschen Sie die alte Prometheus Instanz.

Exporter und Metriken

Der Agent sammelt automatisch einen Satz von Standardmetriken. Sie können optional zusätzliche Metriken von den folgenden Exportern aktivieren:

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

Bitte kontaktieren Sie 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 verwenden Sie stattdessen den Alertmanager.

Erstellen Sie eine Grafana Instanz, um Metriken zu visualisieren.

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

Wenn Sie die Instanz in einem anderen Projekt erstellen, sind nur Metriken desselben Projekts sichtbar.

Instrumentierung Ihrer Anwendung

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

Nachdem Sie Unterstützung für Metriken hinzugefügt haben, verwenden Sie ServiceMonitors oder PodMonitors, um das Scraping zu konfigurieren.

ServiceMonitors scrapen alle Pods, die von einem oder mehreren Services angesprochen werden. Verwenden Sie diese Ressource in den meisten Fällen. Definieren Sie einen Label-Selektor im ServiceMonitor, um die gewünschten Services zu finden. Erstellen Sie den ServiceMonitor im selben Namespace wie die Services, die er auswählt. Setzen Sie zusätzlich zum Label-Selektor das Label prometheus.nine.ch/<Name Ihres Metrics Agent>: scrape mit dem Namen der Metrics Agent Instanz. Betrachten Sie 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). Verwenden Sie die PodMonitor Ressource, wenn die Anwendung keine Service Ressource benötigt (wie einige Exporter). Führen Sie die Pods im selben Namespace aus, in dem Sie den PodMonitor definieren. 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. Verwenden Sie dieses Label, um zu identifizieren, von welchen Services oder Pods eine bestimmte Metrik gescrapt wurde.

Externe Ziele Scrapen

Verwenden Sie 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 finden Sie 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, verwenden Sie 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

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

Weitere Informationen finden Sie 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 finden Sie 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. Übergeben Sie 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.

Geben Sie 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 überwachen Sie Ihre 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, können Sie die Endpunkt-Zielliste verlieren. Weitere Informationen finden Sie in der Dokumentation zu den Anforderungen an HTTP SD-Endpunkte.

Weitere Details finden Sie in der Konfiguration und der API Dokumentation.

Abfragen von Metriken

Verwenden Sie PromQL, um Metriken abzufragen. Auf der offiziellen Prometheus-Seite finden Sie einige Beispiele. Fragen Sie Metriken mit Grafana in der Explore-Ansicht ab. Achten Sie bei der Verwendung von Grafana darauf, die Datenquelle auszuwählen, die zu Ihrer Metrics Agent Instanz passt. Der Name der Datenquelle lautet <IHR 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, erstellen Sie eine Recording Rule, die die Abfrage in einem definierten Intervall auswertet und das Ergebnis als neue Metrik speichert. Verwenden Sie 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ügen Sie das Label prometheus.nine.ch/<Name Ihres 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. Verwenden Sie die angegebenen „Labels" und „Annotationen" im Alertmanager, um Benachrichtigungen und Routing-Entscheidungen anzupassen.

Die vollständige Spezifikation für die Definition von PrometheusRule finden Sie 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.

Dokumentation und Links

• PrometheusRule Dokumentation
• prometheus-operator project

Videoanleitung

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

Teil 1: Die Grundlagen

Teil 2: Service Monitors

Teil 3: Blackbox Exporter