Zum Hauptinhalt springen

Metrics Agent

Metrics Agent ist eine Komponente von NKE, die zur Überwachung von Anwendungen verwendet wird. Es ist der Nachfolger der Lösung basierend auf dem Prometheus Produkt.

Verwendung​

Eine neue Metrics Agent Instanz wird bei der Erstellung im nine-system Namespace bereitgestellt. 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.

Die Konfiguration wird über prometheus-operator project Ressourcen verwaltet. Die folgenden Ressourcentypen werden für Scraping-Konfigurationen, Alerting- und Recording-Rules verwendet:

  • ServiceMonitors
  • PodMonitors
  • PrometheusRules

Metriken werden gesammelt und an einen externen Metrics Cluster gesendet. Dies entlastet die Ressourcen der NKE Cluster Control-Plane im Vergleich zum vorherigen Prometheus Produkt.

Exporter und Metriken​

Ein Satz von Standardmetriken wird automatisch gesammelt. Zusätzliche Metriken von den folgenden Exportern können optional aktiviert werden:

  • 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

Grafana Alerting wird derzeit bei Verwendung von Metrics Agent nicht unterstützt. Bitte verwenden Sie stattdessen den Alertmanager.

Erstellen Sie eine Grafana Instanz, um Metriken zu visualisieren.

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

Wenn die Instanz in einem anderen Projekt erstellt wird, sind nur Metriken desselben Projekts sichtbar.

Instrumentierung Ihrer Anwendung​

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

Sobald die Unterstützung für Metriken hinzugefügt wurde, werden ServiceMonitors oder PodMonitors verwendet, um das Scraping zu konfigurieren.

ServiceMonitors scrapen alle Pods, die von einem oder mehreren Services angesprochen werden. Diese Ressource wird in den meisten Fällen verwendet. Ein Label-Selektor muss im ServiceMonitor definiert werden, um die gewünschten Services zu finden. Der ServiceMonitor sollte im selben Namespace erstellt werden wie die Services, die er auswählt. Zusätzlich zum Label-Selektor muss der ServiceMonitor das Label prometheus.nine.ch/<Name Ihres Metrics Agent>: scrape mit dem Namen der Metrics Agent Instanz haben. 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). Die PodMonitor Ressource kann verwendet werden, wenn die Anwendung keine Service Ressource benötigt (wie einige Exporter). Die Pods sollten im selben Namespace laufen, in dem der PodMonitor definiert ist. 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. Ein Job-Label wird zu allen gescrapten Metriken hinzugefügt, die im entsprechenden Job gesammelt wurden. Dies kann verwendet werden, um zu identifizieren, von welchen Services oder Pods eine bestimmte Metrik gescrapt wurde.

Externe Ziele Scrapen​

Die ScrapeConfig CRD wird verwendet, 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), wobei regelmässig neue Funktionen und Unterstützung für zusätzliche Service-Discoveries hinzugefügt werden.

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

Das Ziel muss als Hostname angegeben werden, 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 mit einer HTTP-200 Antwort 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 ebenfalls HTTP 200 ausgegeben werden, mit einer leeren Liste []. 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 URL zur HTTP SD gilt nicht als geheim. Authentifizierung und alle API-Schlüssel sollten mit den entsprechenden Authentifizierungsmechanismen übergeben werden. Metrics Agent unterstützt TLS-Authentifizierung, Basisauthentifizierung, OAuth2 und Autorisierungsheader.

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

Bei jedem Scrape muss die gesamte Liste der Ziele zurückgegeben werden. Inkrementelle Aktualisierungen werden nicht unterstützt. Eine Metrics Agent Instanz sendet ihren Hostnamen nicht und es ist für einen SD-Endpunkt nicht möglich zu erkennen, ob die SD-Anfrage die erste nach einem Neustart ist oder nicht.

Jedes Ziel hat ein Meta-Label __meta_url während der Relabeling Phase. Sein Wert wird auf die URL gesetzt, 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. Die Zielliste bleibt jedoch nach einem Neustart nicht erhalten. Daher ist es wichtig, Ihre HTTP Service Discovery (HTTP SD) Endpunkte auf Ausfallzeiten zu überwachen. Bei einem Neustart des Metrics Agent, der während regulärer Wartungsfenster erfolgen kann, wird der Cache gelöscht. Wenn zu diesem Zeitpunkt auch die HTTP SD Endpunkte ausgefallen sind, kann die Endpunkt-Zielliste verloren gehen. 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​

PromQL wird verwendet, um Metriken abzufragen. Auf der offiziellen Prometheus-Seite finden Sie einige Beispiele. Abfragen können mit Grafana in der Explore-Ansicht durchgeführt werden. 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 werden verwendet, um aus bereits vorhandenen Metriken neue Metriken zu berechnen. Dies kann nützlich sein für rechenintensive Abfragen in Dashboards. Um diese zu beschleunigen, kann eine Recording Rule erstellt werden, die die Abfrage in einem definierten Intervall auswertet und das Ergebnis als neue Metrik speichert. Diese neue Metrik kann dann in Dashboard-Abfragen verwendet werden.

Alerting Rules werden verwendet, um Alarmbedingungen (basierend auf PromQL) zu definieren. 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 muss das Label prometheus.nine.ch/<Name Ihres Metrics Agent>: scrape mit dem Namen der Metrics Agent Instanz hinzugefügt werden. 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 eine spezielle Metrik, da sie vom Metrics Agent selbst für jedes Jobziel (Pod) hinzugefügt wird. Sobald 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. Die angegebenen „Labels” und „Annotationen” können im Alertmanager verwendet werden, um Benachrichtigungen und Routing-Entscheidungen anzupassen.

Die vollständige Spezifikation für die Definition von PrometheusRule finden Sie hier.

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.

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.