Diese Seite wurde von der Cloud Translation API übersetzt.

Fehlerbehebung bei der Beobachtbarkeit

In diesem Dokument wird beschrieben, wie Sie Bereitstellungsfehler und Betriebsereignisse erkennen, die in der Air-Gap-Appliance von Google Distributed Cloud (GDC) auftreten können. Außerdem enthält es Beschreibungen aller im System angezeigten Benachrichtigungen, die Ihnen helfen, häufige Probleme mit Logging- und Monitoring-Komponenten zu beheben.

Observability-Komponenten identifizieren

Die Observability-Plattform stellt ihre Komponenten im Namespace obs-system im Infrastrukturcluster der Organisation bereit.

Die Grafana-Instanz des Infrastructure Operator (IO) bietet Zugriff auf Messwerte auf Organisationsebene, um Infrastrukturkomponenten wie CPU-Auslastung und Speicherverbrauch zu überwachen. Außerdem bietet es Zugriff auf Betriebs- und Audit-Logs. Außerdem bietet es Zugriff auf Benachrichtigungen, Logs und Messwerte der GDC-kompatiblen Komponenten.

Für die Monitoring- und Logging-Stacks von GDC werden Open-Source-Lösungen als Teil der Observability-Plattform verwendet. Diese Komponenten erfassen Logs und Messwerte von Kubernetes-Pods, Bare-Metal-Maschinen, Netzwerk-Switches, Speicher und verwalteten Diensten.

In der folgenden Tabelle werden alle Komponenten beschrieben, die in die Observability-Plattform integriert sind:

Komponente	Beschreibung
`Prometheus`	Prometheus ist eine Zeitreihendatenbank zum Erfassen und Speichern von Messwerten und zum Auswerten von Benachrichtigungen. Prometheus speichert Messwerte zur langfristigen Speicherung in der Cortex-Instanz des Infrastrukturclusters der Organisation. Prometheus fügt Labels als Schlüssel/Wert-Paare hinzu und erfasst Messwerte von Kubernetes-Knoten, ‑Pods, Bare-Metal-Maschinen, Netzwerk-Switches und Speichergeräten.
`Alertmanager`	Alertmanager ist ein benutzerdefiniertes Managementsystem, das Benachrichtigungen sendet, wenn Protokolle oder Messwerte darauf hinweisen, dass Systemkomponenten ausfallen oder nicht normal funktionieren. Er verwaltet das Routing, die Stummschaltung und die Aggregation von Prometheus-Benachrichtigungen.
`Loki`	Loki ist eine Zeitreihendatenbank, in der Logs aus verschiedenen Quellen gespeichert und zusammengefasst werden. Sie indexiert Logs für effiziente Abfragen.
`Grafana`	Grafana bietet eine Benutzeroberfläche (UI) zum Ansehen von Messwerten, die von Prometheus erfasst werden, und zum Abfragen von Audit- und Betriebsprotokollen aus den entsprechenden Loki-Instanzen. Über die Benutzeroberfläche können Sie Dashboards mit Messwerten und Benachrichtigungen visualisieren.
`Fluent Bit`	Fluent Bit ist ein Prozessor, der Logs aus verschiedenen Komponenten oder Standorten abruft und an Loki sendet. Es wird auf jedem Knoten aller Cluster ausgeführt.

Bereitstellungsfehler identifizieren

Wenn Ihre Bereitstellung ausgeführt wird und fehlerfrei ist, werden die Komponenten im Status READY ausgeführt.

Führen Sie die folgenden Schritte aus, um Bereitstellungsfehler zu ermitteln:

Aktuellen Status einer Komponente bestätigen:
```
kubectl get -n obs-system TYPE/COMPONENT
```
Ersetzen Sie Folgendes:
- TYPE: der Komponententyp
- COMPONENT: der Komponentenname
Die Ausgabe sollte in etwa so aussehen:
```
NAME       READY  AGE
COMPONENT  1/1    23h
```
Wenn die Komponente fehlerfrei ist, wird in der Spalte READY der Ausgabe der Wert N/N angezeigt. Wenn in der Spalte READY kein Wert angezeigt wird, bedeutet das nicht unbedingt, dass ein Fehler aufgetreten ist. Die Bearbeitung des Dienstes kann länger dauern.
Prüfen Sie die Pods in jeder Komponente:
```
kubectl get pods -n obs-system | awk 'NR==1 | /COMPONENT/'
```
Ersetzen Sie COMPONENT durch den Namen der Komponente.

Die Ausgabe sollte in etwa so aussehen:
```
NAME       READY  STATUS   RESTARTS  AGE
COMPONENT  1/1    Running  0         23h
```
Prüfen Sie, ob in der Spalte READY der Wert N/N, in der Spalte STATUS der Wert Running und in der Spalte RESTARTS ein Wert angezeigt wird, der nicht größer als 2 ist.

Eine hohe Anzahl von Neustarts deutet auf folgende Symptome hin:
- Die Pods schlagen fehl und Kubernetes startet sie neu.
- In der Spalte STATUS wird der Wert CrashLoopBackoff angezeigt.
Rufen Sie die Logs der Pods auf, um den Fehlerstatus zu beheben.

Wenn sich ein Pod im Status PENDING befindet, weist dies auf eines oder mehrere der folgenden Symptome hin:
- Der Pod wartet auf den Netzwerkzugriff, um den erforderlichen Container herunterzuladen.
- Ein Konfigurationsproblem verhindert, dass der Pod gestartet wird. Beispielsweise fehlt ein Secret-Wert, der für den Pod erforderlich ist.
- In Ihrem Kubernetes-Cluster sind keine Ressourcen mehr verfügbar, um den Pod zu planen. Das passiert, wenn viele Anwendungen im Cluster ausgeführt werden.
So ermitteln Sie die Ursache für den Status PENDING:
```
kubectl describe -n obs-system pod/POD_NAME
```
Ersetzen Sie POD_NAME durch den Namen des Pods, in dem der Status PENDING angezeigt wird.

Die Ausgabe enthält weitere Details zum Pod.

Rufen Sie den Abschnitt Events der Ausgabe auf, um eine Tabelle mit den letzten Ereignissen des Pods und eine Zusammenfassung der Ursache des Status PENDING aufzurufen.

Die folgende Ausgabe zeigt ein Beispiel für den Events-Abschnitt für ein Grafana-StatefulSet-Objekt:

Events:
  Type    Reason            Age                From                    Message
  ----    ------            ----               ----                    -------
  Normal  SuccessfulCreate  13s (x3 over 12d)  statefulset-controller  create Pod grafana-0 in StatefulSet grafana successful

Wenn in Ihrem Pod oder einer anderen Ressource über einen längeren Zeitraum keine Ereignisse vorhanden sind, erhalten Sie die folgende Ausgabe:

  Events:         <none>

Prüfen, ob der Observability-Logging-Stack ausgeführt wird

Führen Sie die folgenden Schritte aus, um zu prüfen, ob der Logging-Stack ausgeführt wird:

Prüfen Sie, ob in alle Loki-Instanzen oder -Pods der Istio-Sidecar eingefügt wurde. Prüfen Sie, ob in alle Fluent Bit-Pods mit den Namen anthos-audit-logs-forwarder-SUFFIX und anthos-log-forwarder-SUFFIX der Istio-Sidecar eingefügt wurde.
Prüfen Sie, ob alle Loki-Instanzen im Infrastrukturcluster der Organisation fehlerfrei ausgeführt werden.
Prüfen Sie den Status der Objekte anthos-audit-logs-forwarder und anthos-log-forwarder DaemonSet, um zu bestätigen, dass alle Instanzen auf allen Knoten fehlerfrei ausgeführt werden.
Prüfen Sie, ob Sie die Betriebslogs von kube-apiserver-SUFFIX-Containern und Audit-Logs vom Kubernetes API-Server für die letzten fünf Minuten in allen Clustern erhalten. Führen Sie dazu die folgenden Abfragen in der Grafana-Instanz aus:
- Betriebsprotokolle: sum (count_over_time({service_name="apiserver"} [5m])) by (cluster, fluentbit_pod)
- Audit-Logs: sum (count_over_time({cluster=~".+"} [5m])) by (cluster, node)
Sie müssen für alle Knoten der Steuerungsebene im Infrastrukturcluster der Organisation Werte ungleich null erhalten.

Prüfen, ob der Observability-Monitoring-Stack ausgeführt wird

Führen Sie die folgenden Schritte aus, um zu prüfen, ob der Monitoring-Stack ausgeführt wird:

Prüfen Sie, ob die Grafana-Instanzen im Infrastrukturcluster der Organisation ausgeführt werden. Die grafana-0-Pods müssen in den folgenden Namespaces fehlerfrei ausgeführt werden:
- obs-system
- infra-obs-obs-system
- platform-obs-obs-system
Hinweis: In anderen PROJECT_NAMESPACE-obs-system-Namespaces werden möglicherweise Grafana-Instanzen ausgeführt. Die Instanzen variieren je nach Cluster.

Prüfen Sie, ob sich alle Monitoring-Komponenten im Istio-Service-Mesh befinden. Führen Sie die Schritte im Abschnitt Bereitstellungsfehler identifizieren aus. In der Spalte READY muss für jeden der folgenden Pods angezeigt werden, dass alle Container bereit sind. Ein Wert von 3/3 bedeutet beispielsweise, dass drei von drei Containern bereit sind. Außerdem müssen die Pods einen istio-proxy-Container haben. Wenn die Pods diese Bedingungen nicht erfüllen, starte den Pod neu:

Pod-Name	Anzahl der bereiten Container
`cortex-`	`2/2`
`cortex-etcd-0`	`2/2`
`cortex-proxy-server-`	`2/2`
`cortex-tenant-`	`2/2`
`meta-blackbox-exporter-`	`2/2`
`meta-grafana-0`	`3/3`
`meta-grafana-proxy-server-`	`2/2`
`meta-prometheus-0`	`4/4`
`cortex-alertmanager-`	`2/2`
`cortex-compactor-`	`2/2`
`cortex-distributor-`	`2/2`
`cortex-etcd-0`	`2/2`
`cortex-ingester-`	`2/2`
`cortex-querier-`	`2/2`
`cortex-query-frontend-`	`2/2`
`cortex-query-scheduler-`	`2/2`
`cortex-ruler-`	`2/2`
`cortex-store-gateway-`	`2/2`
`cortex-tenant-`	`2/2`
`grafana-proxy-server-`	`2/2`
`meta-blackbox-exporter-`	`2/2`
`meta-grafana-0`	`3/3`
`meta-grafana-proxy-server-*`	`2/2`
`meta-prometheus-0`	`4/4`

Achten Sie darauf, dass Cortex ohne Fehler ausgeführt wird.

Beobachtbarkeitslogs abrufen

In der folgenden Tabelle finden Sie die Befehle, die Sie ausführen müssen, um die Logs für die einzelnen Komponenten abzurufen, die von der Observability-Plattform bereitgestellt werden.

Komponente	Befehl zum Abrufen von Logs
`grafana`	`kubectl logs -n obs-system statefulset/grafana`
`anthos-prometheus-k8s`	`kubectl logs -n obs-system statefulset/anthos-prometheus-k8s`
`alertmanager`	`kubectl logs -n obs-system statefulset/alertmanager`
`ops-logs-loki-io`	`kubectl logs -n obs-system statefulset/ops-logs-loki-io`
`ops-logs-loki-io-read`	`kubectl logs -n obs-system statefulset/ops-logs-loki-io-read`
`ops-logs-loki-all`	`kubectl logs -n obs-system statefulset/ops-logs-loki-all`
`ops-logs-loki-all-read`	`kubectl logs -n obs-system statefulset/ops-logs-loki-all-read`
`audit-logs-loki-io`	`kubectl logs -n obs-system statefulset/audit-logs-loki-io`
`audit-logs-loki-io-read`	`kubectl logs -n obs-system statefulset/audit-logs-loki-io-read`
`audit-logs-loki-pa`	`kubectl logs -n obs-system statefulset/audit-logs-loki-pa`
`audit-logs-loki-pa-read`	`kubectl logs -n obs-system statefulset/audit-logs-loki-pa-read`
`audit-logs-loki-all`	`kubectl logs -n obs-system statefulset/audit-logs-loki-all`
`audit-logs-loki-all-read`	`kubectl logs -n obs-system statefulset/audit-logs-loki-all-read`
`anthos-log-forwarder`	`kubectl logs -n obs-system daemonset/anthos-log-forwarder`
`anthos-audit-logs-forwarder`	`kubectl logs -n obs-system daemonset/anthos-audit-logs-forwarder`
`oplogs-forwarder`	`kubectl logs -n obs-system daemonset/oplogs-forwarder`
`logmon-operator`	`kubectl logs -n obs-system deployment/logmon-operator`

Wenn Sie die Logs der vorherigen Instanz einer Komponente aufrufen möchten, fügen Sie das Flag -p am Ende jedes Befehls hinzu. Wenn Sie das Flag -p hinzufügen, können Sie Logs einer zuvor fehlgeschlagenen Instanz anstelle der aktuell ausgeführten Instanz aufrufen.

Konfiguration ansehen

Der Observability-Stack verwendet benutzerdefinierte Kubernetes API-Ressourcen, um Monitoring- und Logging-Pipelines zu konfigurieren.

Die benutzerdefinierte Ressource LoggingPipeline wird im Infrastrukturcluster der Organisation bereitgestellt und konfiguriert Loki-Instanzen.

Die folgenden Befehle zeigen die verfügbaren Aktionen, die Sie für die Logging-Pipeline ausführen können:

So rufen Sie die aktuelle Konfiguration Ihrer Logging-Pipeline-Bereitstellung auf:
```
kubectl get loggingpipeline -n obs-system default -o yaml
```
Konfiguration der Bereitstellung Ihrer Logging-Pipeline ändern:
```
kubectl edit loggingpipeline -n obs-system default
```

GDC verwendet einen Logging- und Monitoring-Operator namens logmon-operator, um die Bereitstellung von Observability-Komponenten wie Prometheus und Fluent Bit zu verwalten. Die API für die logmon-operator-Komponente ist die benutzerdefinierte Ressourcendefinition logmon. Die benutzerdefinierte Ressourcendefinition logmon weist logmon-operator an, wie die Observability für Ihre Bereitstellung konfiguriert wird. Diese benutzerdefinierte Ressourcendefinition enthält die Eigenschaften von Volumes zum Speichern Ihrer Messwerte, Benachrichtigungsregeln für Alertmanager, Prometheus-Konfigurationen zum Erfassen von Messwerten und Grafana-Konfigurationen für Dashboards.

Die folgenden Befehle zeigen die verfügbaren Aktionen, die Sie für die benutzerdefinierte Ressourcendefinition logmon ausführen können:

So rufen Sie die aktuelle Konfiguration für Ihre Observability-Bereitstellung auf:
```
kubectl get logmon -n obs-system logmon-default -o yaml
```

Konfiguration der Observability-Bereitstellung ändern:

kubectl edit logmon -n obs-system logmon-default

Die Ausgabe der beiden Befehle kann auf mehrere Kubernetes-ConfigMap-Objekte für die weitere Konfiguration verweisen. Sie können beispielsweise Alertmanager-Regeln in einem separaten ConfigMap-Objekt konfigurieren, auf das in der benutzerdefinierten Ressourcendefinition logmon nach Name verwiesen wird. Sie können die Alertmanager-Konfiguration über die benutzerdefinierte Ressourcendefinition logmon mit dem Namen gpc-alertmanager-config ändern und ansehen.

So rufen Sie die Alertmanager-Konfiguration auf:

kubectl get configmap -n obs-system gpc-alertmanager-config -o yaml

Allgemeine Probleme

Dieser Abschnitt enthält häufige Probleme, die bei der Bereitstellung der Observability-Plattform auftreten können.

Sie können nicht auf Grafana zugreifen

Standardmäßig ist Grafana nicht für Maschinen außerhalb Ihres Kubernetes-Clusters verfügbar. Wenn Sie vorübergehend von außerhalb des Infrastrukturclusters der Organisation auf die Grafana-Oberfläche zugreifen möchten, können Sie den Port Service an den Localhost weiterleiten. So leiten Sie den Port des Service weiter:

kubectl port-forward -n gpc-system service/grafana 33000\:3000

Rufen Sie in Ihrem Webbrowser http://localhost:33000 auf, um das Grafana-Dashboard für Ihre Bereitstellung aufzurufen. Drücken Sie die Tasten Strg+C, um den Vorgang zu beenden.

Grafana läuft langsam

Wenn Grafana langsam ausgeführt wird, kann das folgende Ursachen haben:

Abfragen an Prometheus oder Loki geben zu viele Daten zurück.
Abfragen geben mehr Daten zurück, als in einem einzelnen Diagramm sinnvoll dargestellt werden können.

Wenn Grafana langsam ist, prüfen Sie die Abfragen in Ihren benutzerdefinierten Grafana-Dashboards. Wenn die Abfragen mehr Daten zurückgeben, als in einem einzelnen Diagramm sinnvoll dargestellt werden können, sollten Sie die angezeigte Datenmenge reduzieren, um die Dashboardleistung zu verbessern.

Im Grafana-Dashboard werden keine Messwerte oder Logs angezeigt

Wenn in Grafana keine Messwerte oder Logs angezeigt werden, kann das folgende Gründe haben:

Grafana-Datenquellen sind nicht richtig festgelegt.
Das System hat Verbindungsprobleme mit Monitoring- oder Logging-Datenquellen.
Das System erfasst keine Messwerte oder Protokolle.

So rufen Sie die Logs und Messwerte auf:

Klicken Sie in der Grafana-Benutzeroberfläche auf Dashboard settings (Dashboard-Einstellungen).
Wählen Sie Datenquellen aus.
Prüfen Sie auf der Seite Datenquellen, ob die folgenden Quellen angezeigt werden:

Name	Organisation	URL
`Audit Logs`	`All`	`http://audit-logs-loki-io-read.obs-system.svc:3100`
`Operational Logs`	`Root`	`http://ops-logs-loki-io-read.obs-system.svc:3100`
`Operational Logs`	`Org`	`http://ops-logs-loki-all-read.obs-system.svc:3100`
`prometheus`		`http://anthos-prometheus-k8s.obs-system.svc:9090`

Wenn diese Datenquellen fehlen, konnte der Observability-Stack Grafana nicht richtig konfigurieren.

Wenn Sie die Datenquellen richtig konfiguriert haben, aber keine Daten angezeigt werden, kann das auf ein Problem mit Service-Objekten hinweisen, die Messwerte oder Logs für Prometheus oder Loki erfassen.

Prometheus verwendet ein Pull-Modell, um Messwerte zu erfassen. Dabei werden Ihre Service-Objekte regelmäßig nach Messwerten abgefragt und die gefundenen Werte gespeichert. Damit Prometheus Ihre Service-Objekte für die Erfassung von Messwerten erkennen kann, muss Folgendes zutreffen:

Alle Pods für Service-Objekte sind mit 'monitoring.gke.io/scrape: "true"' annotiert.

Hinweis :Wenn Ihr Dienst eine Bereitstellung oder ein StatefulSet-Objekt ist, fügen Sie die Annotation dem Dienst hinzu, damit sie von Kubernetes auf Ihre Pods übertragen wird.
Im Prometheus-Messwertformat werden die Pod-Messwerte über HTTP bereitgestellt. Standardmäßig sucht Prometheus nach diesen Messwerten am Endpunkt http://POD_NAME:80/metrics. Bei Bedarf können Sie Port, Endpunkt und Schema über Anmerkungen überschreiben.

Fluent Bit erfasst Logs und soll auf jedem Knoten Ihrer Kubernetes-Cluster ausgeführt werden. Fluent Bit sendet die Logs zur langfristigen Speicherung an Loki.

Wenn in Grafana keine Logs vorhanden sind, versuchen Sie es mit den folgenden Problemumgehungen:

Prüfen Sie die Logs der Loki-Instanzen, um sicherzustellen, dass sie ohne Fehler ausgeführt werden.
Wenn die Loki-Instanzen ordnungsgemäß ausgeführt werden, die Logs aber nicht angezeigt werden, prüfen Sie die Logs in Fluent Bit, um sicherzustellen, dass der Dienst wie erwartet funktioniert. Informationen zum Abrufen von Logs finden Sie unter Observability-Logs abrufen.

Alertmanager öffnet keine Benachrichtigungen

Wenn Alertmanager keine Benachrichtigungen öffnet, gehen Sie so vor:

Prüfen Sie, ob das Label logmon: system_metrics im configMap-Objekt im Namespace gpc-system vorhanden ist.
Prüfen Sie, ob der Datenabschnitt configMap einen Schlüssel mit dem Namen alertmanager.yml enthält. Der Wert für den Schlüssel alertmanager.yml muss den Alarmregeln entsprechen, die in Ihrer gültigen Alertmanager-Konfigurationsdatei enthalten sind.
Achten Sie darauf, dass die benutzerdefinierte Ressourcendefinition logmon mit dem Namen logmon-default im Namespace gpc-system einen Verweis auf das Objekt configMap enthält. Die benutzerdefinierte Ressourcendefinition logmon-default muss den Namen des configMap-Objekts enthalten, wie im folgenden Beispiel gezeigt:
```
apiVersion: addons.gke.io/v1
kind: Logmon
spec:
  system_metrics:
    outputs:
      default_prometheus:
        deployment:
          components:
            alertmanager:
              alertmanagerConfigurationConfigmaps:
                - alerts-config
```
Der Wert alerts-config im Beispiel ist der Name Ihres configMap-Objekts.

Alertmanager sendet keine Benachrichtigungen an die konfigurierten Benachrichtigungskanäle

Ein Konfigurationsfehler kann verhindern, dass Sie Benachrichtigungen in der externen Software erhalten, die Sie als Benachrichtigungskanal konfiguriert haben, z. B. Slack, auch wenn Alertmanager Warnungen in der Grafana-Instanz generiert.

So erhalten Sie Benachrichtigungen in Ihrer externen Software:

Prüfen Sie, ob die Werte in Ihrer Alertmanager-Konfigurationsdatei richtig formatiert sind. Wenn Alertmanager einen Alarm auslöst, wird ein Webhook in der externen Software abgefragt.
Prüfen Sie, ob die Webhook-URLs, die eine Verbindung zur externen Software herstellen, korrekt sind. Wenn die URLs korrekt sind, prüfen Sie, ob die Software für die Annahme von Webhooks konfiguriert ist. Möglicherweise müssen Sie einen API-Schlüssel generieren, um auf die API des externen Dienstes zuzugreifen. Es kann auch sein, dass Ihr aktueller API-Schlüssel abgelaufen ist und Sie ihn aktualisieren müssen.
Wenn sich der externe Dienst außerhalb Ihrer GDC-Air-Gap-Appliance-Bereitstellung befindet, müssen Sie dafür sorgen, dass die Regeln für ausgehenden Traffic für Ihren Organisationsinfrastrukturcluster konfiguriert sind. Mit dieser Konfiguration kann Alertmanager Anfragen an einen Dienst außerhalb des internen Kubernetes-Netzwerks senden. Wenn die Egress-Regeln nicht überprüft werden, kann es sein, dass Alertmanager die externe Software nicht findet.

Sie können keine Messwerte für Ihre Arbeitslast mit Projektbereich sehen

Führen Sie die folgenden Schritte aus, um eine Problemumgehung anzuwenden und Messwerte für Ihre Arbeitslast zu erhalten:

Prüfen Sie, ob die benutzerdefinierte Ressource MonitoringTarget den Status Ready hat.
Wenn Sie Ihre Arbeitslast scrapen möchten, müssen Sie alle Zielinformationen, die für MonitoringTarget angegeben sind, in der Pod-Spezifikation der Arbeitslast deklarieren. Wenn Sie beispielsweise deklarieren, dass Messwerte auf Port 8080 verfügbar sind, muss der Arbeitslast-Pod Kubernetes deklarieren, dass Port 8080 geöffnet ist. Andernfalls wird die Arbeitslast von Prometheus ignoriert.
Prometheus führt mehrere Shards aus. Daher ist es nicht zu erwarten, dass alle Prometheus-Pods Ihren Pod scrapen. Die Shard-Nummer finden Sie im Namen der einzelnen Prometheus-Pods. primary-prometheus-shard0-replica0-0 ist beispielsweise Teil des Shards 0. Prüfen Sie für jeden Prometheus-Shard, ob der Pod, aus dem Sie Daten extrahieren möchten, vorhanden ist:
1. Leiten Sie den Port des primary-prometheus-shardSHARD_NUMBER-replica0-0-Pods von Prometheus im obs-system-Namespace weiter, um auf die Prometheus-Benutzeroberfläche zuzugreifen. Ersetzen Sie SHARD_NUMBER im Pod-Namen durch fortlaufende Zahlen, wenn Sie einen neuen Shard prüfen.
2. Rufen Sie die Prometheus-Benutzeroberfläche in Ihrem Webbrowser auf und folgen Sie dieser Anleitung:
  1. Klicken Sie auf Status > Targets (Ziele).
  2. Prüfen Sie, ob der Pod, den Sie scrapen möchten, in der Liste enthalten ist. Falls nicht, prüfen Sie den nächsten Shard. Wenn keine Shards mehr zu prüfen sind, prüfen Sie noch einmal, ob Prometheus genügend Informationen hat, um sie zu erkennen.
3. Prüfen Sie, ob der primary-prometheus-shardSHARD_NUMBER-replica0-0-Pod von Prometheus Fehler im Namespace obs-system protokolliert.
Prüfen Sie die cortex-tenant-Pod-Logs auf Fehler im Namespace obs-system.

Es wurde kein Dashboard erstellt

Gehen Sie die folgenden Schritte durch, um eine Problemumgehung anzuwenden und herauszufinden, warum ein Dashboard nicht erstellt wird:

Prüfen Sie den Status der benutzerdefinierten Dashboard-Ressource auf Fehler. Die benutzerdefinierte Ressource muss den Status Ready haben.
Prüfen Sie, ob Sie die richtige Grafana-Instanz verwenden. Wenn Sie das Dashboard beispielsweise in Ihrem Projekt-Namespace mit dem Namen my-namespace bereitgestellt haben, muss es in der Grafana-Instanz am Endpunkt https://GDCH_URL/my-namespace/grafana vorhanden sein.
Prüfen Sie die Logs von fleet-admin-controller im Namespace gpc-system. Suchen Sie in den Logs nach Fehlern im Zusammenhang mit dem Dashboard, indem Sie den Namen des Dashboards eingeben. Wenn Sie Fehler finden, hat die JSON-Datei in Ihrem configMap-Objekt ein falsches Format und Sie müssen sie korrigieren.
Prüfen Sie die Grafana-Logs im Namespace PROJECT_NAME-obs-system auf Fehler. Dashboards fragen die Grafana REST API ab. Grafana muss also funktionieren, damit ein Dashboard erstellt werden kann.

Ihre Benachrichtigung wird nicht geöffnet

Gehen Sie so vor, um eine Problemumgehung anzuwenden und herauszufinden, warum eine Benachrichtigung nicht geöffnet wird:

Cortex und Loki müssen beide im Bucket-Speichermodus sein. Regeln funktionieren nur, wenn das Backend durch Bucket-Speicher unterstützt wird.
Prüfen Sie, ob der Status der benutzerdefinierten Ressourcen MonitoringRule und LoggingRule Ready ist.
Prüfen Sie die folgenden Benachrichtigungsbedingungen:
- PromQL- und LogQL-Ausdrücke: Vergleichen Sie alle Funktionen, die Sie verwenden, mit der Dokumentation Benachrichtigungsregeln erstellen, um sicherzustellen, dass Ihre Regeln wie gewünscht konfiguriert sind. Achten Sie darauf, dass die Ausdrücke einen true- oder false-Wert zurückgeben.
- Dauer: Das Feld for der benutzerdefinierten Ressource definiert, wie lange eine Bedingung erfüllt sein muss. Das Feld interval gibt an, wie oft die Bedingung ausgewertet werden soll. Vergleichen Sie die Werte dieser Felder miteinander und achten Sie darauf, dass Ihre Bedingungen logisch sind.
Prüfen Sie auf der Seite Alerts (Benachrichtigungen) in der Grafana-Benutzeroberfläche, ob die Benachrichtigung offen ist.
Wenn in Grafana angezeigt wird, dass die Benachrichtigung offen ist, prüfen Sie Ihre Benachrichtigungskanäle und stellen Sie sicher, dass Alertmanager sie kontaktieren kann, um die Benachrichtigung zu generieren.

Erwartete Logs sind nicht verfügbar

Wenn Sie keine Betriebslogs von Ihrer Komponente sehen, führen Sie die folgenden Schritte aus:

Prüfen Sie, ob Ihre Komponente ausgeführt wird und Logs erstellt.
Prüfen Sie, ob die Protokolle Ihrer Komponente als integrierte Funktion erfasst werden sollen. Falls nicht, müssen Sie dafür sorgen, dass die benutzerdefinierte Ressource LoggingTarget mit einer gültigen Spezifikation und dem Status Ready bereitgestellt wird.

Wenn Sie keine Audit-Logs für Ihre Komponente sehen, führen Sie die folgenden Schritte aus:

Wenn Ihre Komponente Logs in eine Datei schreibt, muss die Datei im Dateisystem des Knotens unter dem Pfad /var/log/audit/SERVICE_NAME/NAMESPACE/ACCESS_LEVEL/audit.log vorhanden sein.
Prüfen Sie, ob der anthos-audit-logs-forwarder-SUFFIX-Pod auf demselben Knoten Fehler enthält.
Wenn Ihre Komponente einen Syslog-Endpunkt zum Empfangen von Logs verwendet, muss die benutzerdefinierte Ressource AuditLoggingTarget mit einer gültigen Spezifikation und dem Status Ready bereitgestellt werden.

Vordefinierte Benachrichtigungsregeln ermitteln

Dieser Abschnitt enthält Informationen zu den vordefinierten Benachrichtigungsregeln, die in Observability-Komponenten vorhanden sind, um Sie über Systemfehler zu informieren.

Vordefinierte Benachrichtigungsregeln in Loki

Die folgende Tabelle enthält die vorinstallierten Benachrichtigungsregeln in Loki für Fehler bei der Audit-Protokollierung:

Vorinstallierte Benachrichtigungsregeln in Loki für Fehler beim Audit-Logging
Name	Typ	Beschreibung
`FluentBitAuditLoggingWriteFailure`	Kritisch	Fluent Bit konnte Audit-Logs in den letzten fünf Minuten nicht weiterleiten.
`LokiAuditLoggingWriteFailure`	Kritisch	Loki konnte keine Audit-Logs in den Backend-Speicher schreiben.

Wenn eine oder mehrere dieser Benachrichtigungen angezeigt werden, hat das System mindestens einen Prüfdatensatz verloren.

Vordefinierte Benachrichtigungsregeln in Prometheus

In der folgenden Tabelle sind die vorinstallierten Benachrichtigungsregeln in Prometheus für Kubernetes-Komponenten aufgeführt:

Vorinstallierte Benachrichtigungsregeln in Prometheus
Name	Typ	Beschreibung
`KubeAPIDown`	Kritisch	Die Kube API ist seit 15 Minuten nicht mehr in der Prometheus-Zielerkennung enthalten.
`KubeClientErrors`	Warnung	Die Fehlerrate des Kubernetes API-Serverclients ist seit 15 Minuten höher als 0,01.
`KubeClientErrors`	Kritisch	Die Fehlerrate des Kubernetes API-Serverclients ist seit 15 Minuten höher als 0,1.
`KubePodCrashLooping`	Warnung	Der Pod befindet sich seit mehr als 15 Minuten in einer Absturzschleife.
`KubePodNotReady`	Warnung	Der Pod ist seit mehr als 15 Minuten nicht bereit.
`KubePersistentVolumeFillingUp`	Kritisch	Die freien Byte eines beanspruchten `PersistentVolume`-Objekts sind kleiner als 0,03.
`KubePersistentVolumeFillingUp`	Warnung	Die freien Byte eines beanspruchten `PersistentVolume`-Objekts sind kleiner als 0,15.
`KubePersistentVolumeErrors`	Kritisch	Das nichtflüchtige Volume befindet sich seit fünf Minuten in der Phase `Failed` oder `Pending`.
`KubeNodeNotReady`	Warnung	Der Knoten ist seit mehr als 15 Minuten nicht bereit.
`KubeNodeCPUUsageHigh`	Kritisch	Die CPU-Auslastung des Knotens liegt bei über 80%.
`KubeNodeMemoryUsageHigh`	Kritisch	Die Speichernutzung des Knotens liegt über 80%.
`NodeFilesystemSpaceFillingUp`	Warnung	Die Nutzung des Dateisystems des Knotens liegt über 60%.
`NodeFilesystemSpaceFillingUp`	Kritisch	Die Nutzung des Dateisystems des Knotens liegt über 85%.
`CertManagerCertExpirySoon`	Warnung	Ein Zertifikat läuft in 21 Tagen ab.
`CertManagerCertNotReady`	Kritisch	Ein Zertifikat kann noch nicht für die Bereitstellung von Traffic nach 10 Minuten verwendet werden.
`CertManagerHittingRateLimits`	Kritisch	Sie haben eine Ratenbegrenzung erreicht, nachdem fünf Minuten lang Zertifikate erstellt oder verlängert wurden.
`DeploymentNotReady`	Kritisch	Ein Deployment im Infrastrukturcluster der Organisation ist seit mehr als 15 Minuten nicht bereit.
`StatefulSetNotReady`	Kritisch	Ein `StatefulSet`-Objekt im Infrastrukturcluster der Organisation ist seit mehr als 15 Minuten nicht bereit.
`AuditLogsForwarderDown`	Kritisch	Das `anthos-audit-logs-forwarder`-DaemonSet ist seit mehr als 15 Minuten nicht verfügbar.
`AuditLogsLokiDown`	Kritisch	Das StatefulSet `audit-logs-loki` ist seit mehr als 15 Minuten nicht bereit.