Logging und Monitoring konfigurieren

GKE on Bare Metal bietet mehrere Optionen für das Cluster-Logging und -Monitoring, einschließlich cloudbasierter verwalteter Dienste, Open-Source-Tools und validierter Kompatibilität mit kommerziellen Lösungen von Drittanbietern. Auf dieser Seite werden diese Optionen beschrieben. Außerdem erhalten Sie grundlegende Informationen zur Auswahl der richtigen Lösung für Ihre Umgebung.

Optionen für GKE on Bare Metal

Für GKE on Bare Metal stehen Ihnen mehrere Logging- und Monitoring-Optionen zur Verfügung:

  • Cloud Logging und Cloud Monitoring sind standardmäßig für Bare-Metal-Systemkomponenten aktiviert.
  • Prometheus und Grafana sind im Cloud Marketplace verfügbar.
  • Validierte Konfigurationen mit Lösungen von Drittanbietern

Cloud Logging und Cloud Monitoring

Google Cloud Observability ist die integrierte Beobachtbarkeitslösung für Google Cloud. Sie bietet eine vollständig verwaltete Logging-Lösung, Messwerterfassung, Monitoring, Dashboards und Benachrichtigungen. Cloud Monitoring überwacht GKE on Bare-Metal-Cluster ähnlich wie cloudbasierte GKE-Cluster.

Die Agents können so konfiguriert werden, dass sie den Umfang von Logging und Monitoring sowie die Ebene der erfassten Messwerte ändern:

  • Der Umfang des Loggings und Monitorings kann auf nur Systemkomponenten (Standardeinstellung) oder auf Systemkomponenten und Anwendungen festgelegt werden.
  • Die Ebene der erfassten Messwerte kann für einen optimierten Satz von Messwerten (Standardeinstellung) oder für alle Messwerte konfiguriert werden.

Weitere Informationen finden Sie in diesem Dokument unter Stackdriver-Agents für GKE on Bare Metal konfigurieren.

Logging und Monitoring bieten eine einzige, einfach zu konfigurierende und leistungsstarke cloudbasierte Beobachtbarkeitslösung. Wir empfehlen Logging und Monitoring beim Ausführen von Arbeitslasten in GKE on Bare Metal dringend. Für Anwendungen mit Komponenten, die in GKE in Bare Metal und in der standardmäßigen lokalen Infrastruktur ausgeführt werden, können Sie andere Lösungen für eine End-to-End-Ansicht dieser Anwendungen in Betracht ziehen.

Prometheus und Grafana

Prometheus und Grafana sind zwei beliebte Open-Source-Monitoring-Produkte im Cloud Marketplace:

  • Prometheus erfasst Anwendungs- und Systemmesswerte.

  • Alertmanager sendet Benachrichtigungen über verschiedene Mechanismen.

  • Grafana ist ein Dashboard-Tool.

Wir empfehlen für alle Monitoringanforderungen die Verwendung von Managed Service for Prometheus, das auf Cloud Monitoring basiert. Mit Managed Service for Prometheus können Sie Systemkomponenten kostenlos überwachen. Managed Service for Prometheus ist auch mit Grafana kompatibel. Wenn Sie jedoch ein reines lokales Monitoringsystem bevorzugen, können Sie Prometheus und Grafana in Ihren Clustern installieren.

Wenn Sie Prometheus lokal installiert haben und Messwerte aus Systemkomponenten erfassen möchten, müssen Sie Ihrer lokalen Prometheus-Instanz die Berechtigung erteilen, auf die Messwertendpunkte der Systemkomponenten zuzugreifen:

  • Binden Sie das Dienstkonto für Ihre Prometheus-Instanz an die vordefinierte ClusterRole gke-metrics-agent und verwenden Sie das Dienstkontotoken als Anmeldedaten, um Messwerte aus den folgenden Systemkomponenten zu extrahieren:

    • kube-apiserver
    • kube-scheduler
    • kube-controller-manager
    • kubelet
    • node-exporter

  • Verwenden Sie den im Secret kube-system/stackdriver-prometheus-etcd-scrape gespeicherten Clientschlüssel und das Zertifikat, um den Messwert-Scraping von etcd zu authentifizieren.

  • Erstellen Sie eine NetworkPolicy, um den Zugriff von Ihrem Namespace auf kube-state-metrics zuzulassen.

Drittanbieterlösungen

Google hat mit mehreren Logging- und Monitoring-Drittanbietern zusammengearbeitet, damit ihre Produkte gut mit GKE on Bare Metal funktionieren. Dazu gehören Datadog, Elastic und Splunk. Weitere validierte Drittanbieter werden in Zukunft hinzugefügt.

Die folgenden Lösungsleitfäden stehen für die Verwendung von Drittanbieterlösungen mit GKE on Bare Metal zur Verfügung:

Funktionsweise von Logging und Monitoring für GKE on Bare Metal

Cloud Logging und Cloud Monitoring werden in jedem Cluster installiert und aktiviert, wenn Sie einen neuen Administrator- oder Nutzercluster erstellen.

Die Stackdriver-Agents enthalten mehrere Komponenten in jedem Cluster:

  • Stackdriver-Operator (stackdriver-operator-*). Verwaltet den Lebenszyklus aller anderen auf dem Cluster bereitgestellten Stackdriver-Agents.

  • Benutzerdefinierte Stackdriver-Ressource. Eine Ressource, die im Rahmen der Installation von GKE on Bare Metal automatisch erstellt wird.

  • GKE-Messwert-Agent (gke-metrics-agent-*). Ein DaemonSet, das auf OpenTelemetry-Collector basiert und Messwerte von jedem Knoten für Cloud Monitoring extrahiert. Ein node-exporter-DaemonSet und ein kube-state-metrics-Deployment sind ebenfalls enthalten, um weitere Messwerte zum Cluster bereitzustellen.

  • Stackdriver Log Forwarder (stackdriver-log-forwarder-*). Ein Fluent Bit-DaemonSet, das Logs von jeder Maschine an Cloud Logging weiterleitet. Der Log-Forwarder puffert die Logeinträge auf dem Knoten lokal und sendet sie bis zu vier Stunden lang noch einmal. Wenn der Zwischenspeicher voll ist oder der Log Forwarder die Cloud Logging API mehr als vier Stunden lang nicht erreichen kann, werden Logs gelöscht.

  • Anthos-Metadaten-Agent (stackdriver-metadata-agent-). Ein Deployment, das Metadaten für Kubernetes-Ressourcen wie Pods, Deployments oder Knoten an die Config Monitoring for Ops API sendet. Diese Daten werden zur Anreicherung von Messwertabfragen verwendet, indem Sie Abfragen nach Bereitstellungsname, Knotenname oder sogar Kubernetes-Dienstnamen ausführen können.

Mit dem folgenden Befehl können Sie die von Stackdriver installierten Agents aufrufen:

kubectl -n kube-system get pods -l "managed-by=stackdriver"

Die Ausgabe dieses Befehls sieht wie folgt aus:

kube-system   gke-metrics-agent-4th8r                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-8lt4s                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-dhxld                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-lbkl2                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-pblfk                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-qfwft                                     1/1     Running   1 (40h ago)   40h
kube-system   kube-state-metrics-9948b86dd-6chhh                          1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-5s4pg                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-d9gwv                                         1/1     Running   2 (40h ago)   40h
kube-system   node-exporter-fhbql                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-gzf8t                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-tsrpp                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-xzww7                                         1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-8lwxh                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-f7cgf                             1/1     Running   2 (40h ago)   40h
kube-system   stackdriver-log-forwarder-fl5gf                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-q5lq8                             1/1     Running   2 (40h ago)   40h
kube-system   stackdriver-log-forwarder-www4b                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-xqgjc                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-metadata-agent-cluster-level-5bb5b6d6bc-z9rx7   1/1     Running   1 (40h ago)   40h

Cloud Monitoring-Messwerte

Eine Liste der von Cloud Monitoring erfassten Messwerte finden Sie unter GKE on Bare-Metal-Messwerte ansehen.

Stackdriver-Agents für GKE on Bare Metal konfigurieren

Die mit GKE on Bare Metal installierten Stackdriver-Agents erfassen Daten zu Systemkomponenten, um Probleme in Ihren Clustern zu warten und zu beheben. In den folgenden Abschnitten werden die Stackdriver-Konfigurations- und Betriebsmodi beschrieben.

Nur Systemkomponenten (Standardmodus)

Bei der Installation werden Stackdriver-Agents standardmäßig so konfiguriert, dass sie Logs und Messwerte erfassen, einschließlich Leistungsdetails (z. B. CPU- und Arbeitsspeicherauslastung) und vergleichbarer Metadaten für von Google bereitgestellte Systemkomponenten. Dazu gehören alle Arbeitslasten im Administratorcluster und in Nutzerclustern Arbeitslasten in den Namespaces kube-system, gke-system, gke-connect, istio-system und config-management-system.

Systemkomponenten und Anwendungen

Führen Sie die Schritte unter Anwendungs-Logging und -Monitoring aktivieren aus, um das Logging und Monitoring von Anwendungen zusätzlich zum Standardmodus zu aktivieren.

Optimierte Messwerte (Standardmesswerte)

Standardmäßig erfassen die im Cluster ausgeführten kube-state-metrics-Deployments einen optimierten Satz von Kube-Messwerten und melden sie an Google Cloud-Beobachtbarkeit (früher Stackdriver).

Es sind weniger Ressourcen erforderlich, um diese optimierten Messwerte zu erfassen, was die Gesamtleistung und die Skalierbarkeit verbessert.

Wenn Sie optimierte Messwerte deaktivieren möchten (nicht empfohlen), überschreiben Sie die Standardeinstellung in Ihrer benutzerdefinierten Stackdriver-Ressource.

Managed Service for Prometheus für ausgewählte Systemkomponenten verwenden

Google Cloud Managed Service for Prometheus ist Teil von Cloud Monitoring und ist als Option für Systemkomponenten verfügbar. Managed Service for Prometheus bietet unter anderem folgende Vorteile:

  • Sie können Ihr vorhandenes Prometheus-basiertes Monitoring weiterhin verwenden, ohne Ihre Benachrichtigungen und Grafana-Dashboards zu ändern.

  • Wenn Sie sowohl GKE als auch GKE on Bare Metal verwenden, können Sie dieselbe Prometheus Query Language (PromQL) für Messwerte in allen Clustern verwenden. Sie können auch den Tab PromQL im Metrics Explorer in der Google Cloud Console verwenden.

Managed Service for Prometheus aktivieren und deaktivieren

Managed Service for Prometheus ist in GKE on Bare Metal standardmäßig aktiviert.

So deaktivieren Sie Managed Service for Prometheus:

  1. Öffnen Sie das Stackdriver-Objekt stackdriver zur Bearbeitung:

    kubectl --kubeconfig CLUSTER_KUBECONFIG --namespace kube-system \
    edit stackdriver stackdriver

  2. Fügen Sie das Feature-Gate enableGMPForSystemMetrics hinzu und legen Sie es auf false fest:

    apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
  name: stackdriver
  namespace: kube-system
spec:
  featureGates:
    enableGMPForSystemMetrics: false

  3. Schließen Sie die Bearbeitungssitzung.

Messwertdaten ansehen

Wenn enableGMPForSystemMetrics auf true gesetzt ist, haben Messwerte für die folgenden Komponenten ein anderes Format dafür, wie sie in Cloud Monitoring gespeichert und abgefragt werden:

  • kube-apiserver
  • kube-scheduler
  • kube-controller-manager
  • Kubelet und cAdvisor
  • kube-state-metrics
  • node-exporter

Im neuen Format können Sie die vorherigen Messwerte entweder mit PromQL oder mit Monitoring Query Language (MQL) abfragen:

PromQL

Beispiel für eine PromQL-Abfrage:

histogram_quantile(0.95, sum(rate(apiserver_request_duration_seconds_bucket[5m])) by (le))

MQL

Wenn Sie MQL verwenden möchten, legen Sie die überwachte Ressource auf prometheus_target fest, verwenden Sie den Messwertnamen mit dem Präfix kubernetes.io/anthos und fügen Sie dem Messwertnamen den Prometheus-Typ als Suffix hinzu.

fetch prometheus_target
| metric 'kubernetes.io/anthos/apiserver_request_duration_seconds/histogram'
| align delta(5m)
| every 5m
| group_by [], [value_histogram_percentile: percentile(value.histogram, 95)]

Grafana-Dashboards mit Managed Service for Prometheus konfigurieren

Wenn Sie Grafana mit Messwertdaten aus Managed Service for Prometheus verwenden möchten, müssen Sie zuerst die Grafana-Datenquelle konfigurieren und authentifizieren. Zur Konfiguration und Authentifizierung der Datenquelle verwenden Sie das Tool zum Synchronisieren der Datenquelle (datasource-syncer), um OAuth2-Anmeldedaten zu generieren und über die Grafana-Datenquellen-API mit Grafana zu synchronisieren. Der Datenquellen-Syncer legt die Cloud Monitoring API als Prometheus-Server-URL (der URL-Wert beginnt mit https://monitoring.googleapis.com) unter der Datenquelle in Grafana fest.

Führen Sie die Schritte unter Abfrage mit Grafana aus, um eine Grafana-Datenquelle zu authentifizieren und zu konfigurieren, um Daten aus Managed Service for Prometheus abzufragen.

Im Repository anthos-samples auf GitHub finden Sie eine Reihe von Grafana-Beispiel-Dashboards. So installieren Sie die Beispiel-Dashboards:

  1. Laden Sie die JSON-Beispieldateien herunter:

    git clone https://github.com/GoogleCloudPlatform/anthos-samples.git
cd anthos-samples/gmp-grafana-dashboards

  2. Wenn Ihre Grafana-Datenquelle mit einem anderen Namen als Managed Service for Prometheus erstellt wurde, ändern Sie das Feld datasource in allen JSON-Dateien:

    sed -i "s/Managed Service for Prometheus/[DATASOURCE_NAME]/g" ./*.json

    Ersetzen Sie [DATASOURCE_NAME] durch den Namen der Datenquelle in Grafana, die auf den Prometheus-Dienst frontend verweist.

  3. Rufen Sie die Grafana-UI in Ihrem Browser auf und wählen Sie im Menü Dashboards die Option + Import (+ Importieren) aus.

    Navigation zum Dashboard-Import in Grafana.

  4. Laden Sie entweder die JSON-Datei hoch oder kopieren Sie den Dateiinhalt, fügen Sie ihn ein und wählen Sie Laden aus. Nachdem der Inhalt der Datei geladen wurde, wählen Sie Importieren aus. Optional können Sie vor dem Import auch den Namen und die UID des Dashboards ändern.

    Dashboard in Grafana wird importiert.

  5. Das importierte Dashboard sollte erfolgreich geladen werden, wenn GKE on Bare Metal und die Datenquelle richtig konfiguriert sind. Der folgende Screenshot zeigt beispielsweise das von cluster-capacity.json konfigurierte Dashboard.

    Clusterkapazitäts-Dashboard in Grafana.

Weitere Ressourcen

Weitere Informationen zu Managed Service for Prometheus finden Sie hier:

Stackdriver-Komponentenressourcen konfigurieren

Wenn Sie einen Cluster erstellen, wird von GKE on Bare Metal automatisch eine benutzerdefinierte Stackdriver-Ressource erstellt. Sie können die Spezifikation in der benutzerdefinierten Ressource bearbeiten, um die Standardwerte für CPU- und Arbeitsspeicheranfragen und -limits für eine Stackdriver-Komponente zu überschreiben. Sie können die Standardeinstellung für optimierte Messwerte separat überschreiben.

Standardmäßige CPU- und Speicheranforderungen und Limits für eine Stackdriver-Komponente überschreiben

Cluster mit einer hohen Pod-Dichte führen zu einem höheren Logging und Monitoring. In extremen Fällen melden Stackdriver-Komponenten möglicherweise das Limit für die CPU- und Speicherauslastung oder wegen kontinuierlicher Neustarts aufgrund von Ressourcenlimits. Führen Sie in diesem Fall die folgenden Schritte aus, um die Standardwerte für CPU- und Speicheranforderungen und Limits für eine Stackdriver-Komponente zu überschreiben:

  1. Führen Sie den folgenden Befehl aus, um Ihre benutzerdefinierte Stackdriver-Ressource in einem Befehlszeileneditor zu öffnen:

    kubectl -n kube-system edit stackdriver stackdriver

  2. Fügen Sie in der benutzerdefinierten Stackdriver-Ressource den Abschnitt resourceAttrOverride unter dem Feld spec hinzu:

    resourceAttrOverride:
      DAEMONSET_OR_DEPLOYMENT_NAME/CONTAINER_NAME:
        LIMITS_OR_REQUESTS:
          RESOURCE: RESOURCE_QUANTITY

    Beachten Sie, dass der Abschnitt resourceAttrOverride alle vorhandenen Standardlimits und -anfragen für die angegebene Komponente überschreibt. Die folgenden Komponenten werden von resourceAttrOverride unterstützt:

    • gke-metrics-agent/gke-metrics-agent
    • stackdriver-log-forwarder/stackdriver-log-forwarder
    • stackdriver-metadata-agent-cluster-level/metadata-agent
    • node-exporter/node-exporter
    • kube-state-metrics/kube-state-metrics

    Eine Beispieldatei sieht so aus:

    apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
  name: stackdriver
  namespace: kube-system
spec:
  anthosDistribution: baremetal
  projectID: my-project
  clusterName: my-cluster
  clusterLocation: us-west-1a
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      requests:
        cpu: 110m
        memory: 240Mi
      limits:
        cpu: 200m
        memory: 4.5Gi

  3. Speichern und schließen Sie den Befehlszeileneditor, um Änderungen an der benutzerdefinierten Stackdriver-Ressource zu speichern.

  4. Prüfen Sie den Status Ihres Pods:

    kubectl -n kube-system get pods -l "managed-by=stackdriver"

    Eine Antwort für einen fehlerfreien Pod sieht so aus:

    gke-metrics-agent-4th8r                1/1     Running   1   40h

  5. Sehen Sie in der Pod-Spezifikation der Komponente nach, ob die Ressourcen richtig festgelegt sind.

    kubectl -n kube-system describe pod POD_NAME

    Ersetzen Sie POD_NAME durch den Namen des Pods, den Sie gerade geändert haben. Beispiel: gke-metrics-agent-4th8r.

    Die Antwort sieht in etwa so aus:

      Name:         gke-metrics-agent-4th8r
  Namespace:    kube-system
  ...
  Containers:
    gke-metrics-agent:
      Limits:
        cpu: 200m
        memory: 4.5Gi
      Requests:
        cpu: 110m
        memory: 240Mi
      ...

Optimierte Messwerte deaktivieren

Standardmäßig erfassen die im Cluster ausgeführten kube-state-metrics-Deployments einen optimierten Satz von Kube-Messwerten und melden sie an Stackdriver. Wenn Sie zusätzliche Messwerte benötigen, empfehlen wir Ihnen, einen Ersatz aus der Liste der GKE on Bare Metal-Messwerte zu finden.

Hier sind einige Beispiele für mögliche Ersetzungen:

Deaktivierter Messwert Ersatzprodukte
kube_pod_start_time container/uptime
kube_pod_container_resource_requests container/cpu/request_cores
container/memory/request_bytes
kube_pod_container_resource_limits container/cpu/limit_cores
container/memory/limit_bytes

So deaktivieren Sie die Standardeinstellung für optimierte Messwerte (nicht empfohlen):

  1. Öffnen Sie die benutzerdefinierte Stackdriver-Ressource in einem Befehlszeileneditor:

    kubectl -n kube-system edit stackdriver stackdriver

  2. Setzen Sie das Feld optimizedMetrics auf false:

    apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
name: stackdriver
namespace: kube-system
spec:
anthosDistribution: baremetal
projectID: my-project
clusterName: my-cluster
clusterLocation: us-west-1a
optimizedMetrics: false

  3. Speichern Sie die Änderungen und schließen Sie den Befehlszeilen-Editor.

Metrics Server

Der Metrics Server ist die Quelle der Containerressourcenmesswerte für verschiedene Autoscaling-Pipelines. Metrics Server ruft Messwerte aus kubelets ab und stellt sie über die Metrics API von Kubernetes bereit. HPA und VPA bestimmen dann anhand dieser Messwerte, wann das Autoscaling ausgelöst werden soll. Der Messwertserver wird mit Add-on-Resizer skaliert.

In extremen Fällen, in denen eine hohe Pod-Dichte zu viel Logging und Monitoring verursacht, wird Metrics Server unter Umständen aufgrund von Ressourcenbeschränkungen gestoppt und neu gestartet. In diesem Fall können Sie dem Messwertserver mehr Ressourcen zuweisen. Dazu bearbeiten Sie die Konfigurationsdatei metrics-server-config im Namespace „gke-managed-metrics-server“ und ändern den Wert für cpuPerNode und memoryPerNode.

kubectl edit cm metrics-server-config -n gke-managed-metrics-server

Der Beispielinhalt der ConfigMap lautet:

apiVersion: v1
data:
  NannyConfiguration: |-
    apiVersion: nannyconfig/v1alpha1
    kind: NannyConfiguration
    cpuPerNode: 3m
    memoryPerNode: 20Mi
kind: ConfigMap

Nachdem Sie die ConfigMap aktualisiert haben, erstellen Sie die Messwertserver-Pods mit dem folgenden Befehl neu:

kubectl delete pod -l k8s-app=metrics-server -n gke-managed-metrics-server

Konfigurationsanforderungen für Logging und Monitoring

Es gibt verschiedene Konfigurationsanforderungen, um Cloud Logging und Cloud Monitoring mit GKE on Bare Metal zu aktivieren. Diese Schritte sind auf der Seite "Google-Dienste aktivieren" unter Dienstkonto für die Verwendung mit Logging und Monitoring konfigurieren und in der folgenden Liste aufgeführt:

  1. Ein Cloud Monitoring-Arbeitsbereich muss innerhalb des Google Cloud-Projekts erstellt werden. Klicken Sie dazu auf Monitoring in der Google Cloud Console und folgen Sie dem Workflow.

  2. Sie müssen die folgenden Stackdriver APIs aktivieren:

  3. Sie müssen dem Dienstkonto, das von den Stackdriver-Agents verwendet wird, die folgenden IAM-Rollen zuweisen:

    • logging.logWriter
    • monitoring.metricWriter
    • stackdriver.resourceMetadata.writer
    • monitoring.dashboardEditor
    • opsconfigmonitoring.resourceMetadata.writer

Preise

Die Systemlogs und -messwerte der Google Kubernetes Engine (GKE) Enterprise-Version sind kostenlos.

In einem GKE on Bare Metal-Cluster umfassen die Systemlogs und Messwerte der Google Kubernetes Engine (GKE) Enterprise-Version Folgendes:

  • Logs und Messwerte aus allen Komponenten in einem Administratorcluster
  • Logs und Messwerte aus Komponenten in diesen Namespaces in einem Nutzercluster: kube-system, gke-system, gke-connect, knative-serving, istio-system, monitoring-system, config-management-system, gatekeeper-system, cnrm-system

Weitere Informationen finden Sie unter Preise für die Google Cloud-Beobachtbarkeit.

Wenn Sie weitere Informationen wünschen und mehr über Guthaben für Cloud Logging-Messwerte wissen möchten, wenden Sie sich an den Vertrieb.