Fehlerbehebung bei proxylosen gRPC-Bereitstellungen
Dieses Dokument enthält Informationen zur Behebung von Konfigurationsproblemen. wenn Sie proxylose gRPC-Dienste mit Cloud Service Mesh bereitstellen. 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.
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. Wenn Sie das Logging speziell für xDS-Module aktivieren möchten, aktivieren Sie die folgenden Tracer. Verwenden Sie dazu die 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.
- Aktivieren Sie das Dienstkonto für den Zugriff auf die Traffic Director API. Prüfen Sie unter Google Cloud Console APIs und -Dienste für Ihr Projekt auf Fehler für die Traffic Director API.
- 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, bei denen zwei oder mehr Endpunktrichtlinienressourcen vorhanden sind, die mit einem Endpunkt übereinstimmen, z. B. zwei Richtlinien mit den gleichen Labels und Ports oder zwei oder mehr Richtlinien mit unterschiedlichen Labels, die 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 über die in Konflikt stehenden Richtlinien.
Fehlerbehebung für den Zustand Ihres Service Mesh
Dieser Leitfaden enthält Informationen zur Lösung des Cloud Service Mesh Konfigurationsprobleme auftreten.
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 Ressource HealthCheck
die an einen Back-End-Dienst angehängt sind,
um den Status Ihrer Back-Ends zu bewerten.
Cloud Service Mesh verwendet diesen Systemstatus, um Traffic an den
nächsten fehlerfreien Back-End. 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.
Zu den Cloud Service Mesh-Diensten - Achten Sie darauf, dass für die
HealthCheck
-Ressource des Logging aktiviert ist. - Wenn die Systemdiagnosen in letzter Zeit fehlschlagen, prüfen Sie die Cloud-Audit-Logs.
um festzustellen, ob sich die
HealthCheck
-Konfiguration vor Kurzem geändert hat.
Nächste Schritte
- Informationen zur Funktionsweise von Cloud Service Mesh finden Sie in den Cloud Service Mesh – Übersicht
- 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 für Cloud Service Mesh finden Sie unter Fehlerbehebung bei Bereitstellungen, die Envoy verwenden
- Weitere Unterstützung für die Verwendung von Cloud Service Mesh finden Sie unter Support