In diesem Dokument wird gezeigt, wie Sie Logging und Monitoring für Systemkomponenten in GKE on VMware konfigurieren.
Folgende Optionen sind verfügbar:
- Cloud Logging und Cloud Monitoring
- Google Cloud Managed Service for Prometheus (Vorabversion)
- Prometheus und Grafana
Weitere Informationen zu den Optionen finden Sie unter Logging und Monitoring.
Überwachte Ressourcen
Mit überwachten Ressourcen stellt Google Ressourcen wie Cluster, Knoten, Pods und Container dar. Weitere Informationen finden Sie in der Dokumentation zu den Typen überwachter Ressourcen von Cloud Monitoring.
Zum Abfragen von Logs und Messwerten müssen Sie mindestens folgende Ressourcenlabels kennen:
project_id
: Projekt-ID des Logging-Monitoring-Projekts des Clusters Sie haben diesen Wert im Feldstackdriver.projectID
Ihrer Clusterkonfigurationsdatei angegeben.location
: Google Cloud-Region, in der Sie Cloud Logging-Logs und Cloud Monitoring-Messwerte speichern möchten. Es empfiehlt sich, eine Region auszuwählen, die sich in der Nähe Ihres lokalen Rechenzentrums befindet. Sie haben diesen Wert während der Installation im Feldstackdriver.clusterLocation
Ihrer Cluster-Konfigurationsdatei bereitgestellt.cluster_name
: Clustername, den Sie beim Erstellen des Clusters ausgewählt haben.Sie können den
cluster_name
-Wert entweder für den Administrator- oder den Nutzercluster abrufen, wenn Sie die benutzerdefinierte Stackdriver-Ressource prüfen:kubectl get stackdriver stackdriver --namespace kube-system \ --kubeconfig CLUSTER_KUBECONFIG --output yaml | grep 'clusterName:'
Wobei Folgendes gilt:
CLUSTER_KUBECONFIG
ist der Pfad zur kubeconfig-Datei des Administratorclusters oder Nutzerclusters, für die der Clustername erforderlich ist.
Cloud Logging verwenden
Sie müssen keine Maßnahmen ergreifen, um Cloud Logging für einen Cluster zu aktivieren.
Sie müssen jedoch das Google Cloud-Projekt angeben, in dem Sie Logs ansehen möchten. In der Clusterkonfigurationsdatei geben Sie das Google Cloud-Projekt im Abschnitt stackdriver
an.
Sie können auf Logs mit dem Log-Explorer in der Google Cloud Console zugreifen. So greifen Sie beispielsweise auf die Logs eines Containers zu:
- Öffnen Sie in der Google Cloud Console den Log-Explorer für Ihr Projekt.
- So finden Sie Logs für einen Container:
- Klicken Sie links oben auf das Drop-down-Menü für den Logkatalog und wählen Sie Kubernetes-Container aus.
- Wählen Sie den Clusternamen, den Namespace und dann einen Container aus der Hierarchie aus.
Logs für Controller im Bootstrap-Cluster ansehen
Pod-Name „onprem-admin-cluster-controller / clusterapi-controllers“ finden
Der Name des Clusters in der Art ist standardmäßig
gkectl-bootstrap-cluster
."ADMIN_CLUSTER_NAME" resource.type="k8s_container" resource.labels.cluster_name="gkectl-bootstrap-cluster"
Ändern Sie die Abfrage anhand des gefundenen Pod-Namens und rufen Sie das Log ab
resource.type="k8s_container" resource.labels.cluster_name="gkectl-bootstrap-cluster" resource.labels.pod_name="POD_NAME"
Cloud Monitoring verwenden
Sie müssen keine Maßnahmen ergreifen, um Cloud Monitoring für einen Cluster zu aktivieren.
Sie müssen jedoch das Google Cloud-Projekt angeben, in dem Sie Messwerte ansehen möchten.
In der Clusterkonfigurationsdatei geben Sie das Google Cloud-Projekt im Abschnitt stackdriver
an.
Mit Metrics Explorer können Sie aus über 1.500 Messwerten auswählen. So greifen Sie auf Metrics Explorer zu:
Wählen Sie in der Google Cloud Console Monitoring aus oder klicken Sie auf die folgende Schaltfläche:
Wählen Sie Ressourcen > Metrics Explorer.
Sie können sich Messwerte auch in Dashboards der Google Cloud Console ansehen. Informationen zum Erstellen von Dashboards und zum Aufrufen von Messwerten finden Sie unter Dashboards erstellen.
Monitoringdaten auf Flottenebene ansehen
Einen Gesamtüberblick über die Ressourcennutzung Ihrer Flotte mithilfe von Cloud Monitoring-Daten, einschließlich Ihrer GKE on VMware, erhalten Sie in der Übersicht zu GKE Enterprise in der Google Cloud Console. Weitere Informationen finden Sie unter GKE Enterprise – Übersicht.
Standardmäßige Kontingentlimits in Cloud Monitoring
GKE on VMware hat für jedes Projekt ein Standardlimit von 6.000 API-Aufrufen pro Minute. Wenn Sie dieses Limit überschreiten, werden Ihre Messwerte möglicherweise nicht angezeigt. Wenn Sie ein höheres Monitoring-Limit benötigen, fordern Sie dieses über die Google Cloud Console an.
Managed Service for Prometheus verwenden (Vorschau)
Google Cloud Managed Service for Prometheus ist Teil von Cloud Monitoring und ist optional. 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 VMware verwenden, können Sie dieselbe 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
Öffnen Sie das Stackdriver-Objekt stackdriver
zur Bearbeitung:
kubectl --kubeconfig CLUSTER_KUBECONFIG --namespace kube-system \ edit stackdriver stackdriver
Fügen Sie das Feature-Gate enableGMPForSystemMetrics
hinzu und legen Sie es auf true
fest:
apiVersion: addons.gke.io/v1alpha1 kind: Stackdriver metadata: name: stackdriver namespace: kube-system spec: featureGates: enableGMPForSystemMetrics: true
Schließen Sie die Bearbeitungssitzung.
Messwertdaten ansehen
Wenn Managed Service for Prometheus aktiviert 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:
histogram_quantile(0.95, sum(rate(apiserver_request_duration_seconds_bucket[5m])) by (le))
Wenn Sie MQL verwenden möchten, legen Sie die überwachte Ressource auf prometheus_target
fest und fügen Sie dem Messwert den Prometheus-Typ als Suffix hinzu.
MQL-Beispiel:
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, führen Sie die Schritte unter Mit Grafana abfragen aus, um eine Grafana-Datenquelle zu authentifizieren und zu konfigurieren, um Daten von 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:
Laden Sie die
.json
-Beispieldateien herunter:git clone https://github.com/GoogleCloudPlatform/anthos-samples.git cd anthos-samples/gmp-grafana-dashboards
Wenn Ihre Grafana-Datenquelle mit einem anderen Namen als
Managed Service for Prometheus
erstellt wurde, ändern Sie das Felddatasource
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.Rufen Sie die Grafana-UI in Ihrem Browser auf und wählen Sie im Menü Dashboards die Option + Import (+ Importieren) aus.
Laden Sie entweder die Datei
.json
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.Das importierte Dashboard sollte erfolgreich geladen werden, wenn GKE on VMware und die Datenquelle richtig konfiguriert sind. Der folgende Screenshot zeigt beispielsweise das von
cluster-capacity.json
konfigurierte Dashboard.
Weitere Ressourcen
Weitere Informationen zu Managed Service for Prometheus finden Sie hier:
Messwerte der GKE-Steuerungsebene sind mit PromQL kompatibel
Managed Service for Prometheus für Nutzeranwendungen in GKE on VMware verwenden
Prometheus und Grafana verwenden
Zum Aktivieren von Prometheus und Grafana öffnen Sie das Monitoring-Objekt mit dem Namen monitoring-sample
zur Bearbeitung:
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] edit \ monitoring monitoring-sample --namespace kube-system
Setzen Sie enablePrometheus
auf true
:
apiVersion: addons.gke.io/v1alpha1 kind: Monitoring metadata: labels: k8s-app: monitoring-operator name: monitoring-sample namespace: kube-system spec: channel: stable ... enablePrometheus: false
Schließen Sie die Bearbeitungssitzung.
Bekanntes Problem
In Nutzerclustern werden Prometheus und Grafana während des Upgrades automatisch deaktiviert. Die Konfigurations- und Messwertdaten gehen jedoch nicht verloren.
Zur Umgehung dieses Problems öffnen Sie nach dem Upgrade monitoring-sample
zum Bearbeiten. Setzen Sie enablePrometheus
auf true
.
Über Grafana-Dashboards auf Monitoring-Messwerte zugreifen
Grafana zeigt Messwerte aus Ihren Clustern an. Zur Anzeige dieser Messwerte müssen Sie auf die Dashboards von Grafana zugreifen:
Rufen Sie den Namen des im
kube-system
-Namespace eines Nutzerclusters ausgeführten Grafana-Pods ab:kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] -n kube-system get pods
Dabei ist [USER_CLUSTER_KUBECONFIG] die kubeconfig-Datei des Nutzerclusters.
Der Grafana-Pod hat einen HTTP-Server, der den TCP-localhost-Port 3000 überwacht. Leiten Sie einen lokalen Port zu Port 3000 im Pod weiter, damit Sie sich die Dashboards von Grafana in einem Webbrowser ansehen können.
Nehmen wir an, der Name des Pods lautet
grafana-0
. Um Port 50000 zu Port 3000 im Pod weiterzuleiten, geben Sie folgenden Befehl ein:kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] -n kube-system port-forward grafana-0 50000:3000
Gehen Sie in einem Webbrowser zu
http://localhost:50000
.Geben Sie auf der Anmeldeseite
admin
für den Nutzernamen und das Passwort ein.Wenn die Anmeldung erfolgreich ist, werden Sie aufgefordert, das Passwort zu ändern. Nachdem Sie das Standardpasswort geändert haben, sollte das Grafana Home Dashboard des Nutzerclusters geladen werden.
Sie können auf andere Dashboards zugreifen, wenn Sie links oben auf der Seite auf das Drop-down-Menü Startseite klicken.
Ein Beispiel für die Verwendung von Grafana finden Sie unter Grafana-Dashboard erstellen.
Auf Benachrichtigungen zugreifen
Der Prometheus Alertmanager erfasst Benachrichtigungen vom Prometheus-Server. Sie können sich diese Benachrichtigungen in einem Grafana-Dashboard ansehen. Dazu müssen Sie auf das Dashboard zugreifen:
Der Container im Pod
alertmanager-0
überwacht den TCP-Port 9093. Leiten Sie einen lokalen Port zu Port 9093 im Pod weiter:kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] port-forward \ -n kube-system alertmanager-0 50001:9093
Gehen Sie in einem Webbrowser zu
http://localhost:50001
.
Prometheus Alertmanager-Konfiguration ändern
Sie können die Standardkonfiguration von Prometheus Alertmanager ändern, wenn Sie die Datei monitoring.yaml
Ihres Nutzerclusters bearbeiten. Sie sollten dies tun, wenn Sie Benachrichtigungen an ein bestimmtes Ziel weiterleiten möchten, anstatt sie im Dashboard zu belassen. In der Prometheus-Dokumentation zur Konfiguration erfahren Sie, wie Sie Alertmanager konfigurieren.
So ändern Sie die Alertmanager-Konfiguration:
Kopieren Sie die Manifestdatei
monitoring.yaml
des Nutzerclusters:kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] -n kube-system \ get monitoring monitoring-sample -o yaml > monitoring.yaml
Nehmen Sie Änderungen an den Feldern unter
spec.alertmanager.yml
vor, um den Alertmanager zu konfigurieren. Wenn Sie fertig sind, speichern Sie das geänderte Manifest.Wenden Sie das Manifest auf Ihren Cluster an:
kubectl apply --kubeconfig [USER_CLUSTER_KUBECONIFG] -f monitoring.yaml
Prometheus-Ressourcen skalieren
Die Standardkonfiguration für das Monitoring unterstützt bis zu fünf Knoten. Bei größeren Clustern können Sie die Prometheus-Server-Ressourcen anpassen. Der empfohlene Wert pro Clusterknoten für CPU ist "50m" und der für Arbeitsspeicher "500Mi". Achten Sie darauf, dass Ihr Cluster zwei Knoten enthält, die jeweils genügend Ressourcen für Prometheus haben. Weitere Informationen finden Sie unter Größe eines Nutzerclusters anpassen.
Führen Sie die folgenden Schritte aus, um Prometheus-Server-Ressourcen zu ändern:
Kopieren Sie die Manifestdatei
monitoring.yaml
des Nutzerclusters:kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] -n kube-system get monitoring monitoring-sample -o yaml > monitoring.yaml
Wenn Sie Ressourcen überschreiben möchten, ändern Sie die Felder unter
spec.resourceOverride
. Wenn Sie fertig sind, speichern Sie das geänderte Manifest. Beispiel:spec: resourceOverride: - component: Prometheus resources: requests: cpu: 300m memory: 3000Mi limits: cpu: 300m memory: 3000Mi
Wenden Sie das Manifest auf Ihren Cluster an:
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] apply -f monitoring.yaml
Grafana-Dashboard erstellen
Sie haben eine Anwendung bereitgestellt, die einen Messwert bereitstellt, prüft, ob der Messwert verfügbar ist, und prüft, ob Prometheus den Messwert entfernt. Jetzt können Sie den Messwert auf Anwendungsebene einem benutzerdefinierten Grafana-Dashboard hinzufügen.
So erstellen Sie ein Grafana-Dashboard:
- Greifen Sie bei Bedarf auf Grafana zu.
- Klicken Sie im Dashboard auf der Startseite links oben auf das Drop-down-Menü auf Startseite.
- Klicken Sie im Menü auf der rechten Seite auf Neues Dashboard.
- Klicken Sie im Bereich New panel auf Graph. Ein leeres Grafik-Dashboard wird angezeigt.
- Klicken Sie auf Steuerfeldtitel und anschließend auf Bearbeiten. Im unteren Bereich Grafik wird der Tab Messwerte geöffnet.
- Wählen Sie im Drop-down-Menü der Datenquelle die Option Nutzer aus. Klicken Sie auf Abfrage hinzufügen und geben Sie
foo
in das Feld Suche ein. - Klicken Sie rechts oben auf die Schaltfläche Zurück zum Dashboard. Ihr Dashboard wird angezeigt.
- Zum Speichern des Dashboards klicken Sie rechts oben auf Dashboard speichern. Wählen Sie einen Namen für das Dashboard aus und klicken Sie auf Speichern.
Prometheus und Grafana deaktivieren
Wenn Sie das Monitoring innerhalb des Clusters deaktivieren möchten, machen Sie die am Objekt monitoring-sample
vorgenommenen Änderungen rückgängig:
Öffnen Sie das Objekt
monitoring-sample
zum Bearbeiten:kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit \ monitoring monitoring-sample --namespace kube-system
Ersetzen Sie USER_CLUSTER_KUBECONFIG durch die kubeconfig-Datei des Nutzerclusters.
Wenn Sie Prometheus und Grafana deaktivieren möchten, setzen Sie
enablePrometheus
auffalse
:apiVersion: addons.gke.io/v1alpha1 kind: Monitoring metadata: labels: k8s-app: monitoring-operator name: monitoring-sample namespace: kube-system spec: channel: stable ... enablePrometheus: false
Schließen Sie die Bearbeitungssitzung, um Ihre Änderungen zu speichern.
Prüfen Sie, ob die Statefulsets
prometheus-0
,prometheus-1
undgrafana-0
gelöscht wurden:kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods --namespace kube-system
Beispiel: Messwerte auf Anwendungsebene zu einem Grafana-Dashboard hinzufügen
In den folgenden Abschnitten erfahren Sie, wie Sie Messwerte für eine Anwendung hinzufügen. In diesem Abschnitt führen Sie die folgenden Aufgaben aus:
- Eine Beispielanwendung bereitstellen, die einen Messwert namens
foo
enthält - Prüfen, ob Prometheus den Messwert verfügbar macht und extrahiert
- Benutzerdefiniertes Grafana-Dashboard erstellen
Beispielanwendung bereitstellen
Die Beispielanwendung wird in einem einzelnen Pod ausgeführt. Der Container des Pods weist den Messwert foo
mit einem konstanten Wert von 40
auf.
Erstellen Sie das folgende Pod-Manifest pro-pod.yaml
:
apiVersion: v1 kind: Pod metadata: name: prometheus-example annotations: prometheus.io/scrape: 'true' prometheus.io/port: '8080' prometheus.io/path: '/metrics' spec: containers: - image: registry.k8s.io/prometheus-dummy-exporter:v0.1.0 name: prometheus-example command: - /bin/sh - -c - ./prometheus_dummy_exporter --metric-name=foo --metric-value=40 --port=8080
Wenden Sie dann das Pod-Manifest auf Ihren Nutzercluster an:
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] apply -f pro-pod.yaml
Prüfen, ob der Messwert verfügbar ist und extrahiert wurde
Der Container im Pod
prometheus-example
überwacht den TCP-Port 8080. Leiten Sie einen lokalen Port zu Port 8080 im Pod weiter:kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] port-forward prometheus-example 50002:8080
Führen Sie den folgenden Befehl aus, um zu prüfen, ob die Anwendung den Messwert verfügbar macht:
curl localhost:50002/metrics | grep foo
Der Befehl gibt die folgende Ausgabe zurück:
# HELP foo Custom metric # TYPE foo gauge foo 40
Der Container im Pod
prometheus-0
überwacht den TCP-Port 9090. Leiten Sie einen lokalen Port zu Port 9090 im Pod weiter:kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] port-forward prometheus-0 50003:9090
Wenn Sie prüfen möchten, ob Prometheus den Messwert erfasst, rufen Sie http://localhost:50003/targets auf. Dadurch sollten Sie zum Pod
prometheus-0
unter der Zielgruppeprometheus-io-pods
gelangen.Rufen Sie zum Ansehen von Messwerten in Prometheus http://localhost:50003/graph auf. Geben Sie im Feld Suche
foo
ein und klicken Sie auf Ausführen. Auf der Seite sollte der Messwert angezeigt werden.
Benutzerdefinierte Stackdriver-Ressource konfigurieren
Wenn Sie einen Cluster erstellen, erstellt GKE on VMware automatisch eine benutzerdefinierte Stackdriver-Ressource. Sie können die Spezifikation in der benutzerdefinierten Ressource bearbeiten und die Standardwerte für CPU- und Arbeitsspeicheranforderungen sowie die Limits für eine Stackdriver-Komponente überschreiben. Die Standardspeichergröße und die Speicherklasse lassen sich separat überschreiben.
Standardwerte für Anfragen und Limits für CPU und Arbeitsspeicher überschreiben
So überschreiben Sie diese Standardeinstellungen:
Öffnen Sie die benutzerdefinierte Stackdriver-Ressource in einem Befehlszeileneditor:
kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver
Dabei ist KUBECONFIG der Pfad der kubeconfig-Datei für den Cluster. Dies kann entweder ein Administratorcluster oder ein Nutzercluster sein.
Fügen Sie in der benutzerdefinierten Stackdriver-Ressource das Feld
resourceAttrOverride
im Abschnittspec
hinzu:resourceAttrOverride: POD_NAME_WITHOUT_RANDOM_SUFFIX/CONTAINER_NAME: LIMITS_OR_REQUESTS: RESOURCE: RESOURCE_QUANTITY
Beachten Sie, dass das Feld
resourceAttrOverride
alle vorhandenen Standardlimits und -anfragen für die angegebene Komponente überschreibt. Eine Beispieldatei sieht so aus:apiVersion: addons.gke.io/v1alpha1 kind: Stackdriver metadata: name: stackdriver namespace: kube-system spec: projectID: my-project clusterName: my-cluster clusterLocation: us-west-1a resourceAttrOverride: stackdriver-prometheus-k8s/prometheus-server: limits: cpu: 500m memory: 3000Mi requests: cpu: 300m memory: 2500Mi
Speichern Sie die Änderungen und beenden Sie den Befehlszeileneditor.
Prüfen Sie den Status der Pods:
kubectl --kubeconfig=KUBECONFIG -n kube-system get pods | grep stackdriver
Ein fehlerfreier Pod sieht beispielsweise so aus:
stackdriver-prometheus-k8s-0 2/2 Running 0 5d19h
Sehen Sie in der Pod-Spezifikation der Komponente nach, ob die Ressourcen richtig festgelegt sind.
kubectl --kubeconfig=KUBECONFIG -n kube-system describe pod POD_NAME
Dabei ist
POD_NAME
der Name des Pods, den Sie gerade geändert haben. z. B.stackdriver-prometheus-k8s-0
.Die Antwort sieht in etwa so aus:
Name: stackdriver-prometheus-k8s-0 Namespace: kube-system ... Containers: prometheus-server: Limits: cpu: 500m memory: 3000Mi Requests: cpu: 300m memory: 2500Mi ...
Standardeinstellungen für die Speichergröße überschreiben
So überschreiben Sie diese Standardeinstellungen:
Öffnen Sie die benutzerdefinierte Stackdriver-Ressource in einem Befehlszeileneditor:
kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver
Fügen Sie das Feld
storageSizeOverride
im Abschnittspec
hinzu. Sie können die Komponentestackdriver-prometheus-k8s
oderstackdriver-prometheus-app
verwenden. Der Abschnitt hat dieses Format:storageSizeOverride: STATEFULSET_NAME: SIZE
In diesem Beispiel werden das StatefulSet
stackdriver-prometheus-k8s
und die Größe120Gi
verwendet.apiVersion: addons.gke.io/v1alpha1 kind: Stackdriver metadata: name: stackdriver namespace: kube-system spec: projectID: my-project clusterName: my-cluster clusterLocation: us-west-1a storageSizeOverride: stackdriver-prometheus-k8s: 120Gi
Speichern Sie und beenden Sie den Befehlszeileneditor.
Prüfen Sie den Status der Pods:
kubectl --kubeconfig=KUBECONFIG -n kube-system get pods | grep stackdriver
Ein fehlerfreier Pod sieht beispielsweise so aus:stackdriver-prometheus-k8s-0 2/2 Running 0 5d19h
Prüfen Sie die Pod-Spezifikation der Komponente, um zu gewährleisten, dass die Speichergröße korrekt überschrieben wird.
kubectl --kubeconfig=KUBECONFIG -n kube-system describe statefulset STATEFULSET_NAME
Die Antwort sieht in etwa so aus:
Volume Claims: Name: my-statefulset-persistent-volume-claim StorageClass: my-storage-class Labels: Annotations: Capacity: 120Gi Access Modes: [ReadWriteOnce]
Standardeinstellungen für Speicherklasse überschreiben
Voraussetzung
Sie müssen zuerst die StorageClass erstellen, die Sie verwenden möchten.
So überschreiben Sie die Standardspeicherklasse für nichtflüchtige Volumes, die von Logging- und Monitoring-Komponenten angefordert werden:
Öffnen Sie die benutzerdefinierte Stackdriver-Ressource in einem Befehlszeileneditor:
kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver
Dabei ist KUBECONFIG der Pfad der kubeconfig-Datei für den Cluster. Dies kann entweder ein Administratorcluster oder ein Nutzercluster sein.
Fügen Sie das Feld
storageClassName
im Abschnittspec
hinzu:storageClassName: STORAGECLASS_NAME
Das Feld
storageClassName
überschreibt die vorhandene Standardspeicherklasse und gilt für alle Logging- und Monitoring-Komponenten mit angeforderten nichtflüchtigen Volumes. Eine Beispieldatei sieht so aus:apiVersion: addons.gke.io/v1alpha1 kind: Stackdriver metadata: name: stackdriver namespace: kube-system spec: projectID: my-project clusterName: my-cluster clusterLocation: us-west-1a proxyConfigSecretName: my-secret-name enableVPC:
optimizedMetrics: true storageClassName: my-storage-class Speichern Sie die Änderungen.
Prüfen Sie den Status der Pods:
kubectl --kubeconfig=KUBECONFIG -n kube-system get pods | grep stackdriver
Ein fehlerfreier Pod sieht beispielsweise so aus:
stackdriver-prometheus-k8s-0 1/1 Running 0 5d19h
Prüfen Sie in der Pod-Spezifikation einer Komponente, ob die Speicherklasse korrekt eingerichtet ist.
kubectl --kubeconfig=KUBECONFIG -n kube-system describe statefulset STATEFULSET_NAME
Unter Verwendung des zustandsorientierten Sets
stackdriver-prometheus-k8s
sieht die Antwort beispielsweise so aus:Volume Claims: Name: stackdriver-prometheus-data StorageClass: my-storage-class Labels: Annotations: Capacity: 120Gi Access Modes: [ReadWriteOnce]
Optimierte Messwerte deaktivieren
Standardmäßig erfassen die im Cluster ausgeführten Messwert-Agents einen optimierten Satz von Container-, Kubelet- und kube-state-metrics-Messwerten und melden sie an Stackdriver. Wenn Sie zusätzliche Messwerte benötigen, empfehlen wir Ihnen, einen Ersatz aus der Liste der GKE Enterprise-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 optimierte Standardeinstellung für kube-state-metrics-Messwerte (nicht empfohlen):
Öffnen Sie die benutzerdefinierte Stackdriver-Ressource in einem Befehlszeileneditor:
kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver
Dabei ist KUBECONFIG der Pfad der kubeconfig-Datei für den Cluster. Dies kann entweder ein Administratorcluster oder ein Nutzercluster sein.
Setzen Sie das Feld
optimizedMetrics
auffalse
:apiVersion: addons.gke.io/v1alpha1 kind: Stackdriver metadata: name: stackdriver namespace: kube-system spec: projectID: my-project clusterName: my-cluster clusterLocation: us-west-1a proxyConfigSecretName: my-secret-name enableVPC:
optimizedMetrics: false storageClassName: my-storage-class Speichern Sie die Änderungen und schließen Sie den Befehlszeilen-Editor.
Bekanntes Problem: Cloud Monitoring-Fehlerbedingung
(Problem-ID 159761921)
Unter bestimmten Umständen kann der standardmäßige Cloud Monitoring-Pod, der standardmäßig in jedem neuen Cluster bereitgestellt wird, nicht mehr reagieren.
Wenn Cluster aktualisiert werden, können beispielsweise Speicherdaten beschädigt werden, wenn Pods in statefulset/prometheus-stackdriver-k8s
neu gestartet werden.
Insbesondere der Monitoring-Pod stackdriver-prometheus-k8s-0
kann in eine Schleife geraten, wenn beschädigte Daten das Schreiben von prometheus-stackdriver-sidecar
in den Cluster-Speicher PersistentVolume
verhindern.
Sie können den Fehler manuell diagnostizieren und wiederherstellen, indem Sie die folgenden Schritte ausführen.
Cloud Monitoring-Fehler diagnostizieren
Wenn der Monitoring-Pod fehlgeschlagen ist, geben die Logs Folgendes aus:
{"log":"level=warn ts=2020-04-08T22:15:44.557Z caller=queue_manager.go:534 component=queue_manager msg=\"Unrecoverable error sending samples to remote storage\" err=\"rpc error: code = InvalidArgument desc = One or more TimeSeries could not be written: One or more points were written more frequently than the maximum sampling period configured for the metric.: timeSeries[0-114]; Unknown metric: kubernetes.io/anthos/scheduler_pending_pods: timeSeries[196-198]\"\n","stream":"stderr","time":"2020-04-08T22:15:44.558246866Z"}
{"log":"level=info ts=2020-04-08T22:15:44.656Z caller=queue_manager.go:229 component=queue_manager msg=\"Remote storage stopped.\"\n","stream":"stderr","time":"2020-04-08T22:15:44.656798666Z"}
{"log":"level=error ts=2020-04-08T22:15:44.663Z caller=main.go:603 err=\"corruption after 29032448 bytes: unexpected non-zero byte in padded page\"\n","stream":"stderr","time":"2020-04-08T22:15:44.663707748Z"}
{"log":"level=info ts=2020-04-08T22:15:44.663Z caller=main.go:605 msg=\"See you next time!\"\n","stream":"stderr","time":"2020-04-08T22:15:44.664000941Z"}
Wiederherstellung nach dem Cloud Monitoring-Fehler
So stellen Sie Cloud Monitoring manuell wieder her:
Beenden Sie das Clustermonitoring. Den Operator
stackdriver
herunterskalieren, um den Monitoring-Abgleich zu verhindern:kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system scale deployment stackdriver-operator --replicas 0
Löschen Sie die Arbeitslasten der Monitoring-Pipeline:
kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system delete statefulset stackdriver-prometheus-k8s
Löschen Sie die PersistentVolumeClaims (PVCs) der Monitoring-Pipeline:
kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system delete pvc -l app=stackdriver-prometheus-k8s
Starten Sie das Clustermonitoring neu. Skalieren Sie den Stackdriver-Operator hoch, um eine neue Monitoring-Pipeline zu installieren und den Abgleich fortzusetzen:
kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system scale deployment stackdriver-operator --replicas=1