Sie lesen die Dokumentation für Anthos Service Mesh 1.6. Lesen Sie die aktuelle Dokumentation oder wählen Sie eine andere verfügbare Version aus:

Anthos Service Mesh-Logs interpretieren

In den folgenden Abschnitten wird beschrieben, wie Sie den Status Ihres Mesh-Netzwerks prüfen und die verschiedenen Logs mit hilfreichen Details zur Fehlerbehebung nutzen können.

Messwerte der Steuerungsebene interpretieren

Wenn Sie Anthos Service Mesh mithilfe des Profils asm-gcp installieren, exportiert Istio standardmäßig Messwerte zur Überwachung in die Operations-Suite von Google Cloud. Istio stellt diesen Messwerte mit das Präfix istio.io/control voran und bietet Einblicke in den Status der Steuerungsebene, z. B. die Anzahl der Proxys, die mit jeder Instanz der Steuerungsebene verbunden sind, Konfigurationsereignisse sowie Push- und Validierungen.

Mit den folgenden Schritten können Sie die Steuerungsebene beobachten oder Fehler beheben.

  1. Beispiel-Dashboard laden:

    git clone https://github.com/GoogleCloudPlatform/monitoring-dashboard-samples && cd monitoring-dashboard-samples && git checkout asm
  2. Installieren Sie das Anthos Service Mesh-Dashboard:

    gcloud monitoring dashboards create --config-from-file=dashboards/servicemesh/anthos-service-mesh-control-plane-monitoring.json
  3. Suchen Sie in der Liste nach einem Dashboard mit dem Namen Istio Control Plane Dashboard. Weitere Informationen finden Sie unter Installiertes Dashboard ansehen.

    Wenn Sie das Profil asm-gcp nicht verwenden, können Sie trotzdem Messwerte der Steuerungsebene aktivieren, indem Sie die Umgebungsvariablen in das Istio-Deployment einfügen:

    - name: ENABLE_STACKDRIVER_MONITORING
    value: "true"

    Darüber hinaus können Sie diese Umgebungsvariable mit der Installationsoption components.pilot.k8s.env hinzufügen.

Eine vollständige Liste der verfügbaren Messwerte finden Sie unter Exportierte Messwerte.

Konfigurationsverzögerungen diagnostizieren

In den folgenden Schritten wird erläutert, wie Sie mit dem Messwert pilot_proxy_convergence_time eine Verzögerung zwischen einer Konfigurationsänderung und allen konvergenten Proxys feststellen können.

  1. Führen Sie einen Shell-Befehl in einem Pod aus:

    kubectl exec -it $(kubectl get pod -l app=pilot -o jsonpath='{.items[0].metadata.name}' -n istio-system) -n istio-system -c istio-proxy -- curl -s
  2. Greifen Sie auf localhost:15014 und grep für convergence in Messwerten zu:

    curl http://localhost:15014/metrics | grep convergence

Zugriffslogs der Operations-Suite von Google Cloud interpretieren

Im Folgenden wird erläutert, wie Sie Verbindungsprotokolle der Operations Suite von Google Cloud verwenden, um Verbindungsprobleme zu beheben.

Anthos Service Mesh exportiert Daten in die Zugriffslogs der Operations-Suite von Google Cloud, die Ihnen bei der Behebung der folgenden Problemarten helfen können:

  • Datenverkehr und Fehler
  • End-to-End-Anfragerouting

Zugriffs-/Trafficlogs der Operations-Suite von Google Cloud sind im Profil asm-gcp standardmäßig für das gesamte Mesh-Netzwerk aktiviert. Wenn diese jedoch noch nicht aktiviert sind, können Sie den folgenden Befehl verwenden:

istioctl install --set profile=PROFILE_NAME --set revision==ASM_VERSION \
    --set values.telemetry.v2.stackdriver.enabled=true \
    --set values.telemetry.v2.stackdriver.logging=true

Es gibt zwei Arten von Zugriffslogs:

  • Serverzugriffsprotokolle bieten eine serverseitige Ansicht von Anfragen. Diese befinden sich unter server-accesslog-stackdriver und sind an die überwachte Ressource k8s_container angehängt. Verwenden Sie die folgende URL-Syntax, um serverseitige Zugriffslogs anzuzeigen:

    https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"&project=PROJECT_ID
  • Clientzugriffslogs bieten eine clientseitige Ansicht von Anfragen. Sie befinden sich unter client-accesslog-stackdriver und sind an die überwachte Ressource k8s_pod angehängt. Verwenden Sie die folgende URL-Syntax, um clientseitige Zugriffslogs anzuzeigen:

    https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/client-accesslog-stackdriver"&project=PROJECT_ID
    .

Standardmäßig sind nur Clientfehlerlogs aktiviert, um Logging-Kosten zu reduzieren. Sie können jedoch alle Clientlogs (Erfolg und Fehler) mit dem folgenden Befehl aktivieren:

istioctl install --set profile=PROFILE_NAME --set revision==ASM_VERSION 
--set values.telemetry.v2.stackdriver.enabled=true
--set values.telemetry.v2.stackdriver.outboundAccessLogging=FULL

Zugriffslogs enthalten folgende Informationen:

  • HTTP-Anfrageattribute, z. B. ID, URL, Größe, Latenz und allgemeine Header.
  • Informationen zu Quell- und Zielarbeitslast, z. B. Name, Namespace, Identität und allgemeine Labels.
  • Informationen zu kanonischen Quell- und Zieldiensten sowie Revisionsinformationen.
  • Wenn Tracing aktiviert ist, enthalten die Logs Trace-Informationen wie Abtastrate, Trace-ID und Span-ID.

Die in den Zugriffslogs der Google Cloud Operations Suite angezeigten Informationen stammen aus Envoy-Zugriffslogs, wenn Sie diese in der Istio-Konfiguration aktivieren. Sie enthalten die folgenden Header:

  • route_name
  • upstream_cluster
  • X-Envoy-Original-Path
  • X-Envoy-Original-Host

Das ist ein Beispiel-Logeintrag:

{
  "insertId": "1j84zg8g68vb62z",
  "httpRequest": {
    "requestMethod": "GET",
    "requestUrl": "http://35.235.89.201:80/productpage",
    "requestSize": "795",
    "status": 200,
    "responseSize": "7005",
    "remoteIp": "10.168.0.26:0",
    "serverIp": "10.36.3.153:9080",
    "latency": "0.229384205s",
    "protocol": "http"
  },
  "resource": {
    "type": "k8s_container",
    "labels": {
      "cluster_name": "istio-e2e22",
      "namespace_name": "istio-bookinfo-1-68819",
      "container_name": "productpage",
      "project_id": "***",
      "location": "us-west2-a",
      "pod_name": "productpage-v1-64794f5db4-8xbtf"
    }
  },
  "timestamp": "2020-08-13T21:37:42.963881Z",
  "severity": "INFO",
  "labels": {
    "protocol": "http",
    "upstream_host": "127.0.0.1:9080",
    "source_canonical_service": "istio-ingressgateway",
    "source_namespace": "istio-system",
    "x-envoy-original-path": "",
    "source_canonical_revision": "latest",
    "connection_id": "32",
    "upstream_cluster": "inbound|9080|http|productpage.istio-bookinfo-1-68819.svc.cluster.local",
    "requested_server_name": "outbound_.9080_._.productpage.istio-bookinfo-1-68819.svc.cluster.local",
    "destination_version": "v1",
    "destination_workload": "productpage-v1",
    "source_workload": "istio-ingressgateway",
    "destination_canonical_revision": "v1",
    "mesh_uid": "cluster.local",
    "source_principal": "spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account",
    "x-envoy-original-dst-host": "",
    "service_authentication_policy": "MUTUAL_TLS",
    "destination_principal": "spiffe://cluster.local/ns/istio-bookinfo-1-68819/sa/bookinfo-productpage",
    "response_flag": "-",
    "log_sampled": "false",
    "destination_service_host": "productpage.istio-bookinfo-1-68819.svc.cluster.local",
    "destination_name": "productpage-v1-64794f5db4-8xbtf",
    "destination_canonical_service": "productpage",
    "destination_namespace": "istio-bookinfo-1-68819",
    "source_name": "istio-ingressgateway-6845f6d664-lnfvp",
    "source_app": "istio-ingressgateway",
    "destination_app": "productpage",
    "request_id": "39013650-4e62-9be2-9d25-78682dd27ea4",
    "route_name": "default"
  },
  "logName": "projects/***/logs/server-accesslog-stackdriver",
  "trace": "projects/***t/traces/466d77d15753cb4d7749ba5413b5f70f",
  "receiveTimestamp": "2020-08-13T21:37:48.758673203Z",
  "spanId": "633831cb1fda4fd5",
  "traceSampled": true
}

Sie können dieses Log auf verschiedene Arten verwenden:

  • Einbindung in Cloud Trace, eine optionale Funktion in Anthos Service Mesh
  • Export von Trafficlogs nach BigQuery, um Abfragen auszuführen, wie die Auswahl aller Anfragen, die länger als 5 Sekunden dauern
  • Logbasierte Messwerte erstellen
  • 404- und 503-Fehler beheben

404- und 503-Fehler beheben

Im folgenden Beispiel wird erläutert, wie Sie dieses Log zur Fehlerbehebung verwenden, wenn eine Anfrage mit dem Antwortcode 404 oder 503 fehlschlägt.

  1. Suchen Sie im Client-Zugriffslog nach einem Eintrag wie dem folgenden:

    httpRequest: {
    requestMethod: "GET"
    requestUrl: "://IP_ADDRESS/src/Util/PHP/eval-stdin.php"
    requestSize: "2088"
    status: 404
    responseSize: "75"
    remoteIp: "10.168.0.26:34165"
    serverIp: "10.36.3.149:8080"
    latency: "0.000371440s"
    protocol: "http"
    }
  2. Gehen Sie zu den Labels im Zugriffslogeintrag. Suchen Sie das Feld response_flag, das in etwa so aussieht:

    response_flag: "NR"

    Der Wert NR ist ein Akronym für NoRoute. Das bedeutet, dass keine Route für das Ziel gefunden wurde oder es keine übereinstimmende Filterkette für eine nachgelagerte Verbindung gibt. Mit dem Label response_flag können Sie auch 503-Fehler beheben.

  3. Wenn Sie sowohl in den Client- als auch den Serverzugriffslogs 503-Fehler sehen, prüfen Sie, ob die Portnamen für die einzelnen Dienste mit dem Namen des verwendeten Protokolls übereinstimmen. Beispiel: Wenn ein Golang-Binärclient über HTTP mit einem Golang-Server verbunden ist, der Port aber http2 lautet, wird das Protokoll nicht automatisch neu ausgehandelt.

Weitere Informationen finden Sie unter Antwort-Flags.

Envoy-Logs interpretieren

In den folgenden Schritten wird erläutert, wie Sie die Proxy-Zugriffsprotokolle von Envoy nutzen, um den Traffic zwischen beiden Enden einer Verbindung zwecks Fehlerbehebung anzuzeigen.

Envoy-Zugriffslogs sind nützlich für die Diagnose von Problemen wie:

  • Datenverkehr und Fehler
  • End-to-End-Anfragerouting

Zugriffslogs sind in Anthos Service Mesh nicht standardmäßig aktiviert und können nur global im gesamten Mesh-Netzwerk aktiviert werden.

Sie können Verbindungs-/Anfragefehler dadurch beheben, dass Sie Aktivitäten in Ihrer Anwendung generieren, die eine HTTP-Anfrage auslösen, und die zugehörige Anfrage dann in den Quell- oder Ziellogs untersuchen.

Wenn Sie eine Anfrage auslösen und diese in den Quellproxy-Logs ausgewiesen wird, bedeutet dies, dass die iptables-Traffic-Weiterleitung ordnungsgemäß funktioniert und der Envoy-Proxy den Traffic verarbeitet. Wenn in den Logs Fehler auftreten, generieren Sie einen Envoy-Konfigurationsauszug und prüfen Sie, ob die Konfiguration des Envoy-Clusters korrekt ist. Wenn Sie die Anfrage sehen, das Log jedoch keine Fehler enthält, prüfen Sie stattdessen die Zielproxy-Logs.

Wenn die Anfrage in den Zielproxy-Logs auftritt, gibt das an, dass das Mesh-Netzwerk ordnungsgemäß funktioniert. Wenn stattdessen ein Fehler angezeigt wird, führen Sie einen Envoy-Konfigurationsdump aus und verifizieren Sie die korrekten Werte für den in der Listener-Konfiguration festgelegten Traffic-Port.

Wenn das Problem nach den vorherigen Schritten weiterhin besteht, kann Envoy das Protokoll zwischen dem Sidecar und dem Anwendungs-Pod möglicherweise nicht automatisch verhandeln. Achten Sie darauf, dass der Portname des Kubernetes-Dienstes, z. B. http-80, mit dem Protokoll übereinstimmt, das von der Anwendung verwendet wird.

Logs mit der Loganzeige abfragen

Sie können über die Benutzeroberfläche der Loganzeige bestimmte Zugriffslogs abfragen. Wenn Sie beispielsweise alle Anfragen abfragen möchten, bei denen MULTUAL_TLS aktiviert ist und das Protokoll grpc verwendet wird, fügen Sie Folgendes an die zuvor erwähnte Abfrage der Serverzugriffslogs an:

labels.protocol="grpc" labels.service_authentication_policy="MULTUAL_TLS"

Richtlinie für Zugriffslogs festlegen

Sie können eine Proxy-Logging-Richtlinie festlegen, die bestimmt, welche Informationen Sie erfassen. Dies ist nützlich, um den Umfang Ihrer Logs zu steuern und Probleme zu beheben. Logging erfasst beispielsweise automatisch Fehler. Sie können jedoch logWindowDuration auch so definieren, dass erfolgreiche Ereignisse für einen bestimmten Zeitraum erfasst werden oder die Fensterdauer auf null setzen, um alle Zugriffe zu protokollieren. Die Richtlinie wird auf Mesh-Netzwerk- oder Clusterebene festgelegt.

Aktivieren Sie mit dem folgenden Befehl eine Zugrifflogrichtlinie:

istioctl install --set profile=PROFILE_NAME \
    --set values.telemetry.v2.stackdriver.enabled=true \
    --set values.telemetry.v2.stackdriver.logging=true \
    --set values.telemetry.accessLogPolicy.enabled=true

Weitere Informationen zu den Konfigurationsoptionen für Zugriffslogs, z. B. logWindowDuration, finden Sie unter AccessLogPolicy-Konfiguration.

Dienst- oder arbeitslastspezifische Informationen aufrufen

Wenn Sie ein Problem mit einem bestimmten Dienst oder einer Arbeitslast haben, nicht eins, das sich auf das gesamte Mesh-Netzwerk auswirkt, prüfen Sie die einzelnen Envoy-Proxys und erfassen Sie von diesen relevante Informationen. Mit pilot-agent können Sie Informationen zu einer bestimmten Arbeitslast und ihren Proxys erfassen:

kubectl exec POD_NAME -c istio-proxy -- pilot-agent request GET SCOPE

Im Beispiel ist SCOPE eine der folgenden Optionen:

  • certs – Zertifikate in der Envoy-Instanz
  • clusters – Cluster mit konfiguriertem Envoy
  • config_dump – Löscht die Envoy-Konfiguration
  • listeners – Listener mit konfiguriertem Envoy
  • logging – Logging-Einstellungen aufrufen und ändern
  • stats – Envoy-Statistiken
  • stats/prometheus – Envoy-Statistiken als Prometheus-Datensätze

Proxy-Socket-Status aufrufen

Sie können den Status von Envoy-Proxy-Sockets mithilfe des folgenden Prozesses direkt prüfen.

  1. Rufen Sie eine Liste der vorhandenen Sockets auf, einschließlich der Sockets mit dem Status TIME_WAIT, die sich negativ auf die Skalierbarkeit auswirken können, wenn deren Anzahl hoch ist:

    kubectl exec POD_NAME -c istio-proxy -- ss -anopim
  2. Zusammenfassung der Socket-Statistiken anzeigen:

    kubectl exec POD_NAME -c istio-proxy -- ss -s

Weitere Informationen finden Sie unter Einführung in den ss-Befehl.

istio-proxy- und istio-init-Logs

Rufen Sie außerdem die istio-proxy-Logs ab und prüfen Sie deren Inhalt auf Fehler, die möglicherweise die Ursache des Problems sein:

kubectl logs POD_NAME -c istio-proxy

Sie können dies auch für den Container init tun:

kubectl logs POD_NAME -c istio-init