Logging und Monitoring konfigurieren

Google Distributed Cloud (nur Software) für Bare-Metal unterstützt mehrere Optionen für das Cluster-Logging und -Monitoring, darunter cloudbasierte verwaltete Dienste, Open-Source-Tools und validierte Kompatibilität mit kommerziellen Lösungen von Drittanbietern. Auf dieser Seite werden diese Optionen erläutert und einige grundlegende Anleitungen zur Auswahl der richtigen Lösung für Ihre Umgebung gegeben.

Diese Seite richtet sich an Administratoren, Architekten und Betreiber, die den Status bereitgestellter Anwendungen oder Dienste überwachen möchten, z. B. zur Einhaltung von Service Level Objectives (SLOs). Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud-Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und -Aufgaben.

Optionen für Google Distributed Cloud

Sie haben mehrere Logging- und Monitoring-Optionen für Ihren Cluster:

  • 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 ähnlich wie cloudbasierte GKE-Cluster.

Cloud Logging und Cloud Monitoring sind standardmäßig aktiviert, wenn Sie Cluster mit den erforderlichen Dienstkonten und IAM-Rollen erstellen. Sie können Cloud Logging und Cloud Monitoring nicht deaktivieren. Weitere Informationen zu Dienstkonten und den erforderlichen Rollen finden Sie unter Dienstkonten konfigurieren.

Die Agents können so konfiguriert werden, dass der Umfang des Loggings und Monitorings sowie die Ebene der erfassten Messwerte geändert werden:

  • Der Umfang des Logging und Monitoring kann nur auf Systemkomponenten (Standardeinstellung) oder auf Systemkomponenten und Anwendungen festgelegt werden
  • Die Ebene der erfassten Messwerte kann für einen optimierten Satz von Messwerten (Standard) oder für vollständige 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 Logging und Monitoring, wenn Sie Arbeitslasten in Google Distributed Cloud ausführen. Für Anwendungen mit Komponenten, die in Google Distributed Cloud und einer 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 die Verwendung von Google Cloud Managed Service for Prometheus, das auf Cloud Monitoring basiert, für alle Ihre Monitoring-Anforderungen. 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 für den Zugriff auf die Messwertendpunkte von Systemkomponenten erteilen:

  • 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 erfassen:

    • 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 das gescrapte Messwert aus 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-Lösungs-Drittanbietern zusammengearbeitet, damit ihre Produkte mit Google Distributed Cloud kompatibel sind. 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 auf dem Cluster bereitgestellten Stackdriver-Agents.

  • Benutzerdefinierte Stackdriver-Ressource. Eine Ressource, die im Rahmen des Installationsprozesses für Google Distributed Cloud 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 4 Stunden 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.

  • Metadata Agent (stackdriver-metadata-agent-). Ein Modul, das Metadaten für Kubernetes-Ressourcen wie Pods, Deployments, Knoten usw. an die Config Monitoring for Ops API sendet. Anhand dieser Daten können Sie Messwertabfragen anreichern und Abfragen nach Deployment-Name, Knotenname oder auch Kubernetes-Dienstname ausführen.

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 aufrufen.

Stackdriver-Agents für die Google Distributed Cloud konfigurieren

Die mit Google Distributed Cloud installierten Stackdriver-Agents erfassen Daten zu 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 ihn an Google Cloud Observability (ehemals Stackdriver).

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

Um optimierte Messwerte zu deaktivieren (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 vorhandenes 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-Abfragesprache (PromQL) für Messwerte in allen Ihren 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 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 die Messwerte für die folgenden Komponenten ein anderes Format für die Speicherung und Abfrage in Cloud Monitoring:

  • 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 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

Setzen Sie die überwachte Ressource auf prometheus_target, verwenden Sie den Messwertnamen mit dem Präfix kubernetes.io/anthos und fügen Sie den Prometheus-Typ als Suffix zum Messwertnamen hinzu, um MQL zu verwenden.

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. Um die Datenquelle zu konfigurieren und zu authentifizieren, verwenden Sie den Datenquellen-Synchronizer (datasource-syncer), um OAuth2-Anmeldedaten zu generieren und über die Grafana Data Source API mit Grafana zu synchronisieren. Der Datenquellen-Synchronizer 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 Google Cloud Managed Service for Prometheus abzufragen.

Im Repository anthos-samples auf GitHub finden Sie eine Reihe von Beispiel-Grafana-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 dabei [DATASOURCE_NAME] durch den Namen der Datenquelle in Ihrer Grafana, die auf den Prometheus-Dienst frontend ausgerichtet wurde.

  3. Rufen Sie die Grafana-Benutzeroberfläche in Ihrem Browser auf und wählen Sie im Menü Dashboards die Option + Importieren aus.

    Rufen Sie in Grafana den Dashboard-Import auf.

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

    Dashboard in Grafana importieren

  5. Das importierte Dashboard sollte geladen werden, wenn Ihre 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 Informationen

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 Arbeitsspeicheranforderungen und Limits für eine Stackdriver-Komponente zu überschreiben. Die optimierte Standardmesswerteinstellung kann separat überschrieben werden.

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 ihn an Stackdriver. Wenn Sie zusätzliche Messwerte benötigen, empfehlen wir Ihnen, einen Ersatz aus der Liste der Messwerte für Google Distributed Cloud zu suchen.

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

Messwert deaktiviert Ersatz
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

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 weitere Ressourcen zuweisen. Bearbeiten Sie dazu die ConfigMap metrics-server-config im Namespace „gke-managed-metrics-server“ und ändern Sie 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
Hinweis:

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
Hinweis:

Konfigurationsanforderungen für Logging und Monitoring

Für das Aktivieren von Cloud Logging und Cloud Monitoring für die Google Distributed Cloud gelten verschiedene Konfigurationsanforderungen. 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 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 Edition 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 Google Cloud Observability.

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