Zum Hauptinhalt springen

Metrics Agent

Metrics Agent ist eine Komponente von NKE, mit der Sie Ihre Anwendungen überwachen können. Metrics Agent ist der Nachfolger der bisherigen Lösung, welche auf Prometheus basiert.

Verfügbarkeit​

Metrics Agent ist als optionaler Service für NKE verfügbar und kann über Cockpit auf einem bestehenden NKE-Cluster bereitgestellt werden.

Verwendung​

Eine Erläuterung zur Verwendung von Metrics Agent finden Sie in den folgenden Abschnitten.

Allgemeine Informationen zur Einrichtung​

Wenn ein Metrics Agent erstellt wird, wird eine neue Metrics Agent-Instanz in Ihrem NKE-Cluster im Namespace „nine-system“ bereitgestellt. Die Pods werden auf den Control-Plane-Nodes ausgeführt, sodass Ihre Nodepools vollständig für Ihre Anwendungen verfügbar bleiben.

Der Metrics Agent basiert auf Victoria Metrics.

Die Konfiguration des MetricsAgent, geschieht über die Resourcen des prometheus-operator projects. Daher können Sie die folgenden Resource Typen in ihrem Cluster nutzen um Scraping-Konfigurationen und Alert- und Recordingrules zu erstellen:

  • ServiceMonitors
  • PodMonitors
  • PrometheusRules

Der Metrics Agent sammelt Ihre Metriken und sendet sie an unseren Metrics Cluster, der extern von Ihrem Cluster aus ausgeführt wird. Dadurch werden im Vergleich zum bisherigen Prometheus-Produkt viele Ressourcen der Control-Plane-Nodes in Ihrem NKE-Cluster freigesetzt.

Exporter und Metriken​

Der Metrics Agent sammelt automatisch eine Reihe von Standardmetriken. Zusätzliche Metriken der folgenden Exporter können optional aktiviert werden:

  • CertManager
  • IngressNginx
  • NodeExporter
  • Kubelet
  • Kubelet cAdvisor
  • KubeStateMetrics
  • 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.

Zugriff auf Metriken – Grafana​

Der Zugriff auf die Metriken erfolgt durch unser Grafana Produkt. Die Sichtbarkeit der einzelnen Metriken wird dabei vom Projekt der Grafana Instanz bestimmt.

Wenn Sie Ihre Grafana-Instanz im Standardprojekt (gleicher Name wie Ihre Organisation) erstellen, können Sie alle Metriken Ihrer gesamten Organisation sehen.

Wenn Sie die Instanz in einem anderen Projekt erstellen, sehen Sie nur die Metriken von Resourcen des gleichen Projekts.

Instrumentierung Ihrer Anwendung​

Bevor Metrics Agent Metriken aus Ihrer Anwendung scrapen kann, müssen Sie Ihre Anwendung so instrumentieren, dass sie Metriken in einem bestimmten Format exportiert. Informationen dazu finden Sie in der offiziellen Prometheus-Dokumentation.

Hinzufügen von Anwendungsmetriken zu Metrics Agent​

Sobald Ihre Anwendung Metriken unterstützt, können Sie ServiceMonitors oder PodMonitors verwenden, damit Metrics Agent die Metriken Ihrer Anwendung erfassen kann.

ServiceMonitors durchsuchen alle Pods, die von einem oder mehreren Services angesprochen werden. Diese Ressource muss in den meisten Fällen verwendet werden. Sie müssen einen Label-Selektor im ServiceMonitor definieren, der zum Auffinden aller gewünschten Services verwendet wird. Der ServiceMonitor sollte im selben Namespace erstellt werden wie die Services, die er auswählt. Neben dem Label-Selektor sollte Ihr ServiceMonitor auch das Label prometheus.nine.ch/<Name Ihres Metrik-Agenten>: scrape mit dem Namen Ihrer Metrik-Agent-Instanz enthalten. 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“ für diesen Service vorhanden ist. Der Metrics Agent sucht dann nach allen Pods, die von diesem Service angesprochen werden, und beginnt, sie auf Port 8080 nach Metriken zu durchsuchen (der ServiceMonitor definiert den Port im Feld endpoints).

PodMonitors erfasst alle Pods, die durch den angegebenen Label-Selektor ausgewählt wurden. Die Funktionsweise ist sehr ähnlich wie bei der ServiceMonitor-Ressource (nur ohne tatsächliche Service-Ressource). Sie können die PodMonitor-Ressource verwenden, wenn Ihre Anwendung aus anderen Gründen keine Service-Ressource benötigt (wie beispielsweise einige Exporter). Die Pods sollten im selben Namespace ausgeführt werden, 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 durchsucht.

Der Metrics Agent erstellt für jede von Ihnen definierte ServiceMonitor- oder PodMonitor-Ressource einen Job. Ausserdem fügt er allen gescrapten Metriken, die im entsprechenden Job gesammelt wurden, ein Job-Label hinzu. Anhand dessen lässt sich feststellen, aus welchen Services oder Pods eine bestimmte Metrik erfasst wurde.

Verwenden Sie ScrapeConfig, um ein externes Ziel {#external-target} zu scrapen​

Die ScrapeConfig CRD kann verwendet werden, um Ziele ausserhalb des Kubernetes-Clusters zu scrapen oder Scrape-Konfigurationen zu erstellen, die mit übergeordneten Ressourcen wie ServiceMonitor oder PodMonitor nicht möglich sind. Derzeit unterstützt ScrapeConfig eine begrenzte Anzahl von Mechanismen zur Serviceermittlung.

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 wird kontinuierlich weiterentwickelt (derzeit in der Phase „v1alpha1“) und regelmässig um neue Funktionen und die Unterstützung zusätzlicher Service Discovery-Mechanismen erweitert. Wir müssen sorgfältig abwägen, welche Felder nützlich sind und langfristig beibehalten werden sollten.

Beispiel für static_config​

Das folgende Beispiel enthält eine grundlegende Konfiguration und deckt nicht alle unterstützten Optionen ab. Um beispielsweise die Zieladresse 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 und nicht als HTTP(S)-URL angegeben werden. Um beispielsweise das Ziel unter http://metricsagent.demo.do.metricsagent.io:9090 zu scrapen, sollten Sie metricsagent.demo.do.metricsagent.io:9090 in das Feld targets eingeben.

Weitere Informationen finden Sie in der Konfiguration und der API-Dokumentation.

Beispiel für http_sd​

Die HTTP-basierte Serviceermittlung bietet eine allgemeinere Möglichkeit zur Konfiguration statischer Ziele und dient als Schnittstelle zum Einbinden benutzerdefinierter Mechanismen zur Serviceermittlung.

Sie ruft Ziele von einem HTTP-Endpunkt ab, der eine Liste mit 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>", ...
    }
  },
  ...
]

Example response body:

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

Die URL zum HTTP SD gilt nicht als geheim. Die Authentifizierung und alle API-Schlüssel sollten mit den entsprechenden Authentifizierungsmechanismen übermittelt 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 während der Umbenennungsphase ein Meta-Label __meta_url. 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-Endpunkte (HTTP SD) auf Ausfallzeiten zu überwachen. Bei einem Neustart des Metrics Agent, der während unseres regulären Wartungsfensters erfolgen kann, wird der Cache gelöscht. 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​

Sie können PromQL verwenden, 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>/.

Hinzufügen von Regeln zu Metrics Agent​

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

Recording Rules können verwendet werden, um aus bereits vorhandenen Metriken neue Metriken zu berechnen. Dies kann nützlich sein, wenn Sie rechenintensive Abfragen in Dashboards verwenden. Um diese zu beschleunigen, können Sie eine Recording Rules erstellen, die die Abfrage in einem definierten Intervall auswertet und das Ergebnis als neue Metrik speichert. Diese neue Metrik können Sie dann in Ihren Dashboard-Abfragen verwenden.

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

Achten Sie beim Erstellen von Alert- oder Recordingrules darauf, das Label prometheus.nine.ch/<Name Ihres Metrik-Agenten>: scrape mit dem Namen Ihrer Metrik-Agent-Instanz hinzuzufügen. Dadurch wird die erstellte Regel Ihrer Metrik-Agent-Instanz zugewiesen.

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 in Alertmanager verwendet werden, um Ihre Benachrichtigungen und Routing-Entscheidungen anzupassen.

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

Hier ist ein Beispiel für einer 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.