Auf Logs in Cloud Logging zugreifen
Die Anthos Service Mesh-Seiten enthalten Links zu drei verschiedenen Arten von Logs in Cloud Logging: Anwendungslogs, Fehlerlogs und Trafficlogs.
Auf Anwendungslogs zugreifen
So rufen Sie Anwendungslogs für einen Dienst in einer bestimmten Zeitspanne auf:
Rufen Sie in der Google Cloud Console die Seite Anthos Service Mesh auf.
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 auf Anwendungslogs aufrufen.
Die Anwendungslogs sind die Logs, die von Ihrem eigenen Anwendungscode generiert und an die entsprechende überwachte Ressource (k8s_container oder gce_instance), die Ihre Anwendung verwendet, angehängt werden.
Auf Fehlerlogs zugreifen
So rufen Sie Fehlerlogs für einen Dienst in einer bestimmten Zeitspanne auf:
Rufen Sie in der Google Cloud Console die Seite Anthos Service Mesh auf.
Wählen Sie unter Dienste den Namen des Dienstes aus, den Sie prüfen möchten.
Rufen Sie die Seite Diagnose auf.
Geben Sie im Drop-down-Menü Zeitspanne einen Zeitraum an oder legen Sie eine benutzerdefinierte Zeitspanne mit der Zeitachse fest.
Klicken Sie oben rechts im Fenster auf In Logging öffnen.
Auf Traffic-Logs zugreifen
Führen Sie die folgenden Schritte aus, um für einen Dienst während einer bestimmten Zeitspanne Traffic-Logs anzuzeigen oder auf Logs in Istio zuzugreifen:
Rufen Sie in der Google Cloud Console die Seite Anthos Service Mesh auf.
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 filter_list 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-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
Bei der Installation von Anthos Service Mesh mit der clusterinternen Steuerungsebene exportiert istiod
standardmäßig Messwerte zum Monitoring in Google Cloud-Beobachtbarkeit.
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 Anthos 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
undgrep
fürconvergence
in Messwerten zu:curl http://localhost:15014/metrics | grep convergence
Zugriffslogs für die Beobachtbarkeit von Google Cloud interpretieren
Im Folgenden wird erläutert, wie Sie mithilfe der Zugriffslogs von Google Cloud für die Beobachtbarkeit Verbindungsprobleme beheben. Zugriffs-/Trafficlogs für Google Cloud-Beobachtbarkeit sind standardmäßig aktiviert.
Anthos Service Mesh exportiert Daten in Google Cloud-Zugriffslogs für die Beobachtbarkeit, mit denen Sie die folgenden Arten von Problemen beheben können:
- Datenverkehr und Fehler
- End-to-End-Anfragerouting
Zugriffslogs für Google Cloud-Beobachtbarkeit sind für Anthos Service Mesh-Installationen in Google Kubernetes Engine standardmäßig aktiviert. Sie können Zugriffslogs für Google Cloud-Beobachtbarkeit 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 Ressourcek8s_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 Ressourcek8s_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 die Loggingkosten zu reduzieren.
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 für die Beobachtbarkeit von Google Cloud angezeigten Informationen 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, 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
- und503
-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ürNoRoute
. Das bedeutet, dass keine Route für das Ziel gefunden wurde oder es keine übereinstimmende Filterkette für eine nachgelagerte Verbindung gibt. Mit dem Labelresponse_flag
können Sie auch503
-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 aberhttp2
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 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 verwaltetes Anthos Service Mesh finden Sie unter Envoy-Zugriffslogs.
So legen Sie eine Zugriffslogrichtlinie für Anthos Service Mesh mit der Steuerungsebene im Cluster fest:
Erstellen Sie eine benutzerdefinierte
IstioOperator
-Overlay-Datei, die die entsprechendenAccessLogPolicyConfig
-Werte für Ihr Szenario enthält.Übergeben Sie diese Datei mit der Option
--custom_overlay
anasmcli
, um die Konfiguration der Steuerungsebene im Cluster zu aktualisieren. Informationen zum Ausführen vonasmcli 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 -c istio-proxy -- pilot-agent request GET SCOPE
Im Beispiel ist SCOPE eine der folgenden Optionen:
certs
– Zertifikate in der Envoy-Instanzclusters
– Cluster mit konfiguriertem Envoyconfig_dump
– Löscht die Envoy-Konfigurationlisteners
– Listener mit konfiguriertem Envoylogging
– Logging-Einstellungen aufrufen und ändernstats
– Envoy-Statistikenstats/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 Anthos Service Mesh.