Sie sehen die Legacy-Dokumentation zum Service Mesh der Version 1.18.

Verfügbare Versionen

Cloud Service Mesh
1.20-Archiv
1.19-Archiv
1.18-Archiv

Diese Seite wurde von der Cloud Translation API übersetzt.

Proxylogs anfordern

Die Cloud Service Mesh-Seiten enthalten Links zu zwei verschiedenen Arten von Logs in Cloud Logging: Zugriffslogs (auch als Envoy-Logs bezeichnet) und Trafficlogs (auch als Google Cloud Observability-Zugriffslogs bezeichnet).

Zugriffslogs

Zugriffslogs aktivieren

Die erforderlichen Schritte zum Aktivieren von Zugriffslogs hängen vom Cloud Service Mesh-Typ ab, entweder verwaltet oder im Cluster:

Verwaltet

Folgen Sie der Anleitung zum Aktivieren von Zugriffslogs im verwalteten Cloud Service Mesh.

Clusterintern

Folgen Sie der Anleitung zum Aktivieren von Zugriffslogs im Cloud Service Mesh im Cluster.

Zugriffslogs ansehen

So rufen Sie Zugriffslogs im Log-Explorer auf:

Rufen Sie den Log-Explorer auf:

Zu „Log-Explorer“
Wählen Sie das entsprechende Google Cloud-Projekt aus.

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"

Traffic-Logs

Trafficlogs aktivieren

Traffic-Logs sind standardmäßig aktiviert, es sei denn, Cloud Service Mesh ist in Google Distributed Cloud Virtual with Istio CA (früher als Citadel bezeichnet) installiert.

Wenn Sie Trafficlogs in Google Distributed Cloud Virtual mit Istio CA aktivieren möchten, beim Installieren des Cloud Service Mesh im Cluster, verwenden Sie das Flag --option stackdriver. Alternativ können Sie Trafficlogs in Google Distributed Cloud Virtual mit Istio CA aktivieren, nachdem Sie Cloud Service Mesh im Cluster installiert haben.

Traffic-Logs ansehen

Traffic-Logs im Log-Explorer ansehen

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

Rufen Sie den Log-Explorer auf:

Zu „Log-Explorer“
Wählen Sie das entsprechende Google Cloud-Projekt aus.

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

Serverprotokolle

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"

Trafficlogs auf der Seite „Anthos Service Mesh“ ansehen

Gehen Sie so vor, um Trafficlogs auf der Cloud Service Mesh-Seite für einen Dienst während eines bestimmten Zeitraums anzusehen:

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

Zur Seite „Cloud Service Mesh“
Wählen Sie unter Dienste den Namen des Dienstes aus, den Sie prüfen möchten.
Rufen Sie die Seite Messwerte auf.
Geben Sie im Drop-down-Menü Zeitspanne einen Zeitraum an oder legen Sie eine benutzerdefinierte Zeitspanne mit der Zeitachse fest.
Klicken Sie unter Eine Filteroption auswählen auf Traffic-Logs ansehen.

Das Traffic-Log trägt den Namenserver-accesslog-stackdriver und ist an die entsprechende überwachte Ressource angehängt (k8s_container oder gce_instance ), die Ihre Anwendung verwendet, angehängt. Das Traffic-Log enthält die folgenden 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.
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"
}

Anthos Service Mesh-Telemetrie interpretieren

In den folgenden Abschnitten wird erläutert, wie Sie den Status Ihres Mesh-Netzwerks prüfen und die verschiedenen Telemetriedaten überprüfen, die hilfreiche Details zur Fehlerbehebung enthalten.

Messwerte der Steuerungsebene interpretieren

Beim Installieren von Cloud Service Mesh mit der clusterinternen Steuerungsebene exportiert istiod standardmäßig Messwerte für das Monitoring nach 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.

Beispiel-Dashboard laden:

git clone https://github.com/GoogleCloudPlatform/monitoring-dashboard-samples && cd monitoring-dashboard-samples/dashboards && git checkout servicemesh

Installieren Sie das Cloud Service Mesh-Dashboard:

gcloud monitoring dashboards create --config-from-file=dashboards/servicemesh/anthos-service-mesh-control-plane-monitoring.json

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

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.

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

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 mithilfe der Google Cloud Observability-Zugriffslogs Verbindungsprobleme beheben. Zugriffs-/Trafficlogs für die Beobachtbarkeit von Google Cloud sind standardmäßig aktiviert.

Cloud Service Mesh exportiert Daten in Google Cloud Observability-Zugriffslogs, mit denen Sie die folgenden Arten von Problemen beheben können:

Datenverkehr und Fehler
End-to-End-Anfragerouting

Zugriffslogs für die Beobachtbarkeit von Google Cloud sind standardmäßig für Cloud Service Mesh-Installationen in Google Kubernetes Engine aktiviert. Sie können Zugriffslogs für Google Cloud Observability aktivieren, indem Sie asmcli install noch einmal ausführen. 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 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
```

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 Informationen, die in den Zugriffslogs für die Beobachtbarkeit von Google Cloud angezeigt werden, stammen aus Envoy-Zugriffslogs, wenn Sie sie 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, 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.

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"
}

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.
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.

Zugriffslogs interpretieren

In den folgenden Schritten wird erläutert, wie Sie die Zugriffslogs (auch als Envoy-Proxy-Logs bezeichnet) verwenden, um den Traffic zwischen beiden Enden einer Verbindung zur Fehlerbehebung anzuzeigen.

Zugriffsprotokolle sind nützlich für die Diagnose von Problemen wie:

Datenverkehr und Fehler
End-to-End-Anfragerouting

Zugriffslogs sind in Cloud 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 die Logs Fehler enthalten, 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 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

Informationen zum Konfigurieren des Proxy-Loggings für das verwaltete Cloud Service Mesh finden Sie unter Envoy-Zugriffslogs.

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

Erstellen Sie eine benutzerdefinierte Overlay-Datei IstioOperator, die die anwendbaren AccessLogPolicyConfig-Werte für Ihr Szenario enthält.
Ü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.

Achtung: Wenn Sie die vorherige Installation angepasst haben, benötigen Sie dieselben Anpassungen, wenn Sie die Steuerungsebene neu installieren, um die Datei mit den Einstellungen für AccessLogPolicyConfig aufzunehmen. Wenn eine Overlay-Datei weggelassen wird, führt dies zu einer erfolgreichen Installation. Ihr Service Mesh hat jedoch eine andere Konfiguration als beabsichtigt, da die ausgelassenen Werte auf die Standardwerte zurückgesetzt werden, wenn die Steuerungsebene noch einmal bereitgestellt wird.

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.

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
```
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

Nächste Schritte

In Cloud Trace einbinden Cloud Trace ist ein optionales Feature in Cloud Service Mesh.
Traffic-Logs nach BigQuery exportieren
Logbasierte Messwerte erstellen