Fehlerbehebung bei proxylosen gRPC-Bereitstellungen
Dieses Dokument enthält Informationen zur Behebung von Konfigurationsproblemen. wenn Sie proxylose gRPC-Dienste mit Cloud Service Mesh bereitstellen. Für Informationen zur Verwendung der Client Status Discovery Service (CSDS) API für Hilfe bei der Untersuchung von Problemen mit dem Cloud Service Mesh finden Sie unter Informationen zum Status des Cloud Service Mesh-Clients.
RPC-Fehler in einer gRPC-Anwendung beheben
Es gibt zwei gängige Methoden, um RPC-Fehler (Remote Procedure Calls, Remote-Prozeduraufrufe) in einer gRPC-Anwendung zu beheben:
Prüfen Sie den Status, der zurückgegeben wird, wenn ein RPC fehlschlägt. In der Regel enthält der Status genügend Informationen, damit Sie die Ursache eines RPC-Fehlers besser verstehen.
Die Behebung von Statusfehlern in gRPC wird in der Dokumentation zur Fehlerbehandlung bei gRPC erläutert.
Beispiel für die Behebung von Statusfehlern in gRPC-Java Eine Ausnahme kann andere Ausnahmen als Ursache haben und dadurch können möglicherweise zusätzliche Informationen verfügbar werden.
Aktivieren Sie das Logging in der gRPC-Laufzeit. Manchmal müssen Sie die gRPC-Laufzeitlogs prüfen, wenn die Ursache eines Fehlers gesucht wird, der nicht in einem RPC-Rückgabestatus aufgeführt ist. Wenn beispielsweise ein RPC mit dem Status fehlschlägt, dass die Frist überschritten wurde, können Sie in den Logs den Fehler ermitteln, der zur Fristüberschreitung geführt hat.
Die unterschiedlichen Sprachimplementierungen von gRPC bieten verschiedene Möglichkeiten, um das Logging in der gRPC-Laufzeit zu aktivieren.
gRPC in Java: gRPC nutzt
java.util.logging
für das Logging. Legen Sie fürio.grpc.level
den WertFINE
fest, um ein ausreichend ausführliches Logging in der gRPC-Laufzeit zu ermöglichen. Eine typische Methode zur Aktivierung des Loggings in Java besteht darin, die Logging-Konfiguration aus einer Datei zu laden und den Speicherort der Datei mithilfe eines Befehlszeilen-Flags an die JVM zu übergeben. Beispiel:# Create a file called logging.properties with the following contents: handlers=java.util.logging.ConsoleHandler io.grpc.level=FINE io.grpc.xds.level=FINEST java.util.logging.ConsoleHandler.level=ALL java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter # Pass the location of the file to JVM by using this command-line flag: -Djava.util.logging.config.file=logging.properties
Um das Logging speziell für xDS-Module zu aktivieren, legen Sie für
io.grpc.xds.level
den WertFINE
fest. Für ein detaillierteres Logging können Sie als EbeneFINER
oderFINEST
festlegen.gRPC in Go: Aktivieren Sie das Logging durch Festlegung von Umgebungsvariablen.
GRPC_GO_LOG_VERBOSITY_LEVEL=99 GRPC_GO_LOG_SEVERITY_LEVEL=info
gRPC in C++: Wie Sie Logging mit gRPC in C++ aktivieren, erfahren Sie unter gRPC Fehler beheben. Um das spezifische Logging für xDS-Module zu aktivieren, aktivieren Sie die folgenden Tracer, indem Sie unter Verwendung der Umgebungsvariable
GRPC_TRACE
fürxds_client
,xds_resolver
,cds_lb
,eds_lb
,priority_lb
,weighted_target_lb
undlrs_lb
.gRPC in Node.js: Informationen zum Aktivieren des Loggings mit gRPC in Node.js finden Sie unter Fehlerbehebung für gRPC-JS. Um das spezifische Logging für xDS-Module zu aktivieren, aktivieren Sie die folgenden Tracer, indem Sie unter Verwendung der Umgebungsvariable
GRPC_TRACE
fürxds_client
,xds_resolver
,cds_balancer
,eds_balancer
,priority
, undweighted_target
.
Je nach dem Fehler, der im RPC-Status oder in den Laufzeitlogs angezeigt wird, kann das Problem in eine der folgenden Kategorien fallen.
Verbindung zu Cloud Service Mesh kann nicht hergestellt werden
Um Verbindungsprobleme zu beheben, führen Sie Folgendes aus:
- Prüfen Sie, ob der Wert von „server_uri“ in der Bootstrap-Datei
trafficdirector.googleapis.com:443
lautet. - Achten Sie darauf, dass die Umgebungsvariable
GRPC_XDS_BOOTSTRAP
definiert ist und auf die Bootstrap-Datei verweist. - Verwenden Sie unbedingt das Schema
xds
im URI, wenn Sie einen gRPC-Kanal erstellen. - Achten Sie darauf, dass Sie die erforderlichen IAM-Berechtigungen zum Erstellen von Compute-Instanzen und zum Ändern eines Netzwerks in einem Projekt haben.
- Achten Sie darauf, dass Sie Aktivieren Sie das Dienstkonto für den Zugriff auf die Traffic Director API. Klicken Sie im Bereich Google Cloud Console APIs und Dienste suchen Sie in der Traffic Director API nach Fehlern.
- Prüfen Sie, ob das Dienstkonto die richtigen Berechtigungen hat. Die in der VM oder im Pod ausgeführten gRPC-Anwendungen verwenden das Dienstkonto des Compute Engine-VM-Hosts oder der GKE-Knoteninstanz (Google Kubernetes Engine).
Prüfen Sie, ob der API-Zugriffsbereich der Compute Engine-VMs oder GKE-Cluster vollständigen Zugriff auf die Compute Engine APIs gewährt. Geben Sie dazu beim Erstellen der VMs oder des Clusters Folgendes an:
--scopes=https://www.googleapis.com/auth/cloud-platform
Prüfen Sie, ob Sie von der VM auf
trafficdirector.googleapis.com:443
zugreifen können. Wenn Zugriffsprobleme auftreten, kann dies daran liegen, dass eine Firewall den Zugriff auftrafficdirector.googleapis.com
über TCP-Port443
verhindert oder dass es Probleme mit der DNS-Auflösung für den Hostnamentrafficdirector.googleapis.com
gibt.
Der im URI angegebene Hostname kann nicht aufgelöst werden
In Ihren Logs wird möglicherweise eine Fehlermeldung wie die folgende angezeigt:
[Channel<1>: (xds:///my-service:12400)] Failed to resolve name. status=Status{code=UNAVAILABLE, description=NameResolver returned no usable address. addrs=[], attrs={}
Um Probleme mit der Auflösung von Hostnamen zu beheben, führen Sie Folgendes aus:
- Prüfen Sie, ob Sie eine unterstützte gRPC-Version und Sprache verwenden.
- Achten Sie darauf, dass der im URI verwendete Port zum Erstellen eines gRPC-Kanals mit dem Portwert in der Weiterleitungsregel übereinstimmt, die Sie in Ihrer Konfiguration verwenden. Wenn im URI kein Port angegeben ist, wird der Wert
80
zum Abgleichen einer Weiterleitungsregel verwendet. - Achten Sie darauf, dass der Hostname und der Port, die zum Erstellen eines gRPC-Kanals in der URI verwendet werden, genau mit einer Hostregel in der URL-Zuordnung Ihrer Konfiguration übereinstimmen.
- Diese Hostregel darf nur in einer URL-Zuordnung konfiguriert sein.
- Achten Sie darauf, dass keine Platzhalter verwendet werden. Hostregeln mit dem Platzhalterzeichen
*
werden ignoriert.
RPC schlägt fehl, weil der Dienst nicht verfügbar ist
So können Sie RPC-Fehler beheben, wenn ein Dienst nicht verfügbar ist:
Prüfen Sie den Gesamtstatus von Cloud Service Mesh und den Status Ihrer Backend-Dienste in der Google Cloud Console:
- Prüfen Sie in der Spalte Verknüpfte Routingregelzuordnungen, ob die richtigen URL-Zuordnungen auf die Backend-Dienste verweisen. Klicken Sie auf die Spalte, um zu prüfen, ob die in den Hostabgleichsregeln angegebenen Backend-Dienste korrekt sind.
- Prüfen Sie in der Spalte Backends, ob die mit Ihren Backend-Diensten verknüpften Backends fehlerfrei sind.
- Wenn die Back-Ends fehlerhaft sind, klicken Sie auf den entsprechenden Back-End-Dienst und prüfen Sie, ob die richtige Systemdiagnose konfiguriert ist. Systemdiagnosen schlagen häufig durch falsche oder fehlende Firewallregeln oder aufgrund einer Nichtübereinstimmung zwischen Tags fehl, die in der VM und in den Firewallregeln angegeben sind. Weitere Informationen finden Sie unter Systemdiagnosen erstellen.
Damit gRPC-Systemdiagnosen richtig funktionieren, müssen die gRPC-Back-Ends das gRPC-Systemdiagnoseprotokoll implementieren. Ist dieses Protokoll nicht implementiert, verwenden Sie stattdessen eine TCP-Systemdiagnose. Verwenden Sie eine HTTP-, HTTPS- oder HTTP/2-Systemdiagnose nicht mit gRPC-Diensten.
Achten Sie bei der Verwendung von Instanzgruppen darauf, dass der in der Instanzgruppe angegebene benannte Port mit dem in der Systemdiagnose verwendeten Port übereinstimmt. Bei der Verwendung von NEGs (Netzwerk-Endpunktgruppen) müssen Sie auch darauf achten, dass die GKE-Dienstspezifikation die richtige NEG-Annotation enthält und die Systemdiagnose für die Nutzung des NEG-Bereitstellungsports konfiguriert ist.
Prüfen Sie, ob das Endpunktprotokoll als
GRPC
konfiguriert ist.
RPC schlägt fehl, da die Load-Balancing-Richtlinie nicht unterstützt wird.
Möglicherweise wird in Ihren Logs eine Fehlermeldung wie diese angezeigt:
error parsing "CDS" response: resource "cloud-internal-istio:cloud_mp_248715": unexpected lbPolicy RING_HASH in response
error={"description":"errors parsing CDS response", "file":"external/com_github_grpc_grpc/src/core/ext/xds/xds_api.cc", "file_line":3304, "referenced_errors":[{"description":"cloud-internal-istio:cloud_mp_248715: LB policy is not supported."
WARNING: RPC failed: Status{code=INTERNAL, description=Panic! This is a bug!, cause=java.lang.NullPointerException: provider at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:910) at io.grpc.internal.ServiceConfigUtil$PolicySelection.<init>(ServiceConfigUtil.java:418) at io.grpc.xds.CdsLoadBalancer2$CdsLbState.handleClusterDiscovered(CdsLoadBalancer2.java:190)
Dies liegt daran, dass RING_HASH von der jeweiligen Sprache und Version des verwendeten Clients nicht unterstützt wird. Um das Problem zu beheben, aktualisieren Sie die Konfiguration des Backend-Dienstes, um nur unterstützte Load-Balancing-Richtlinien zu verwenden, oder aktualisieren Sie den Client auf eine unterstützte Version. Informationen zu unterstützten Clientversionen finden Sie unter xDS-Features in gRPC.
Die Sicherheitskonfiguration wurde nicht wie erwartet generiert
Wenn Sie die Dienstsicherheit konfigurieren und die Sicherheitskonfiguration nicht wie erwartet generiert wird, prüfen Sie die Endpunktrichtlinien in Ihrer Bereitstellung.
Cloud Service Mesh unterstützt keine Szenarien mit zwei oder mehr Endpunkten Richtlinienressourcen, die zu gleichen Teilen einem Endpunkt entsprechen, z. B. zwei Richtlinien mit denselben Labels und Ports oder zwei oder mehr Richtlinien mit unterschiedlichen Labels, die gleichermaßen mit den Labels eines Endpunkts übereinstimmen. Weitere Informationen zum Abgleichen von Endpunktrichtlinien mit den Labels eines Endpunkts finden Sie unter APIs für EndpointPolicy.EndpointMatcher.MetadataLabelMatcher. In solchen Situationen generiert Cloud Service Mesh keine Sicherheitskonfiguration. Richtlinienkonflikten entfernt werden.
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 zwischen allen 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 Systemstatus, um Traffic an den
nächsten fehlerfreien Back-End. Wenn einige Ihrer Back-Ends fehlerhaft sind, kann der Traffic
verarbeitet werden, jedoch mit suboptimaler Verteilung. Zum Beispiel
an eine Region fließen, in der noch fehlerfreie Back-Ends vorhanden sind, die jedoch
viel weiter vom Client entfernt ist. Das führt zu Latenz. Zur Identifizierung und Überwachung
des Systemstatus Ihrer Back-Ends führen Sie die folgenden Schritte aus:
- 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 zur Funktionsweise von Cloud Service Mesh finden Sie in der Übersicht über Cloud Service Mesh.
- Informationen zur Funktionsweise von Cloud Service Mesh mit proxylosen gRPC-Diensten finden Sie unter Cloud Service Mesh mit proxylosen gRPC-Diensten – Übersicht.
- Allgemeine Informationen zur Fehlerbehebung in Cloud Service Mesh finden Sie unter Fehlerbehebung bei Bereitstellungen, die Envoy verwenden.
- Weitere Unterstützung zur Verwendung von Cloud Service Mesh finden Sie unter Support erhalten.