Logging und Monitoring konfigurieren

Anthos-Cluster on Bare Metal bietet mehrere Optionen für das Logging und Monitoring von Clustern, darunter cloudbasierte verwaltete Dienste, Open-Source-Tools und validierte 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 Anthos-Cluster on Bare Metal

Sie haben mehrere Logging- und Monitoring-Optionen für Ihre Anthos-Cluster on Bare Metal:

  • 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

Die Operations-Suite von Google Cloud 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 "Anthos-Cluster on Bare Metal"-Cluster ähnlich wie cloudbasierte GKE-Cluster.

Die Agents können auf zwei verschiedenen Logging- und Monitoring-Ebenen konfiguriert werden:

  • Nur Systemkomponenten (Standard).
  • Systemkomponenten und Anwendungen.

Logging und Monitoring bieten eine einzige, einfach zu konfigurierende und leistungsstarke cloudbasierte Beobachtbarkeitslösung. Wir empfehlen Logging und Monitoring, wenn Sie Arbeitslasten nur in Anthos-Cluster on Bare Metal oder in GKE und Anthos-Cluster on Bare Metal ausführen. Für Anwendungen mit Komponenten, die in Anthos-Cluster on Bare Metal und einer herkömmlichen 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.

Prometheus und Grafana können in jedem Administrator- und Nutzercluster aktiviert werden. Prometheus und Grafana werden für Anwendungsteams empfohlen, die bereits Erfahrung mit diesen Produkten haben. Diese Produkte werden auch für operative Teams empfohlen, die Anwendungsmesswerte innerhalb des Clusters beibehalten möchten, und zur Behebung von Problemen verwenden, wenn die Netzwerkverbindung unterbrochen wird.

Drittanbieterlösungen

Google hat mit mehreren Drittanbietern für Logging- und Monitoring-Lösungen zusammengearbeitet, damit deren Produkte mit Anthos-Cluster on Bare Metal 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 Anthos-Cluster on Bare Metal zur Verfügung:

So funktionieren Logging und Monitoring für Anthos-Cluster 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 für jeden 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 Anthos-Cluster 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 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.

  • Anthos 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 Anthos-Cluster on Bare Metal-Messwerte aufrufen.

Stackdriver-Agents für Anthos-Cluster on Bare Metal konfigurieren

Die mit Anthos-Cluster on Bare Metal 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.

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

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 kube-system und ändern Sie den Wert für cpuPerNode und memoryPerNode.

kubectl edit cm metrics-server-config -n kube-system

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 kube-system

Konfigurationsanforderungen für Logging und Monitoring

Es gibt mehrere Konfigurationsanforderungen, um Cloud Logging und Cloud Monitoring mit Anthos-Cluster 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. 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

Für die Systemlogs und -messwerte von Anthos fallen keine Gebühren an.

In einem "Anthos-Cluster on Bare Metal"-Cluster enthalten die Anthos-Systemlogs und -Messwerte 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 Operations-Suite von Google Cloud.

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