Beobachtbarkeits- und Telemetrieprobleme in Cloud Service Mesh beheben

In diesem Abschnitt werden häufige Cloud Service Mesh-Probleme und deren Behebung erläutert . Weitere Informationen finden Sie unter Support.

In der Cloud Service Mesh-Telemetrie rufen die Envoy-Proxys die Methode Google Cloud Observability APIs zur regelmäßigen Meldung von Telemetriedaten. Der Typ des Die Häufigkeit des API-Aufrufs wird festgelegt:

  • Logging: etwa alle 10 Sekunden
  • Messwerte: etwa 1-mal pro Minute
  • Edges (Context API/Topologie-Ansicht): inkrementelle Berichte etwa alle 1 Minute mit vollständigen Berichten etwa alle 10 Minuten.
  • Traces: bestimmt durch die von Ihnen konfigurierte Stichprobenhäufigkeit (in der Regel eine von 100 Anfragen).

Die Telemetrie-Dashboards erfassen Daten aus Confluence und Google Cloud Observability, um die verschiedenen dienstorientierten Dashboards anzuzeigen.

Prüfen, ob es höchstens eine Istio Telemetrie API-Konfiguration gibt

Dieser Abschnitt gilt nur für die verwaltete Cloud Service Mesh-Steuerungsebene.

Führen Sie den folgenden Befehl aus, um die Telemetrie-API-Konfigurationen aufzulisten. Prüfen Sie, ob Es gibt maximal eine Istio-Telemetrie-API-Konfiguration.

kubectl -n istio-system get telemetry

Im Dienste-Dashboard fehlt ein Dienst

Im Dashboard werden nur HTTP(S)- bzw. gRPC-Dienste angezeigt. Wenn Ihre Dienstleistung in und prüfen Sie, ob die Cloud Service Mesh-Telemetrie sie als HTTP- .

Falls Ihr Dienst weiterhin fehlt, prüfen Sie, ob ein Kubernetes-Dienstkonfiguration in Ihrem Cluster 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 und einer dieser Container ist der istio-Proxy. Container:

kubectl -n YOUR_NAMESPACE get pods

Prüfen, ob die Telemetriekonfiguration vorhanden ist

So prüfen Sie, ob der Google Cloud-Filter für die Beobachtbarkeit konfiguriert ist: Erstellen Sie einen Konfigurations-Dump von jedem Proxy und suchen Sie nach dem Google Cloud-Beobachtbarkeitsfilter:

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-Filter für Beobachtbarkeit. Das sieht so aus:

"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 nicht in der Benutzeroberfläche angezeigt, wenn der Dienstport für die Der Kubernetes-Dienst hat weder den Namen http noch einen Namen mit dem Präfix http-. Prüfen Sie, ob der Dienst die richtigen Namen für die Ports hat.

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" der Google Cloud 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 Menü IAM & Admin und prüfen Sie, ob ein Kontingente Option. Ü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

Offen 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]

Stellen Sie sicher, dass alle erwarteten Dienste Messwerte melden und dass ihre metric.mesh_uid hat das Format proj-<Cloud Service Mesh fleet project number>.

Wenn metric.mesh_uid einen anderen Wert hat, wird das Cloud Service Mesh-Dashboard angezeigt werden keine Messwerte angezeigt. metric.mesh_uid ist festgelegt, wenn Cloud Service Mesh: die im Cluster installiert sind. Untersuchen Sie daher Ihre Installationsmethode, gibt es eine Möglichkeit, ihn auf den erwarteten Wert zu setzen.

Fehlende oder falsche Telemetriedaten für Dienste

Standardmäßig sind Cloud Monitoring und Cloud Logging in Ihrer Google Cloud-Projekt, 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 behält die Dienst-Dashboards automatisch bei auf dem neuesten Stand:

  • Die Sidecar-Proxys rufen ungefähr jede Minute Messwerte von der Cloud Monitoring API ab.
  • Zur Aktualisierung des Topologiediagramms senden die Sidecar-Proxys etwa jede Minute inkrementelle Berichte und etwa alle 10 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 im Cloud Service Mesh angezeigt Messwerte. Wenn Sie keine Messwerte sehen, prüfen Sie, ob alle Pods in der Namespace für die Dienste Ihrer Anwendung haben Sidecar-Proxys eingefügt:

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.

Außerdem werden im Dienst-Dashboard nur Servermesswerte angezeigt, Daten werden möglicherweise nicht angezeigt, wenn sich der Client nicht im Mesh-Netzwerk befindet oder so konfiguriert ist, dass Nur Clientmesswerte (z. B. Ingress-Gateways) werden gemeldet.