Anthos Service Mesh und Traffic Director heißen jetzt Cloud Service Mesh. Weitere Informationen finden Sie in der Cloud Service Mesh-Übersicht.

Diese Seite wurde von der Cloud Translation API übersetzt.

Fehlerbehebung bei Envoy-Bereitstellungen

Diese Anleitung enthält Informationen zur Behebung von Konfigurationsproblemen mit Envoy-Clients, wenn Sie Cloud Service Mesh mit Google APIs ausführen. Informationen zur Verwendung der Client Status Discovery Service (CSDS) API für die Untersuchung von Problemen mit Cloud Service Mesh finden Sie unter Informationen zum Cloud Service Mesh-Clientstatus.

Auf einer VM installierte Envoy-Version ermitteln

Anhand dieser Anleitung können Sie prüfen, welche Version von Envoy auf einer VM-Instanz ausgeführt wird.

So können Sie die Envoy-Version prüfen:

Prüfen Sie die Gastattribute der VM unter dem Pfad gce-service-proxy/proxy-version:

gcloud compute --project cloud-vm-mesh-monitoring instances get-guest-attributes INSTANCE_NAME
--zone ZONEc --query-path=gce-service-proxy/proxy-version

NAMESPACE KEY VALUE gce-service-proxy proxy-version dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

Prüfen Sie die Cloud Logging-Instanzlogs auf der Seite "Logging" der VM-Instanzdetails in der Google Cloud Console mit einer Abfrage wie dieser:

  resource.type="gce_instance"
  resource.labels.instance_id="3633122484352464042"
  jsonPayload.message:"Envoy version"

Sie erhalten eine Antwort wie die folgende:

  {
    "insertId": "9zy0btf94961a",
    "jsonPayload": {
      "message": "Envoy Version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
      "localTimestamp": "2021-01-12T11:39:14.3991Z"
    },
    "resource": {
      "type": "gce_instance",
      "labels": {
        "zone": "asia-southeast1-b",
        "instance_id": "3633122484352464042",
        "project_id": "cloud-vm-mesh-monitoring"
      }
    },
    "timestamp": "2021-01-12T11:39:14.399200504Z",
    "severity": "INFO",
    "logName": "projects/cloud-vm-mesh-monitoring/logs/service-proxy-agent",
    "receiveTimestamp": "2021-01-12T11:39:15.407023427Z"
  }

Stellen Sie eine SSH-Verbindung zu einer VM her und prüfen Sie die Binärversion:

YOUR_USER_NAME@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~$ /usr/local/bin/envoy --version

/usr/local/bin/envoy version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

Stellen Sie eine SSH-Verbindung zu einer VM und der Administratoroberfläche als Root her:

  root@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~# curl localhost:15000/server_info
  {
   "version": "dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
   "state": "LIVE",
   "hot_restart_version": "disabled",
   ...
  }

Logspeicherorte in Envoy

Zur Behebung einiger Fehler müssen Sie die Proxy-Logs von Envoy prüfen.

Sie können eine SSH-Verbindung zur VM-Instanz herstellen, um die Logdatei abzurufen. Der Pfad sieht wahrscheinlich so aus:

  /var/log/envoy/envoy.err.log

Proxys stellen keine Verbindung zu Cloud Service Mesh her

Wenn Ihre Proxys keine Verbindung zu Cloud Service Mesh herstellen, gehen Sie so vor:

Prüfen Sie die Proxy-Logs von Envoy auf Fehler der Verbindung mit trafficdirector.googleapis.com.
Wenn Sie netfilter (über iptables) so eingerichtet haben, dass der gesamte Traffic an den Envoy-Proxy weitergeleitet wird, achten Sie darauf, dass der Nutzer (UID), mit dem Sie den Proxy ausführen, von der Weiterleitung ausgeschlossen ist. Andernfalls führt dies dazu, dass der Traffic ständig zum Proxy zurückgeleitet wird.
Prüfen Sie, ob die Cloud Service Mesh API für das Projekt aktiviert ist. Suchen Sie unter APIs und Dienste für Ihr Projekt nach Fehlern der Cloud Service Mesh API.
Prüfen Sie, ob der API-Zugriffsbereich der VM so eingestellt ist, dass uneingeschränkter Zugriff auf die Google Cloud APIs möglich ist. Geben Sie dazu beim Erstellen der VM Folgendes an:
```
--scopes=https://www.googleapis.com/auth/cloud-platform
```
Prüfen Sie, ob das Dienstkonto die richtigen Berechtigungen hat. Weitere Informationen finden Sie unter Dienstkonto für den Zugriff auf die Traffic Director API aktivieren.
Prüfen Sie, ob Sie von der VM auf trafficdirector.googleapis.com:443 zugreifen können. Wenn es Probleme mit diesem Zugriff gibt, könnte dies daran liegen, dass eine Firewall den Zugriff auf trafficdirector.googleapis.com über den TCP-Port 443 verhindert oder Probleme mit der DNS-Auflösung für den Hostnamen trafficdirector.googleapis.com vorliegen.
Wenn Sie Envoy für den Sidecar-Proxy verwenden, achten Sie darauf, dass es sich bei der Envoy-Version um 1.24.9 oder höher handelt.

Der mit Cloud Service Mesh konfigurierte Dienst ist nicht erreichbar

Wenn ein mit Cloud Service Mesh konfigurierter Dienst nicht erreichbar ist, prüfen Sie, ob der Sidecar-Proxy ausgeführt wird und eine Verbindung zu Cloud Service Mesh hergestellt werden kann.

Wenn Sie Envoy als Sidecar-Proxy verwenden, können Sie dies mit den folgenden Befehlen prüfen:

Prüfen Sie in der Befehlszeile, ob der Envoy-Prozess ausgeführt wird:
```
ps aux | grep envoy
```
Prüfen Sie die Laufzeitkonfiguration von Envoy, um zu bestätigen, dass Cloud Service Mesh dynamische Ressourcen konfiguriert hat. Führen Sie den folgenden Befehl aus, um die Konfiguration aufzurufen:
```
curl http://localhost:15000/config_dump
```
Achten Sie darauf, dass das Abfangen von Traffic für den Sidecar-Proxy korrekt eingerichtet ist. Führen Sie für die Weiterleitungskonfiguration mit iptables den Befehl iptables und dann grep für die Ausgabe aus, um zu prüfen, ob Ihre Regeln vorhanden sind:
```
sudo iptables -t nat -S | grep ISTIO
```
Hier ein Beispiel für die Ausgabe, die Sie erhalten, wenn iptables die virtuelle IP-Adresse (VIP) 10.0.0.1/32 abfängt und an einen Envoy-Proxy weiterleitet, der an Port 15001 als UID1006 ausgeführt wird:
```
-N ISTIO_IN_REDIRECT
-N ISTIO_OUTPUT
-N ISTIO_REDIRECT
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15001
-A ISTIO_OUTPUT -m owner --uid-owner 1006 -j RETURN
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
-A ISTIO_OUTPUT -d 10.0.0.1/32 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -j RETURN
```

Wenn die VM-Instanz über die Google Cloud Console erstellt wird, sind einige IPv6-bezogene Module nicht installiert und vor einem Neustart verfügbar. Dies führt dazu, dass iptables aufgrund fehlender Abhängigkeiten fehlschlägt. Starten Sie in diesem Fall die VM neu und führen Sie den Einrichtungsprozess noch einmal aus, um das Problem zu beheben. Bei einer Compute Engine-VM, die Sie mithilfe der Google Cloud CLI erstellt haben, wird dieses Problem nicht erwartet.

Der Dienst ist nicht mehr erreichbar, wenn das Zugriffs-Logging von Envoy konfiguriert ist

Wenn Sie mit TRAFFICDIRECTOR_ACCESS_LOG_PATH ein Envoy-Zugriffslog konfiguriert haben, wie unter Envoy-Bootstrap-Attribute für Cloud Service Mesh konfigurieren beschrieben, achten Sie darauf, dass der Systemnutzer, der den Envoy-Proxy ausführt, Schreibzugriff auf den angegebenen Speicherort des Zugriffslogs hat.

Ohne die erforderlichen Berechtigungen werden die Listener nicht auf dem Proxy programmiert. Dies erkennen Sie an der folgenden Fehlermeldung im Proxy-Log von Envoy:

gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected:
Error adding/updating listener(s) TRAFFICDIRECTOR_INTERCEPTION_PORT:
unable to open file '/var/log/envoy.log': Permission denied

Ändern Sie zur Behebung des Problems die Berechtigungen für die ausgewählte Datei, damit der Envoy-Nutzer Schreibzugriff auf das Zugriffslog erhält.

Fehlermeldungen in den Envoy-Logs, die auf ein Konfigurationsproblem hinweisen

Dieser Abschnitt gilt für Bereitstellungen mit den Load Balancing APIs.

Wenn Probleme mit der Cloud Service Mesh-Konfiguration auftreten, werden in den Envoy-Logs möglicherweise folgende Fehlermeldungen angezeigt:

warning envoy config    StreamAggregatedResources gRPC config stream closed:
5, Cloud Service Mesh configuration was not found for network "VPC_NAME" in
project "PROJECT_NUMBER".

warning envoy upstream  StreamLoadStats gRPC config stream closed:
5, Cloud Service Mesh configuration was not found for network "VPC_NAME" in
project "PROJECT_NUMBER".

warning envoy config    StreamAggregatedResources gRPC config stream closed:
5, Requested entity was not found.

warning envoy upstream  StreamLoadStats gRPC config stream closed:
5, Requested entity was not found.

Cloud Service Mesh configuration was not found.

Die letzte Fehlermeldung (Traffic Director configuration was not found) zeigt im Allgemeinen an, dass Envoy eine Konfiguration von Cloud Service Mesh anfordert, aber keine passende Konfiguration gefunden wird. Wenn Envoy eine Verbindung zu Cloud Service Mesh herstellt, wird der Name eines VPC-Netzwerk angezeigt (z. B. my-network). Cloud Service Mesh sucht dann nach Weiterleitungsregeln, die das Load-Balancing-Schema INTERNAL_SELF_MANAGED haben und auf denselben VPC-Netzwerknamen verweisen.

So beheben Sie diesen Fehler:

Achten Sie darauf, dass in Ihrem Netzwerk eine Weiterleitungsregel mit dem Load-Balancing-Schema INTERNAL_SELF_MANAGED vorhanden ist. Notieren Sie sich den VPC-Netzwerknamen der Weiterleitungsregel.
Wenn Sie Cloud Service Mesh mit automatisierten Envoy-Bereitstellungen in Compute Engine verwenden, achten Sie darauf, dass der für das Flag --service-proxy:network angegebene Wert mit dem VPC-Netzwerknamen der Weiterleitungsregel übereinstimmt.
Wenn Sie Cloud Service Mesh mit manuellen Envoy-Bereitstellungen in Compute Engine verwenden, prüfen Sie die Bootstrap-Datei von Envoy auf Folgendes:
1. Achten Sie darauf, dass der Wert für die Variable TRAFFICDIRECTOR_NETWORK_NAME mit dem VPC-Netzwerknamen der Weiterleitungsregel übereinstimmt.
2. Achten Sie darauf, dass in der Variable TRAFFICDIRECTOR_GCP_PROJECT_NUMBER die Projektnummer festgelegt ist.
Wenn Sie in GKE bereitstellen und den Auto-Injector verwenden, achten Sie darauf, dass die Projektnummer und der VPC-Netzwerkname richtig konfiguriert sind. Folgen Sie dazu der Anleitung unter Cloud Service Mesh-Einrichtung für GKE-Pods mit automatischer Envoy-Injection.

Fehlerbehebung für die Compute Engine

In diesem Abschnitt finden Sie Anleitungen zur Fehlerbehebung bei Envoy-Bereitstellungen für die Compute Engine.

Die Bootstrapping-Prozesse von Envoy und den VMs sowie weitere Vorgänge des Lebenszyklusmanagements können aus verschiedensten Gründen fehlschlagen. Zu diesen Gründen zählen vorübergehende Verbindungsprobleme, fehlerhafte Repositories, Programmfehler in Bootstrapping-Skripts und VM-Agents sowie unerwartete Nutzeraktionen.

Kommunikationskanäle zur Fehlerbehebung

Google Cloud bietet Kommunikationskanäle, dank derer Sie den Bootstrapping-Prozess und den aktuellen Status der Komponenten, die auf Ihren VMs existieren, besser verstehen können.

Logging der Ausgabe des virtuellen seriellen Ports

Das Betriebssystem, das BIOS und andere Entitäten auf Systemebene einer VM schreiben in der Regel eine Ausgabe an die seriellen Ports. Diese Ausgabe ist nützlich, um Systemabstürze, fehlgeschlagene Boot-Vorgänge sowie Probleme beim Starten und Herunterfahren zu beheben.

Bootstrapping-Agents von Compute Engine loggen alle ausgeführten Vorgänge am seriellen Port 1 zusammen mit Systemereignissen – angefangen bei der grundlegenden Paketinstallation über den Datenabruf vom Metadatenserver einer Instanz bis hin zur iptables-Konfiguration und dem Envoy-Installationsstatus.

Der VM-Agent erstellt Logs zum Envoy-Prozessstatus, zu neu erkannten Cloud Service Mesh-Diensten und anderen Informationen, die bei der Untersuchung von Problemen mit VMs nützlich sein könnten.

Logging mit Cloud Monitoring

Daten, die über den seriellen Port ausgegeben werden, werden auch in Monitoring protokolliert. Monitoring nutzt die Golang-Bibliothek und exportiert die Logs in ein separates Log, um Störungen zu reduzieren. Dieses Log wird auf Instanzebene erstellt. Daher finden sich Dienstproxy-Logs möglicherweise auf derselben Seite wie die anderen Instanzlogs.

VM-Gastattribute

Gastattribute sind ein spezieller Typ benutzerdefinierter Metadaten, in die Anwendungen Daten schreiben können, während sie auf der Instanz ausgeführt werden. Jede Anwendung und jeder Nutzer auf der Instanz kann Daten aus den Metadaten der Gastattribute lesen und in diese schreiben.

Bootstrap-Skripts von Envoy in Compute Engine und VM-Agents stellen Attribute mit Informationen zum Bootstrapping-Prozess und dem aktuellen Status von Envoy bereit. Alle Gastattribute werden im Namespace gce-service-proxy bereitgestellt:

gcloud compute instances get-guest-attributes INSTANCE_NAME  \
    --query-path=gce-service-proxy/ \
    --zone=ZONE

Wenn Probleme auftreten, empfehlen wir, den Wert der Gastattribute bootstrap-status und bootstrap-last-failure zu prüfen. Alle bootstrap-status-Werte außer FINISHED zeigen an, dass die Envoy-Umgebung noch nicht konfiguriert wurde. Der Wert von bookstrap-last-failure kann auf die Ursache des Problems hinweisen.

Der Cloud Service Mesh-Dienst kann nicht über eine VM erreicht werden, die aus einer Instanzvorlage mit aktiviertem Dienst-Proxy erstellt wurde

So beheben Sie dieses Problem:

Die Installation der Dienstproxykomponenten auf der VM ist möglicherweise noch nicht abgeschlossen oder fehlgeschlagen. Mit dem folgenden Befehl können Sie feststellen, ob alle Komponenten ordnungsgemäß installiert wurden:
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
    --query-path=gce-service-proxy/ \
    --zone=ZONE
```
Das Gastattribut bootstrap-status hat einen der folgenden Werte:
- [none] zeigt an, dass die Installation noch nicht gestartet wurde. Die VM wird möglicherweise noch gebootet. Prüfen Sie den Status in einigen Minuten noch einmal.
- IN PROGRESS gibt an, dass die Installation und Konfiguration der Dienstproxykomponenten noch nicht vollständig ist. Prüfen Sie den Status wiederholt auf Aktualisierungen.
- FAILED gibt an, dass die Installation oder Konfiguration einer Komponente fehlgeschlagen ist. Prüfen Sie die Fehlermeldung durch Abfrage des Attributs gce-service-proxy/bootstrap-last-failure1.
- FINISHED gibt an, dass die Installations- und Konfigurationsprozesse fehlerfrei abgeschlossen wurden. Folgen Sie der nachstehenden Anleitung, um zu prüfen, ob das Abfangen von Traffic und der Envoy-Proxy richtig konfiguriert sind.
Das Abfangen von Traffic auf der VM ist für Cloud Service Mesh-basierte Dienste nicht korrekt konfiguriert. Melden Sie sich bei der VM an und prüfen Sie die iptables-Konfiguration:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo iptables -L -t nat
```
Untersuchen Sie die Kette SERVICE_PROXY_SERVICE_CIDRS auf SERVICE_PROXY_REDIRECT-Einträge wie diese:
```
Chain SERVICE_PROXY_SERVICE_CIDRS (1 references)
target                   prot opt source         destination ...
SERVICE_PROXY_REDIRECT   all  --  anywhere       10.7.240.0/20
```
Für jeden Dienst muss in der Spalte destination eine entsprechende IP-Adresse oder ein CIDR-Bereich vorhanden sein. Wenn kein Eintrag für die virtuelle IP-Adresse (VIP) vorhanden ist, gibt es ein Problem beim Einfügen der Envoy-Proxy-Konfiguration aus Cloud Service Mesh oder der VM-Agent ist fehlgeschlagen.
Die Envoy-Proxys haben noch keine Konfiguration von Cloud Service Mesh erhalten. Melden Sie sich bei der VM an, um die Envoy-Proxy-Konfiguration zu prüfen:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump
```
Prüfen Sie die Listener-Konfiguration, die von Cloud Service Mesh empfangen wurde. Beispiel:
```
"dynamic_active_listeners": [
  ...
  "filter_chains": [{
    "filter_chain_match": {
      "prefix_ranges": [{
        "address_prefix": "10.7.240.20",
        "prefix_len": 32
      }],
      "destination_port": 80
    },
  ...
    "route_config_name": "URL_MAP/PROJECT_NUMBER.td-routing-rule-1"
  ...
]
```
Das address_prefix ist die virtuelle IP-Adresse (VIP) eines Cloud Service Mesh-Dienstes. Es verweist auf die URL-Zuordnung mit dem Namen td-routing-rule-1. Prüfen Sie, ob der Dienst, zu dem Sie eine Verbindung herstellen möchten, bereits in der Listener-Konfiguration enthalten ist.
Der VM-Agent wird nicht ausgeführt. Der VM-Agent konfiguriert automatisch das Abfangen von Traffic, wenn neue Cloud Service Mesh-Dienste erstellt werden. Wenn der Agent nicht ausgeführt wird, wird der gesamte Traffic zu neuen Diensten direkt an VIPs weitergeleitet. Dadurch wird der Envoy-Proxy umgangen und das Zeitlimit überschritten.
1. Prüfen Sie mit dem folgenden Befehl den Status des VM-Agents:
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
   --query-path=gce-service-proxy/ \
   --zone=ZONE
```
2. Prüfen Sie die Attribute des VM-Agents. Der Wert des Attributs agent-heartbeat gibt an, wann der Agent zuletzt eine Aktion oder Prüfung ausgeführt hat. Wenn der Wert älter als fünf Minuten ist, ist der Agent blockiert. Erstellen Sie die VM dann mit dem folgenden Befehl neu:
```
gcloud compute instance-groups managed recreate-instance
```
3. Das Attribut agent-last-failure zeigt den letzten Fehler im Agent an. Dies kann ein vorübergehendes Problem sein, das durch die nächste Prüfung des Agents behoben wird, z. B. wenn der Fehler Cannot reach the Cloud Service Mesh API server lautet, oder es handelt sich um einen permanenten Fehler. Warten Sie einige Minuten und prüfen Sie den Fehler noch einmal.

Das Abfangen eingehenden Traffics ist für den Arbeitslastport konfiguriert. Sie können jedoch keine Verbindung zum Port von außerhalb der VM herstellen.

So beheben Sie dieses Problem:

Die Installation der Dienstproxykomponenten auf der VM ist möglicherweise noch nicht abgeschlossen oder fehlgeschlagen. Mit dem folgenden Befehl können Sie feststellen, ob alle Komponenten ordnungsgemäß installiert wurden:
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
    --query-path=gce-service-proxy/ \
    --zone=ZONE
```
Das Gastattribut bootstrap-status hat einen der folgenden Werte:
- [none] zeigt an, dass die Installation noch nicht gestartet wurde. Die VM wird möglicherweise noch gebootet. Prüfen Sie den Status in einigen Minuten noch einmal.
- IN PROGRESS gibt an, dass die Installation und Konfiguration der Dienstproxykomponenten noch nicht vollständig ist. Prüfen Sie den Status wiederholt auf Aktualisierungen.
- FAILED gibt an, dass die Installation oder Konfiguration einer Komponente fehlgeschlagen ist. Prüfen Sie die Fehlermeldung durch Abfrage des Attributs gce-service-proxy/bootstrap-last-failure1.
- FINISHED gibt an, dass die Installations- und Konfigurationsprozesse fehlerfrei abgeschlossen wurden. Folgen Sie der nachstehenden Anleitung, um zu prüfen, ob das Abfangen von Traffic und der Envoy-Proxy richtig konfiguriert sind.
Das Abfangen von Traffic auf der VM ist für eingehenden Traffic nicht korrekt konfiguriert. Melden Sie sich bei der VM an und prüfen Sie die iptables-Konfiguration:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo iptables -L -t nat
```
Untersuchen Sie die Kette SERVICE_PROXY_INBOUND auf SERVICE_PROXY_IN_REDIRECT-Einträge wie diese:
```
Chain SERVICE_PROXY_INBOUND (1 references)
target                      prot opt source       destination ...
SERVICE_PROXY_IN_REDIRECT   tcp  --  anywhere     anywhere  tcp dpt:mysql
```
Für jeden in service-proxy:serving-ports definierten Port muss in der Spalte destination ein entsprechender Port vorhanden sein. Ist kein Eintrag für den Port vorhanden, wird der gesamte eingehende Traffic direkt an diesen Port weitergeleitet. Dadurch wird der Envoy-Proxy umgangen.

Achten Sie darauf, dass es keine anderen Regeln gibt, die Traffic an diesen Port oder alle Ports mit Ausnahme eines bestimmten Ports leiten.
Die Envoy-Proxys haben noch keine Konfiguration für den eingehenden Port von Cloud Service Mesh erhalten. Melden Sie sich bei der VM an, um die Envoy-Proxy-Konfiguration zu prüfen:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump
```
Suchen Sie nach der Listener-Konfiguration für eingehenden Traffic, die von Cloud Service Mesh empfangen wurde:
```
"dynamic_active_listeners": [
  ...
  "filter_chains": [{
    "filter_chain_match": {
      "prefix_ranges": [{
        "address_prefix": "10.0.0.1",
        "prefix_len": 32
      }],
      "destination_port": 80
    },
  ...
    "route_config_name": "inbound|default_inbound_config-80"
  ...
]
```
Der route_config_name, beginnend mit inbound, gibt einen speziellen Dienst an, der für das Abfangen von eingehendem Traffic erstellt wurde. Prüfen Sie, ob der Port, zu dem Sie eine Verbindung herstellen möchten, bereits in der Listener-Konfiguration unter destination_port enthalten ist.

Probleme bei der Verwendung serverbezogener Protokolle

Einige Anwendungen wie MySQL verwenden Protokolle, an die der Server das erste Paket sendet. Bei der ersten Verbindung sendet der Server also die ersten Byte. Diese Protokolle und Anwendungen werden von Cloud Service Mesh nicht unterstützt.

Fehlerbehebung für den Zustand Ihres Service Mesh

Diese Anleitung enthält Informationen zur Behebung von Konfigurationsproblemen in Cloud Service Mesh.

Cloud Service Mesh-Verhalten, wenn die meisten Endpunkte fehlerhaft sind

Wenn 99% der Endpunkte fehlerhaft sind, konfiguriert Cloud Service Mesh für eine bessere Zuverlässigkeit die Datenebene so, dass der Systemstatus der Endpunkte ignoriert wird. Stattdessen verteilt die Datenebene den Traffic unter allen Endpunkten, da der Bereitstellungsport möglicherweise noch funktioniert.

Fehlerhafte Back-Ends verursachen eine suboptimale Verteilung des Traffic

Cloud Service Mesh verwendet die Informationen in der HealthCheck-Ressource, die an einen Backend-Dienst angehängt sind, um den Status Ihrer Backends zu bewerten. Cloud Service Mesh verwendet diesen Status, um den Traffic an das nächstgelegene fehlerfreie Backend weiterzuleiten. Wenn einige Ihrer Back-Ends fehlerhaft sind, wird der Traffic möglicherweise mit suboptimaler Verteilung weiterhin verarbeitet. Beispiel: Traffic kann in eine Region fließen, in der fehlerfreie Back-Ends vorhanden sind, die aber sehr weit vom Client entfernt sind, was Latenz verursacht. Führen Sie folgende Schritte aus, um den Systemstatus Ihrer Back-Ends zu ermitteln und zu überwachen:

Prüfen Sie den Systemstatus Ihres Backend-Dienstes in der Google Cloud Console.
Cloud Service Mesh-Dienste aufrufen
Achten Sie darauf, dass für die HealthCheck-Ressource des Logging aktiviert ist.
Wenn es zu fehlgeschlagenen Systemdiagnosen kommt, prüfen Sie anhand von Cloud-Audit-Logs, ob Ihre HealthCheck-Konfiguration kürzlich geändert wurde.

Nächste Schritte

Informationen zum Beheben von Konfigurationsproblemen bei der Bereitstellung proxyloser gRPC-Dienste finden Sie unter Fehlerbehebung bei Bereitstellungen, die proxyloses gRPC verwenden.
Weitere Unterstützung zur Verwendung von Cloud Service Mesh finden Sie unter Support erhalten.