Proxy-Logs anfordern

Cloud Service Mesh unterstützt zwei verschiedene Arten von Zugriffslogs in Cloud Logging: Traffic-Logs (auch bekannt als Google Cloud Observability-Zugriffslogs) und Envoy-Zugriffslogs. Auf dieser Seite erfahren Sie, wie Sie diese Logs aktivieren, deaktivieren, aufrufen und interpretieren. Beachten Sie, dass Traffic-Logs standardmäßig aktiviert sind.

Zugriffslogs aktivieren und deaktivieren

Verwalteter Traffic Director

Wenn Sie bereits eine Istio Telemetry API-CR haben, müssen Sie die vorherigen Anpassungseinstellungen in die neue Istio Telemetry API-CR aufnehmen, um sie beizubehalten.

Envoy-Zugriffslogs

Führen Sie den folgenden Befehl aus, um Envoy-Zugriffslogs zu aktivieren und Traffic-Logs zu deaktivieren:

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: enable-envoy-disable-sd
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
  - providers:
      - name: stackdriver
    disabled: true
EOF

Der Anbietername für das Traffic-Log ist stackdriver.

Trafficlogs

Standardmäßig sind Traffic-Logs aktiviert und Envoy-Zugriffslogs deaktiviert. Wenn Sie zuvor Envoy-Zugriffslogs aktiviert haben und Traffic-Logs aktivieren und Envoy-Zugriffslogs deaktivieren möchten, führen Sie den folgenden Befehl aus:

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: disable-envoy-enable-sd
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
    disabled: true
  - providers:
      - name: stackdriver
EOF

Beides

  • Führen Sie den folgenden Befehl aus, um sowohl Envoy-Zugriffsprotokolle als auch Traffic-Logs zu aktivieren:

    cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: enable-envoy-and-sd-access-log
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
      - name: stackdriver
EOF

  • Führen Sie den folgenden Befehl aus, um sowohl Envoy-Zugriffsprotokolle als auch Traffic-Logs zu deaktivieren:

    cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: disable-envoy-and-sd
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
    disabled: true
  - providers:
      - name: stackdriver
    disabled: true
EOF

Selektorspezifische Zugriffslogs

Wenn Sie im Rapid und Regular Channel das Zugriffs-Logging nur für eine bestimmte Arbeitslast aktivieren möchten, müssen Sie es zuerst auf Mesh-weiter Ebene deaktivieren. Dazu wenden Sie eine Telemetriekonfiguration im Root-Namespace an, da das Traffic-Logging standardmäßig aktiviert ist. Anschließend wenden Sie eine separate Konfiguration mit einer Auswahl an, um sie nur für diese Arbeitslast zu aktivieren.

# 1. Disable mesh-wide access logging
cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: disable-mesh-wide-telemetry
  namespace: istio-system
spec:
  accessLogging:
  - providers:
    - name: stackdriver
    disabled: true
EOF

# 2. Enable access logging for a specific workload
cat <<EOF | kubectl apply -n NAMESPACE -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: workload-specific-telemetry
  namespace: NAMESPACE
spec:
  selector:
    matchLabels:
      app: YOUR_APP_LABEL
  accessLogging:
  - providers:
    - name: stackdriver
EOF

Verwaltete istiod

Envoy-Zugriffslogs

Führen Sie die folgenden Befehle aus, um das Envoy-Zugriffs-Logging zu aktivieren:

  1. Führen Sie den folgenden Befehl aus, um accessLogFile: /dev/stdout hinzuzufügen:

    cat <<EOF | kubectl apply -f -
apiVersion: v1
data:
  mesh: |-
    accessLogFile: /dev/stdout
kind: ConfigMap
metadata:
  name: istio-release-channel
  namespace: istio-system
EOF

    Dabei ist release-channel Ihre Release-Version (asm-managed, asm-managed-stable oder asm-managed-rapid).

  2. Führen Sie den folgenden Befehl aus, um die ConfigMap aufzurufen:

     kubectl get configmap istio-release-channel -n istio-system -o yaml

  3. Wenn Sie prüfen möchten, ob das Zugriffs-Logging aktiviert ist, muss die Zeile accessLogFile: /dev/stdout im Abschnitt mesh: enthalten sein.

    ...
apiVersion: v1
data:
  mesh: |
    ....
    accessLogFile: /dev/stdout
...

Trafficlogs

Trafficlogs sind standardmäßig aktiviert.

Clusterintern

Envoy-Zugriffslogs

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: "/dev/stdout"

Weitere Informationen finden Sie unter Zugriffs-Logging von Envoy aktivieren.

Trafficlogs

Trafficlogs sind standardmäßig aktiviert, es sei denn, Cloud Service Mesh ist in Google Distributed Cloud mit Istio CA (ehemals Citadel) installiert.

Wenn Sie Traffic-Logs in Google Distributed Cloud mit Istio CA bei der Installation von clusterinternem Cloud Service Mesh aktivieren möchten, verwenden Sie das Flag --option stackdriver. Alternativ können Sie Traffic-Logs in Google Distributed Cloud mit Istio-Zertifizierungsstelle nach der Installation von clusterinternem Cloud Service Mesh aktivieren.

Envoy-Zugriffslogformat und ‑Codierung anpassen

Sie können den Inhalt und die Struktur von Envoy-Zugriffsprotokollen anpassen, die in die Standardausgabe (/dev/stdout) ausgegeben werden. So können Sie bestimmte Felder für Auditing oder Compliance (z. B. TLS-Chiffrierverfahren) einfügen und zwischen Nur-Text- oder strukturierter JSON-Ausgabe wählen.

Beschränkungen

Die Konfiguration des Formats für das Zugriffs-Logging ist nur in der schnellen Release-Version verfügbar.

Konfigurationsfelder

Konfigurieren Sie die folgenden Felder in MeshConfig:

  • accessLogEncoding: Gibt die Struktur der Logs an, entweder TEXT oder JSON. Die Standardeinstellung ist TEXT.
  • accessLogFormat: Der Envoy-Zugriffsprotokoll-Formatstring oder die JSON-Definition (optional, wenn TEXT ausgewählt ist).

Wenden Sie die Konfiguration an

Wie Sie diese Einstellungen anwenden, hängt von Ihrer Steuerungsebene ab:

Verwalteter Traffic Director

Aktualisieren Sie die ConfigMap istio-asm-managed-rapid im Namespace istio-system (auch wenn Sie einen anderen Channel als „Rapid“ verwenden). Fügen Sie accessLogEncoding und accessLogFormat unter dem Feld mesh hinzu.

cat <<EOF | kubectl apply -f -
apiVersion: v1
data:
  mesh: |-
    accessLogFile: /dev/stdout
    accessLogEncoding: JSON
    accessLogFormat: '{"time": "%START_TIME%","code": "%RESPONSE_CODE%","upstream_cluster": "%UPSTREAM_CLUSTER%"}'
kind: ConfigMap
metadata:
  name: istio-asm-managed-rapid
  namespace: istio-system
EOF

Zugriffslogs ansehen

Envoy-Zugriffslogs

Befehlszeile

Führen Sie den folgenden Befehl aus, um Envoy-Zugriffsprotokolle im istio-proxy-Log aufzurufen:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy

Log-Explorer

So rufen Sie Envoy-Zugriffslogs im Log-Explorer auf:

  1. Rufen Sie den Log-Explorer auf:

    Zu „Log-Explorer“

  2. Wählen Sie das entsprechende Google Cloud -Projekt aus.

  3. Führen Sie die folgende Abfrage aus:

resource.type="k8s_container" \
resource.labels.container_name="istio-proxy"
resource.labels.cluster_name="CLUSTER_NAME" \
resource.labels.namespace_name="NAMESPACE_NAME" \
resource.labels.pod_name="POD_NAME"

Trafficlogs

So rufen Sie Traffic-Logs im Log-Explorer auf:

  1. Rufen Sie den Log-Explorer auf:

    Zu „Log-Explorer“

  2. Wählen Sie das entsprechende Google Cloud Projekt aus.

  3. Führen Sie die folgende Abfrage aus, je nachdem, ob Sie Client- oder Serverzugriffsprotokolle ansehen:

    Server-Logs

    resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/server-accesslog-stackdriver"

    Clientprotokolle

    resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/client-accesslog-stackdriver"

So rufen Sie Traffic-Logs für einen Dienst in einer bestimmten Zeitspanne auf der Cloud Service Mesh-Seite auf:

  1. Rufen Sie in der Google Cloud Console die Seite Cloud Service Mesh auf.

    Zur Seite „Cloud Service Mesh“

  2. Wählen Sie unter Dienste den Namen des Dienstes aus, den Sie prüfen möchten.

  3. Rufen Sie die Seite Messwerte auf.

  4. Geben Sie im Drop-down-Menü Zeitspanne einen Zeitraum an oder legen Sie eine benutzerdefinierte Zeitspanne mit der Zeitachse fest.

  5. Klicken Sie unter Filteroption auswählen auf Traffic-Logs ansehen.

Das Traffic-Log hat den Namen server-accesslog-stackdriver und ist an die entsprechende überwachte Ressource (k8s_container oder gce_instance) angehängt, die Ihr Dienst verwendet. Das Traffic-Log enthält die folgenden Informationen:

  • HTTP-Anfrageattribute wie ID, URL, Größe, Latenz und allgemeine Header.

  • Informationen zu Quell- und Zielarbeitslast, z. B. Name, Namespace, Identität und allgemeine Labels.

  • Wenn Tracing aktiviert ist, werden Trace-Informationen, z. B. Stichprobenerfassung, Trace-ID und Span-ID, angezeigt.

Ein Beispiel für einen Logeintrag sieht so aus:

{
  insertId: "1awb4hug5pos2qi"
  httpRequest: {
    requestMethod: "GET"
    requestUrl: "YOUR-INGRESS/productpage"
    requestSize: "952"
    status: 200
    responseSize: "5875"
    remoteIp: "10.8.0.44:0"
    serverIp: "10.56.4.25:9080"
    latency: "1.587232023s"
    protocol: "http"
  }
  resource: {
    type: "k8s_container"
    labels: {
      location: "us-central1-a"
      project_id: "YOUR-PROJECT"
      pod_name: "productpage-v1-76589d9fdc-ptnt9"
      cluster_name: "YOUR-CLUSTER-NAME"
      container_name: "productpage"
      namespace_name: "default"
    }
  }
  timestamp: "2020-04-28T19:55:21.056759Z"
  severity: "INFO"
  labels: {
    destination_principal: "spiffe://cluster.local/ns/default/sa/bookinfo-productpage"
    response_flag: "-"
    destination_service_host: "productpage.default.svc.cluster.local"
    source_app: "istio-ingressgateway"
    service_authentication_policy: "MUTUAL_TLS"
    source_name: "istio-ingressgateway-5ff85d8dd8-mwplb"
    mesh_uid: "YOUR-MESH-UID"
    request_id: "021ce752-9001-4ac6-b6d6-3b15f5d3632"
    destination_namespace: "default"
    source_principal:  "spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"
    destination_workload: "productpage-v1"
    destination_version: "v1"
    source_namespace: "istio-system"
    source_workload: "istio-ingressgateway"
    destination_name: "productpage-v1-76589d9fdc-ptnt9"
    destination_app: "productpage"
  }
  trace: "projects/YOUR-PROJECT/traces/d4197f59b7a43e3aeff3571bac99d536"
  receiveTimestamp: "2020-04-29T03:07:14.362416217Z"
  spanId: "43226343ca2bb2b1"
  traceSampled: true
  logName: "projects/YOUR-PROJECT/logs/server-accesslog-stackdriver"
  receiveTimestamp: "2020-04-28T19:55:32.185229100Z"
}

Cloud Service Mesh-Telemetrie interpretieren

In den folgenden Abschnitten wird beschrieben, wie du den Status deines Mesh-Netzwerks prüfen und die verschiedenen Telemetriedaten ansehen kannst, die hilfreiche Details für die Fehlerbehebung enthalten.

Messwerte der Steuerungsebene interpretieren

Verwalteter Traffic Director

Cloud Service Mesh mit einer verwalteten Traffic Director-Steuerungsebene unterstützt keine Steuerungsebenenmesswerte.

Verwaltete istiod

Cloud Service Mesh mit einer verwalteten istiod-Steuerungsebene unterstützt die in diesem Abschnitt beschriebene Prüfung von Messwerten der Steuerungsebene nicht.

Clusterintern

Wenn Sie Cloud Service Mesh mit der clusterinternen Steuerungsebene installieren, exportiert istiod standardmäßig Messwerte zur Überwachung in Google Cloud Observability. istiod 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/dashboards && git checkout servicemesh

  2. Installieren Sie das Cloud 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.

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

Konfigurationsverzögerungen diagnostizieren

Managed Traffic Director

Cloud Service Mesh mit einer verwalteten Traffic Director-Steuerungsebene unterstützt die Diagnose von Konfigurationsverzögerungen nicht.

Verwaltet von istiod

Cloud Service Mesh mit einer verwalteten istiod-Steuerungsebene unterstützt die Diagnose von Konfigurationsverzögerungen nicht.

Clusterintern

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 debug --image istio/base --target istio-proxy -it $(kubectl get pod -l app=pilot -o jsonpath='{.items[0].metadata.name}' -n istio-system) -n istio-system -- curl -s

  2. Greifen Sie auf localhost:15014 und grep für convergence in Messwerten zu:

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

Traffic-Logs interpretieren

Im Folgenden wird erläutert, wie Sie Traffic-Protokolle verwenden, um Verbindungsprobleme zu beheben. Trafficlogs sind standardmäßig aktiviert.

Cloud Service Mesh exportiert Daten in Traffic-Logs, die Ihnen bei der Behebung der folgenden Problemarten helfen können:

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

Trafficlogs sind für Cloud Service Mesh-Installationen in Google Kubernetes Engine standardmäßig aktiviert. Sie können Trafficlogs wieder aktivieren. Führen Sie dazu asmcli install noch einmal aus. Verwenden Sie die Optionen, die Sie ursprünglich installiert haben, aber lassen Sie das benutzerdefinierte Overlay weg, das Stackdriver deaktiviert hat.

Es gibt zwei Arten von Traffic-Logs:

  • 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

Zugriffslogs enthalten folgende Informationen:

  • HTTP-Anfrageattribute, z. B. ID, URL, Größe, Latenz und allgemeine Header.
  • Informationen zur Quell- und Zielarbeitslast, z. B. Name, Namespace, Identität und allgemeine Labels.
  • Informationen zum kanonischen Dienst und zur Überarbeitung von Quelle und Ziel.
  • Wenn das Tracing aktiviert ist, enthalten die Logs Trace-Informationen wie Stichprobenerhebung, Trace-ID und Span-ID.

Traffic-Logs können die folgenden Labels enthalten:

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

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:

  • In Cloud Trace einbinden, ein optionales Feature in Cloud 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 Clientzugriffslog 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. Rufen Sie die Labels im Zugriffsprotokolleintrag auf. 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-Zugriffslogs interpretieren

In den folgenden Schritten wird erläutert, wie Sie die Envoy-Zugriffslogs verwenden, um den Traffic zwischen beiden Enden einer Verbindung zur Fehlerbehebung anzuzeigen.

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

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

Envoy-Zugriffsprotokolle sind in Cloud Service Mesh nicht standardmäßig aktiviert und können für die Cluster in einem Mesh aktiviert werden.

Sie können Verbindungs- oder Anfragefehler beheben, indem Sie in Ihrer Anwendung Aktivität generieren, die eine HTTP-Anfrage auslöst, und dann die zugehörige Anfrage in den Quell- oder Ziellogs prüfen.

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 Sie Fehler in den Logs sehen, generieren Sie einen Envoy-Konfigurations-Dump und prüfen Sie, ob die Envoy-Clusterkonfiguration 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 dem Log-Explorer abfragen

Sie können über die Benutzeroberfläche des Log-Explorers bestimmte Envoy-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

Verwalteter Traffic Director

Informationen zum Konfigurieren von Zugriffslogs für Cloud Service Mesh mit einer verwalteten Traffic Director-Steuerungsebene finden Sie unter Zugriffslogs aktivieren.

Verwaltet von istiod

Informationen zum Konfigurieren von Zugriffslogs für Cloud Service Mesh mit einer verwalteten istiod-Steuerungsebene finden Sie unter Zugriffslogs aktivieren.

Clusterintern

So legen Sie eine Zugriffslogrichtlinie für Cloud Service Mesh mit der clusterinternen Steuerungsebene fest:

  1. Erstellen Sie eine benutzerdefinierte IstioOperator-Overlay-Datei, die die entsprechenden AccessLogPolicyConfig-Werte für Ihr Szenario enthält.

  2. Übergeben Sie diese Datei mit der Option --custom_overlay an asmcli, um die Konfiguration der Steuerungsebene im Cluster zu aktualisieren. Informationen zum Ausführen von asmcli install mit einer benutzerdefinierten Overlay-Datei finden Sie unter Mit optionalen Features installieren.

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 -n NAMESPACE_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 ansehen 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 debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -anopim

  2. Zusammenfassung der Socket-Statistiken anzeigen:

    kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- 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 -n NAMESPACE_NAME -c istio-proxy

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

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-init

Nächste Schritte