Beobachtbarkeits- und Telemetrieprobleme in Cloud Service Mesh beheben
In diesem Abschnitt werden häufig auftretende Probleme bei Cloud Service Mesh und deren Behebung beschrieben. Weitere Informationen finden Sie unter Support.
In der Cloud Service Mesh-Telemetrie rufen die Envoy-Proxys regelmäßig die Google Cloud Observability APIs auf, um Telemetriedaten zu melden. Die Häufigkeit des API-Aufrufs hängt vom Typ ab:
- Logging: etwa alle 10 Sekunden
- Messwerte: etwa 1-mal pro Minute
- Edges (Context API/Topologieansicht): inkrementelle Berichte etwa alle 1 Minute, vollständige Berichte etwa alle 10 Minuten.
- Traces: wird durch die von Ihnen konfigurierte Stichprobenhäufigkeit bestimmt (in der Regel eine Stichprobe alle 100 Anfragen)
Die Telemetrie-Dashboards erfassen Daten aus Confluence und Google Cloud Observability, um die verschiedenen dienstbezogenen Dashboards anzuzeigen.
Prüfen, ob höchstens eine Istio-Telemetrie-API-Konfiguration vorhanden ist
Dieser Abschnitt gilt nur für die verwaltete Traffic Director-Steuerungsebene.
Wenn Sie bereits eine Istio-Telemetrie-API-CR haben, müssen Sie alle vorherigen Anpassungseinstellungen in Ihre neue Istio-Telemetrie-API-CR einbeziehen, um sie in Ihrer vorhandenen Istio-Telemetrie-CR beizubehalten.
Führen Sie den folgenden Befehl aus, um die Telemetrie-API-Konfigurationen aufzulisten. Prüfen Sie, ob höchstens eine Istio-Telemetrie-API-Konfiguration vorhanden ist.
kubectl -n istio-system get telemetry
Im Dienste-Dashboard fehlt ein Dienst
Im Dashboard werden nur HTTP(S)- bzw. gRPC-Dienste angezeigt. Wenn Ihr Dienst in der Liste enthalten sein sollte, prüfen Sie, ob er von der Cloud Service Mesh-Telemetrie als HTTP-Dienst identifiziert wird.
Wenn Ihr Dienst weiterhin fehlt, prüfen Sie, ob in Ihrem Cluster eine Kubernetes-Dienstkonfiguration vorhanden ist.
Sehen Sie sich die Liste aller Kubernetes-Services an:
kubectl get services --all-namespaces
Sehen Sie sich die Liste der Kubernetes-Services in einem bestimmten Namespace an:
kubectl get services -n YOUR_NAMESPACE
Fehlende oder falsche Messwerte für Dienste
Wenn im Service-Dashboard Messwerte für Dienste fehlen oder falsch sind, suchen Sie in den folgenden Abschnitten nach möglichen Lösungen.
Prüfen, ob Sidecar-Proxys vorhanden sind und ordnungsgemäß eingefügt wurden
Der Namespace hat möglicherweise kein Label für die automatische Einfügung oder die manuelle Einfügung ist fehlgeschlagen. Prüfen Sie, ob die Pods im Namespace mindestens zwei Container haben und einer davon der istio-proxy-Container ist:
kubectl -n YOUR_NAMESPACE get pods
Prüfen, ob die Telemetriekonfiguration vorhanden ist
Um zu prüfen, ob der Google Cloud Observability-Filter konfiguriert ist, erstellen Sie einen Konfigurationsdump von jedem Proxy und suchen Sie nach dem Google Cloud Observability-Filter:
kubectl debug --image istio/base --target istio-proxy -it YOUR_POD_NAME -n YOUR_NAMESPACE curl localhost:15000/config_dump
Suchen Sie in der Ausgabe des vorherigen Befehls nach dem Google Cloud Observability-Filter, der so aussieht:
"config": {
"root_id": "stackdriver_inbound",
"vm_config": {
"vm_id": "stackdriver_inbound",
"runtime": "envoy.wasm.runtime.null",
"code": {
"local": {
"inline_string": "envoy.wasm.null.stackdriver"
}
}
},
"configuration": "{....}"
}Prüfen, ob Cloud Service Mesh einen HTTP-Dienst identifiziert
Messwerte werden in der Benutzeroberfläche nicht angezeigt, wenn der Dienstport für den
Kubernetes-Dienst nicht http oder ein anderer Name mit dem Präfix http- ist.
Prüfen Sie, ob die Ports des Dienstes die richtigen Namen haben.
Prüfen, ob die Cloud Monitoring API für das Projekt aktiviert ist
Prüfen Sie, ob die Cloud Monitoring API im Dashboard „APIs & Dienste“ in Google Cloud der Console aktiviert ist (Standardeinstellung).
Prüfen, ob Fehler bezüglich der Cloud Monitoring API gemeldet werden
Öffnen Sie im Dashboard „APIs &Dienste“ der Google Cloud Console die Grafik-URL „ Traffic nach Antwortcode“:
https://console.cloud.google.com/apis/api/monitoring.googleapis.com/metrics?folder=&organizationId=&project=YOUR_PROJECT_ID
Wenn Fehlermeldungen angezeigt werden, sollte das entsprechende Problem möglicherweise genauer untersucht werden. Suchen Sie insbesondere nach einer großen Anzahl von 429-Fehlermeldungen, die auf ein potenzielles Kontingentproblem hinweisen. Schritte zur Fehlerbehebung finden Sie im nächsten Abschnitt.
Prüfen, ob das Kontingent für die Cloud Monitoring API korrekt ist
Öffnen Sie in der Google Cloud Console das IAM & Admin Menü und prüfen Sie, ob die
Option „Kontingente“
vorhanden ist. Über die folgende URL können Sie direkt auf diese Seite zugreifen:
https://console.cloud.google.com/iam-admin/quotas?project=YOUR_PROJECT_ID
Auf dieser Seite finden Sie alle Kontingente für das Projekt. Sie können dort nach Cloud Monitoring API suchen.
Prüfen, ob Fehler bezüglich der Envoy-Proxys gemeldet werden
Prüfen Sie die Logs für den betreffenden Proxy auf Fehlermeldungen:
kubectl -n YOUR_NAMESPACE logs YOUR_POD_NAME -c istio-proxy
Warnmeldungen wie die folgenden können Sie aber ignorieren:
[warning][filter] [src/envoy/http/authn/http_filter_factory.cc:83] mTLS PERMISSIVE mode is used, connection can be either plaintext or TLS, and client cert can be omitted. Please consider to upgrade to mTLS STRICT mode for more secure configuration that only allows TLS connection with client cert. See https://istio.io/docs/tasks/security/mtls-migration/ [warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13
Prüfen, ob metric.mesh_uid richtig festgelegt ist
Öffnen Sie den Metrics Explorer und führen Sie die folgende MQL-Abfrage aus:
fetch istio_canonical_service
| metric 'istio.io/service/server/request_count'
| align delta(1m)
| every 1m
| group_by [metric.destination_canonical_service_namespace, metric.destination_canonical_service_name, metric.mesh_uid]
Prüfen Sie, ob alle erwarteten Dienste Messwerte melden und ob ihre
metric.mesh_uid das Format proj-<Cloud Service Mesh fleet project number> hat.
Wenn metric.mesh_uid einen anderen Wert hat, werden im Cloud Service Mesh-Dashboard keine Messwerte angezeigt. metric.mesh_uid wird festgelegt, wenn Cloud Service Mesh im Cluster installiert wird. Prüfen Sie daher Ihre Installationsmethode, um herauszufinden, ob Sie den Wert auf den erwarteten Wert festlegen können.
Fehlende oder falsche Telemetriedaten für Dienste
Standardmäßig werden Cloud Monitoring und Cloud Logging in Ihrem Google Cloud Projekt aktiviert, wenn Sie Cloud Service Mesh installieren. Zur Erhebung von Telemetriedaten ruft jeder in Ihre Dienst-Pods eingefügte Sidecar-Proxy die Cloud Monitoring API und die Cloud Logging API auf. Nach der Bereitstellung der Arbeitslasten dauert es etwa ein bis zwei Minuten, bis die Telemetriedaten in der Google Cloud Console angezeigt werden. Cloud Service Mesh hält die Dienst-Dashboards automatisch auf dem neuesten Stand:
- Die Sidecar-Proxys rufen ungefähr jede Minute Messwerte von der Cloud Monitoring API ab.
- Um die Topologiegrafik zu aktualisieren, senden die Sidecar-Proxys etwa jede Minute inkrementelle Berichte und etwa alle zehn Minuten vollständige Berichte.
- Für das Logging rufen die Sidecar-Proxys etwa alle 10 Sekunden die Cloud Logging API auf.
- Für das Tracing müssen Sie Cloud Trace aktivieren. Traces werden gemäß der von Ihnen konfigurierten Stichprobenhäufigkeit (normalerweise eine Stichprobe alle 100 Anfragen) gemeldet.
Messwerte werden nur für HTTP-Dienste auf der Seite „Cloud Service Mesh-Messwerte“ angezeigt. Wenn keine Messwerte angezeigt werden, prüfen Sie, ob in alle Pods im Namespace für die Dienste Ihrer Anwendung Sidecar-Proxys eingefügt wurden:
kubectl get pod -n YOUR_NAMESPACE --all
Beachten Sie in der Ausgabe, dass die Spalte READY zwei Container für jede Ihrer Arbeitslasten enthält: den primären Container und den Container für den Sidecar-Proxy.
Darüber hinaus werden im Service-Dashboard nur Servermesswerte angezeigt. Telemetriedaten werden daher möglicherweise nicht angezeigt, wenn sich der Client nicht im Mesh-Netzwerk befindet oder so konfiguriert ist, dass nur Clientmesswerte gemeldet werden (z. B. Ingress-Gateways).