Logging und Monitoring konfigurieren

Google Distributed Cloud 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 Google Distributed Cloud

Sie haben mehrere Logging- und Monitoring-Optionen für Ihre Google Distributed Cloud:

  • 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 Google Distributed Cloud-Cluster auf ähnliche Weise wie cloudbasierte GKE-Cluster.

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

  • Der Umfang von Logging und Monitoring kann auf Systemkomponenten (Standardeinstellung) oder für 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 Google Distributed Cloud konfigurieren.

Logging und Monitoring bieten eine einzige, einfach zu konfigurierende und leistungsstarke cloudbasierte Beobachtbarkeitslösung. Wir empfehlen dringend Logging und Monitoring, wenn Sie Arbeitslasten in Google Distributed Cloud ausführen. Für Anwendungen mit Komponenten, die in Google Distributed Cloud und lokaler Standardinfrastruktur 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 verarbeitet das Senden von Benachrichtigungen über verschiedene Mechanismen.

  • Grafana ist ein Dashboard-Tool.

Wir empfehlen, Google Cloud Managed Service for Prometheus für alle Ihre Monitoring-Anforderungen zu verwenden, das auf Cloud Monitoring basiert. Mit Google Cloud Managed Service for Prometheus können Sie Systemkomponenten kostenlos überwachen. Google Cloud Managed Service for Prometheus ist auch mit Grafana kompatibel. Wenn Sie jedoch ein rein 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 Clientschlüssel und das Zertifikat, die im kube-system/stackdriver-prometheus-etcd-scrape-Secret gespeichert sind, um die Messwertextraktion aus etcd zu authentifizieren.

  • Erstellen Sie eine NetworkPolicy, um den Zugriff von Ihrem Namespace auf kube-state-metrics zu ermöglichen.

Drittanbieterlösungen

Google hat mit mehreren Logging- und Monitoring-Drittanbietern zusammengearbeitet, damit ihre Produkte gut mit Google Distributed Cloud 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 Google Distributed Cloud zur Verfügung:

Funktionsweise von Logging und Monitoring für Google Distributed Cloud

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 im Cluster bereitgestellten Stackdriver-Agents.

  • Benutzerdefinierte Stackdriver-Ressource. Eine Ressource, die im Rahmen der Google Distributed Cloud-Installation 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 speichert die Logeinträge auf dem Knoten lokal zwischen und sendet sie bis zu 4 Stunden lang noch einmal. Wenn der Zwischenspeicher voll ist oder der Log-Forwarder die Cloud Logging API länger als vier Stunden nicht erreichen kann, werden Logs gelöscht.

  • 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, da Sie damit 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 Google Distributed Cloud-Messwerte ansehen.

Stackdriver-Agents für Google Distributed Cloud konfigurieren

Die mit Google Distributed Cloud installierten Stackdriver-Agents erfassen Daten über Systemkomponenten, um Probleme mit 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 diesen an Google Cloud Observability (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.

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

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

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

  • Wenn Sie sowohl GKE als auch Google Distributed Cloud 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.

Google Cloud Managed Service for Prometheus aktivieren und deaktivieren

Google Cloud Managed Service for Prometheus ist in Google Distributed Cloud standardmäßig aktiviert.

So deaktivieren Sie Google Cloud Managed Service for Prometheus:

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

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

  2. Fügen Sie das Feature-Gatter enableGMPForSystemMetrics hinzu und legen Sie dafür 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 mit PromQL oder 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 den Messwertnamen mit dem Präfix kubernetes.io/anthos und fügen 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 Google Cloud Managed Service for Prometheus konfigurieren

Wenn Sie Grafana mit Messwertdaten aus Google Cloud Managed Service for Prometheus verwenden möchten, müssen Sie zuerst die Grafana-Datenquelle konfigurieren und authentifizieren. Zum Konfigurieren und Authentifizieren der Datenquelle generieren Sie mit dem Datenquellen-Syncer (datasource-syncer) OAuth2-Anmeldedaten und synchronisieren sie über die Grafana Data Source API mit Grafana. Der Datenquellen-Syncer legt die Cloud Monitoring API unter der Datenquelle in Grafana als Prometheus-Server-URL fest (der URL-Wert beginnt mit https://monitoring.googleapis.com).

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

Eine Reihe von Grafana-Beispiel-Dashboards finden Sie im Repository anthos-samples auf GitHub. 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 die 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 Ihrer Grafana-Datei, die auf den frontend-Dienst von Prometheus verweist.

  3. Rufen Sie die Benutzeroberfläche von Grafana über Ihren Browser auf und wählen Sie im Menü Dashboards die Option + Importieren aus.

    Dashboard-Import in Grafana wird aufgerufen.

  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 Dateiinhalt geladen wurde, wählen Sie Importieren aus. Optional können Sie vor dem Import auch den Namen und die UID des Dashboards ändern.

    Dashboard wird in Grafana importiert.

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

    Dashboard zur Clusterkapazität in Grafana.

Weitere Ressourcen

Weitere Informationen zu Google Cloud Managed Service for Prometheus finden Sie hier:

Stackdriver-Komponentenressourcen konfigurieren

Wenn Sie einen Cluster erstellen, erstellt Google Distributed Cloud automatisch eine benutzerdefinierte Stackdriver-Ressource. 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. Die Standardeinstellung für optimierte Messwerte lässt sich 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, einen Ersatz in der Liste der Google Distributed Cloud-Messwerte zu suchen.

Hier sind einige Beispiele für Ersatz, die Sie verwenden können:

Deaktivierter Messwert Ersatzgeräte
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 beenden Sie den Befehlszeileneditor.

Metrics Server

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, indem Sie die configmap metrics-server-config im Namespace „gke-managed-metrics-server“ bearbeiten und den Wert für cpuPerNode und memoryPerNode ändern.

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 mehrere Konfigurationsanforderungen, um Cloud Logging und Cloud Monitoring mit Google Distributed Cloud 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. Im Google Cloud-Projekt muss ein Cloud Monitoring-Arbeitsbereich 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 Google Distributed Cloud-Cluster enthalten 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.