Beobachtbarkeit mit proxylosen gRPC-Anwendungen

Mit Beobachtbarkeitstools für Mikrodienste können Sie Ihre Anwendungen instrumentieren, um Telemetriedaten in Cloud Monitoring, Cloud Logging und Cloud Trace aus gRPC-Arbeitslasten, die in Google Cloud bereitgestellt werden, zu erfassen und darzustellen, einschließlich gRPC-Arbeitslasten in Traffic Director.

gRPC-Clients und -Server sind in OpenCensus eingebunden, um Messwerte und Traces in verschiedene Back-Ends, einschließlich Trace und Monitoring, zu exportieren. Sie können dies mit den folgenden gRPC-Sprachen tun:

  • C++
  • Einfach loslegen (Go)
  • Java

Lesen Sie die Beobachtbarkeit von Mikrodiensten und folgen Sie dann der Anleitung unter Beobachtbarkeit von Mikrodiensten einrichten, um Ihre gRPC-Arbeitslasten für Folgendes zu instrumentieren:

Verwenden Sie die Anweisungen in diesem Dokument für die folgenden Aufgaben:

Traces in Trace ansehen

Nach Abschluss der Einrichtung senden Ihre instrumentierten gRPC-Clients und -Server Traces an Trace. Auf der Seite Trace-Übersicht in der Google Cloud Console finden Sie eine Liste der letzten Traces. Sie können einen einzelnen Trace auswählen, um eine Aufschlüsselung Ihres Traffics anzeigen zu lassen, wie im folgenden Abschnitt beschrieben.

Trace-Kompatibilität mit dem Envoy-Proxy

Das Exportieren von Traces nach Trace mit Traffic Director und dem Envoy-Proxy, wie in Beobachtbarkeit mit Envoy beschrieben, nutzt die OpenCensus-Tracer-Konfiguration von Envoy, mit der Traces, die aus proxylosen gRPC-Anwendungen und Envoy-Proxys exportiert wurden, in einem Service Mesh vollständig kompatibel sein können. Für die Kompatibilität mit dem proxylosen gRPC muss der Envoy-Bootstrap den Trace-Kontext so konfigurieren, dass das Trace-Format GRPC_TRACE_BIN in der Datei OpenCensusConfig enthalten ist. Beispiel:

tracing:
  http:
      name: envoy.tracers.opencensus
      typed_config:
        "@type": type.googleapis.com/envoy.config.trace.v2.OpenCensusConfig
        stackdriver_exporter_enabled: "true"
        stackdriver_project_id: "PROJECT_ID"
        incoming_trace_context: ["CLOUD_TRACE_CONTEXT", "GRPC_TRACE_BIN"]
        outgoing_trace_context: ["CLOUD_TRACE_CONTEXT", "GRPC_TRACE_BIN"]

Administratoroberfläche einblenden

Manchmal sind Messwerte und Tracing-Daten nicht ausreichend, um ein Problem zu beheben. Möglicherweise müssen Sie sich die Konfiguration oder den Laufzeitstatus der gRPC-Bibliothek in Ihrer Anwendung ansehen. Diese Informationen enthalten Resolver-Informationen, den Status der Konnektivität zu Peers, RPC-Statistiken für einen Kanal und die von Traffic Director empfangene Konfiguration.

Für gRPC-Anwendungen kann die Admin-Schnittstelle von einem bestimmten Port aus bereitgestellt werden. Anschließend können Sie die Anwendung abfragen, um zu verstehen, wie die Dienste konfiguriert sind und wie sie ausgeführt werden. In diesem Abschnitt finden Sie Anleitungen zum Konfigurieren der Admin-Schnittstelle für Anwendungen, die in den unterstützten Sprachen geschrieben sind.

Wir empfehlen Ihnen, in Ihrer Anwendung einen separaten gRPC-Server zu erstellen, der einen für diesen Zweck reservierten Port überwacht. Auf diese Weise können Sie auch dann auf Ihre gRPC-Anwendungen zugreifen, wenn die Datenports aufgrund von Fehlkonfigurationen oder Netzwerkproblemen nicht zugänglich sind. Wir empfehlen, die Admin-Schnittstelle nur auf localhost oder auf einem Unix-Domain-Socket verfügbar zu machen.

Die folgenden Code-Snippets zeigen, wie eine Admin-Schnittstelle erstellt wird.

C++

Verwenden Sie in C++ den folgenden Code, um eine Admin-Schnittstelle zu erstellen:

#include <grpcpp/ext/admin_services.h>

grpc::ServerBuilder builder;
grpc::AddAdminServices(&builder);
builder.AddListeningPort(":50051", grpc::ServerCredentials(...));
std::unique_ptr<grpc::Server> server(builder.BuildAndStart());

Einfach loslegen (Go)

Verwenden Sie in Go diesen Code, um eine Admin-Schnittstelle zu erstellen:

import "google.golang.org/grpc/admin"

lis, err := net.Listen("tcp", ":50051")
if err != nil {
        log.Fatalf("failed to listen: %v", err)
}
defer lis.Close()
grpcServer := grpc.NewServer(...opts)
cleanup, err := admin.Register(grpcServer)
if err != nil {
        log.Fatalf("failed to register admin services: %v", err)
}
defer cleanup()

if err := grpcServer.Serve(lis); err != nil {
        log.Fatalf("failed to serve: %v", err)
}

Java

Verwenden Sie in Java diesen Code, um eine Admin-Schnittstelle zu erstellen:

import io.grpc.services.AdminInterface;

server = ServerBuilder.forPort(50051)
        .useTransportSecurity(certChainFile, privateKeyFile)
        .addServices(AdminInterface.getStandardServices())
        .build()
        .start();
server.awaitTermination();

Python

Verwenden Sie in Python den folgenden Code, um eine Admin-Schnittstelle zu erstellen:

import grpc_admin

server = grpc.server(futures.ThreadPoolExecutor())
grpc_admin.add_admin_servicers(server)
server.add_insecure_port('[::]:50051')
server.start()
server.wait_for_termination()

SSH-Verbindung zu einer VM herstellen

Im Beispiel für gRPC Wallet wird bereits die Administratorschnittstelle aktiviert. Sie können den Port der Admin-Schnittstelle ändern, indem Sie folgendes Flag angeben.

 --admin-port=PORT

Der Standard-Admin-Port ist localhost:28881.

Zum Debuggen Ihrer gRPC-Anwendung können Sie eine SSH-Verbindung zu einer der VMs herstellen, die den wallet-service bereitstellt. Dadurch erhalten Sie Zugriff auf den localhost.

# List the Wallet VMs
$ gcloud compute instances list --filter="zone:(us-central1-a)" --filter="name~'grpcwallet-wallet-v2'"
NAME                                       ZONE            MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP    EXTERNAL_IP     STATUS
grpcwallet-wallet-v2-mig-us-central1-ccl1  us-central1-a   n1-standard-1               10.240.0.38    35.223.42.98    RUNNING
grpcwallet-wallet-v2-mig-us-central1-k623  us-central1-a   n1-standard-1               10.240.0.112   35.188.133.75   RUNNING
# Pick one of the Wallet VMs to debug
$ gcloud compute ssh grpcwallet-wallet-v2-mig-us-central1-ccl1 --zone=us-central1-a

Installieren Sie das grpcdebug-Tool.

Für den Zugriff auf die Admin-Schnittstelle benötigen Sie einen gRPC-Client, der mit den Admin-Diensten in Ihrer gRPC-Anwendung kommunizieren kann. In den folgenden Beispielen verwenden Sie ein Tool namens grpcdebug, das Sie auf der VM oder dem Pod herunterladen und installieren können, auf dem Ihre gRPC-Anwendung ausgeführt wird. Das Repository für grpcdebug befindet sich unter grpc-ecosystem/grpcdebug.

Die Golang-Version für minimale Unterstützung ist 1.12. Das offizielle Installationshandbuch für Golang finden Sie auf der Golang-Website. Wenn Sie den Leitfaden zum Erstellen einer Linux-VM für wallet-service befolgen, können Sie Golang 1.16 mit diesen Befehlen installieren:

sudo apt update && sudo apt install -y wget
wget https://golang.org/dl/go1.16.3.linux-amd64.tar.gz
sudo rm -rf /usr/local/go
sudo tar -C /usr/local -xzf go1.16.3.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin
sudo ln -sf /usr/local/go/bin/go /usr/bin/go
go version
# go version go1.16.3 linux/amd64

Sie installieren das grpcdebug-Tool mit den folgenden Befehlen:

go install -v github.com/grpc-ecosystem/grpcdebug@latest
export PATH=$PATH:$(go env GOPATH)/bin

Sie haben jetzt Zugriff auf die grpcdebug-Befehlszeile. Die Hilfeausgabe enthält Informationen zu unterstützten Befehlen:

$ grpcdebug -h
grpcdebug is a gRPC service admin command-line interface

Usage:
  grpcdebug <target address> [flags]  <command>

Available Commands:
  channelz    Display gRPC states in human readable way.
  health      Check health status of the target service (default "").
  help        Help about any command
  xds         Fetch xDS related information.

Flags:
      --credential_file string        Sets the path of the credential file; used in [tls] mode
  -h, --help                          Help for grpcdebug
      --security string               Defines the type of credentials to use [tls, google-default, insecure] (default "insecure")
      --server_name_override string   Overrides the peer server name if non empty; used in [tls] mode
  -t, --timestamp                     Print timestamp as RFC 3339 instead of human readable strings
  -v, --verbose                       Print verbose information for debugging

Verwenden Sie folgenden Code, um weitere Informationen zu einem bestimmten Befehl abzurufen:

 grpcdebug <target address> [command] --help

grpcdebug-Tool zum Debuggen von Anwendungen verwenden

Mit dem grpcdebug-Tool können Sie Fehler in Ihren Anwendungen beheben. Das grpcdebug-Tool bietet eine ssh_config-ähnliche Konfiguration, die Aliasing, Hostname-Umschreibungen und Sicherheitseinstellung für die Verbindung (unsicher/TLS) unterstützt. Weitere Informationen zu diesem erweiterten Feature finden Sie unter grpcdebug/Connect&Security.

In den folgenden Abschnitten werden die von der Admin-Schnittstelle bereitgestellten Dienste und deren Zugriff beschrieben.

Channelz verwenden

Der Channelz-Dienst bietet Zugriff auf Laufzeitinformationen zu den Verbindungen auf verschiedenen Ebenen in der gRPC-Bibliothek Ihrer Anwendung. Sie können dies für die Live-Analyse von Anwendungen nutzen, bei denen möglicherweise Probleme mit der Konfiguration oder dem Netzwerk auftreten. In den folgenden Beispielen wird davon ausgegangen, dass Sie das gRPC IAP-Beispiel mithilfe der Anleitung unter Erweiterte Trafficverwaltung mit proxylosen gRPC-Diensten konfigurieren bereitgestellt und das folgende Flag angegeben haben:

 --admin-port=PORT

Nachdem Sie einige RPCs von einem Testclient gesendet haben, wie unter Konfiguration prüfen gezeigt, verwenden Sie die folgenden Befehle, um auf die Channelz-Daten für gRPC-Dienste zuzugreifen.

  1. Stellen Sie mit SSH eine Verbindung zu einer VM her, auf der wallet-service ausgeführt wird.
  2. Richten Sie grpcdebug ein, um eine Verbindung zur ausgeführten gRPC-Anwendung herzustellen.

Die Standardausgabe von grpcdebug hat ein für die Konsole optimiertes Tabellenformat. Wenn Sie das Flag --json angeben, wird die Ausgabe als JSON codiert.

Mit dem Befehl grpcdebug channelz werden Debugging-Informationen vom Channelz-Dienst abgerufen und präsentiert. Der Befehl funktioniert sowohl für gRPC-Clients als auch für gRPC-Server.

Für gRPC-Clients gibt der Befehl grpcdebug channelz channels eine Liste der vorhandenen Kanäle sowie einige grundlegende Informationen an.

$ grpcdebug localhost:28881 channelz channels
Channel ID   Target                               State     Calls(Started/Succeeded/Failed)   Created Time
1            xds:///account.grpcwallet.io:10080   READY     0/0/0                             59 seconds ago
2            trafficdirector.googleapis.com:443   READY     2/0/0                             59 seconds ago
4            xds:///stats.grpcwallet.io:10080     READY     0/0/0                             59 seconds ago

Wenn Sie weitere Informationen zu einem bestimmten Kanal benötigen, können Sie mit grpcdebug channelz channel [CHANNEL_ID] detaillierte Informationen für diesen Kanal einsehen. Die Kanalkennung kann die Kanal-ID oder die Zieladresse sein, wenn nur eine einzige Zieladresse vorhanden ist. Ein gRPC-Kanal kann mehrere Subkanäle enthalten. Dies ist eine Abstraktion von gRPC für eine TCP-Verbindung.

$ grpcdebug localhost:28881 channelz channel 2
Channel ID:        2
Target:            trafficdirector.googleapis.com:443
State:             READY
Calls Started:     2
Calls Succeeded:   0
Calls Failed:      0
Created Time:      10 minutes ago
---
Subchannel ID   Target                               State     Calls(Started/Succeeded/Failed)   CreatedTime
3               trafficdirector.googleapis.com:443   READY     2/0/0                             10 minutes ago
---
Severity   Time             Child Ref                      Description
CT_INFO    10 minutes ago                                  Channel Created
CT_INFO    10 minutes ago                                  parsed scheme: ""
CT_INFO    10 minutes ago                                  scheme "" not registered, fallback to default scheme
CT_INFO    10 minutes ago                                  ccResolverWrapper: sending update to cc: {[{trafficdirector.googleapis.com:443  <nil> 0 <nil>}] <nil> <nil>}
CT_INFO    10 minutes ago                                  Resolver state updated: {Addresses:[{Addr:trafficdirector.googleapis.com:443 ServerName: Attributes:<nil> Type:0 Metadata:<nil>}] ServiceConfig:<nil> Attributes:<nil>} (resolver returned new addresses)
CT_INFO    10 minutes ago                                  ClientConn switching balancer to "pick_first"
CT_INFO    10 minutes ago                                  Channel switches to new LB policy "pick_first"
CT_INFO    10 minutes ago   subchannel(subchannel_id:3 )   Subchannel(id:3) created
CT_INFO    10 minutes ago                                  Channel Connectivity change to CONNECTING
CT_INFO    10 minutes ago                                  Channel Connectivity change to READY

Sie können sich auch detaillierte Informationen zu einem Subkanal ansehen:

$ grpcdebug localhost:28881 channelz subchannel 3
Subchannel ID:     3
Target:            trafficdirector.googleapis.com:443
State:             READY
Calls Started:     2
Calls Succeeded:   0
Calls Failed:      0
Created Time:      12 minutes ago
---
Socket ID   Local->Remote                           Streams(Started/Succeeded/Failed)   Messages(Sent/Received)
9           10.240.0.38:60338->142.250.125.95:443   2/0/0                               214/132

Sie können Informationen zu TCP-Sockets abrufen.

$ grpcdebug localhost:28881 channelz socket 9
Socket ID:                       9
Address:                         10.240.0.38:60338->142.250.125.95:443
Streams Started:                 2
Streams Succeeded:               0
Streams Failed:                  0
Messages Sent:                   226
Messages Received:               141
Keep Alives Sent:                0
Last Local Stream Created:       12 minutes ago
Last Remote Stream Created:      a long while ago
Last Message Sent Created:       8 seconds ago
Last Message Received Created:   8 seconds ago
Local Flow Control Window:       65535
Remote Flow Control Window:      966515
---
Socket Options Name   Value
SO_LINGER             [type.googleapis.com/grpc.channelz.v1.SocketOptionLinger]:{duration:{}}
SO_RCVTIMEO           [type.googleapis.com/grpc.channelz.v1.SocketOptionTimeout]:{duration:{}}
SO_SNDTIMEO           [type.googleapis.com/grpc.channelz.v1.SocketOptionTimeout]:{duration:{}}
TCP_INFO              [type.googleapis.com/grpc.channelz.v1.SocketOptionTcpInfo]:{tcpi_state:1  tcpi_options:7  tcpi_rto:204000  tcpi_ato:40000  tcpi_snd_mss:1408  tcpi_rcv_mss:1408  tcpi_last_data_sent:8212  tcpi_last_data_recv:8212  tcpi_last_ack_recv:8212  tcpi_pmtu:1460  tcpi_rcv_ssthresh:88288  tcpi_rtt:2400  tcpi_rttvar:3012  tcpi_snd_ssthresh:2147483647  tcpi_snd_cwnd:10  tcpi_advmss:1408  tcpi_reordering:3}
---
Security Model:   TLS
Standard Name:    TLS_AES_128_GCM_SHA256

Auf der Serverseite können Sie mit Channelz den Status Ihrer Serveranwendung prüfen. Sie können beispielsweise die Liste der Server mit dem Befehl grpcdebug channelz servers abrufen:

$ grpcdebug localhost:28881 channelz servers
Server ID   Listen Addresses    Calls(Started/Succeeded/Failed)   Last Call Started
5           [127.0.0.1:28881]   9/8/0                             now
6           [[::]:50051]        159/159/0                         4 seconds ago

Weitere Informationen zu einem bestimmten Server erhalten Sie mit dem Befehl grpcdebug channelz server. Sie können Server-Sockets genauso prüfen wie Client-Sockets.

$ grpcdebug localhost:28881 channelz server 6
Server Id:           6
Listen Addresses:    [[::]:50051]
Calls Started:       174
Calls Succeeded:     174
Calls Failed:        0
Last Call Started:   now
---
Socket ID   Local->Remote                            Streams(Started/Succeeded/Failed)   Messages(Sent/Received)
25          10.240.0.38:50051->130.211.1.39:44904    68/68/0                             68/68
26          10.240.0.38:50051->130.211.0.167:32768   54/54/0                             54/54
27          10.240.0.38:50051->130.211.0.22:32768    52/52/0                             52/52

Client Status Discovery Service verwenden

Die Client Status Discovery Service (CSDS) API ist Teil der xDS APIs. In einer gRPC-Anwendung bietet der CSDS-Dienst Zugriff auf die von Traffic Director erhaltene Konfiguration (auch xDS-Konfiguration genannt). Auf diese Weise können Sie konfigurationsbezogene Probleme in Ihrem Mesh ermitteln und beheben.

In den folgenden Beispielen wird davon ausgegangen, dass Sie das gRPC-Wallet-Beispiel gemäß der Anleitung in Erweiterte Trafficverwaltung mit proxylosen gRPC-Diensten konfigurieren bereitgestellt haben.

So verwenden Sie CSDS, um die Konfiguration zu untersuchen:

  1. Stellen Sie mit SSH eine Verbindung zu einer VM her, auf der wallet-service ausgeführt wird. Folgen Sie der Anleitung unter SSH zum Herstellen einer Verbindung zu einer VM verwenden.
  2. Führen Sie den grpcdebug-Client aus.

Führen Sie den folgenden Befehl aus, um eine Übersicht über den Konfigurationsstatus zu erhalten:

grpcdebug localhost:28881 xds status

Die Ergebnisse sollten in etwa so aussehen:

Name                                                                    Status    Version               Type                                                                 LastUpdated
account.grpcwallet.io:10080                                             ACKED     1618529574783547920   type.googleapis.com/envoy.config.listener.v3.Listener                3 seconds ago
stats.grpcwallet.io:10080                                               ACKED     1618529574783547920   type.googleapis.com/envoy.config.listener.v3.Listener                3 seconds ago
URL_MAP/830293263384_grpcwallet-url-map_0_account.grpcwallet.io:10080   ACKED     1618529574783547920   type.googleapis.com/envoy.config.route.v3.RouteConfiguration         3 seconds ago
URL_MAP/830293263384_grpcwallet-url-map_1_stats.grpcwallet.io:10080     ACKED     1618529574783547920   type.googleapis.com/envoy.config.route.v3.RouteConfiguration         3 seconds ago
cloud-internal-istio:cloud_mp_830293263384_3566964729007423588          ACKED     1618529574783547920   type.googleapis.com/envoy.config.cluster.v3.Cluster                  3 seconds ago
cloud-internal-istio:cloud_mp_830293263384_7383783194368524341          ACKED     1618529574783547920   type.googleapis.com/envoy.config.cluster.v3.Cluster                  3 seconds ago
cloud-internal-istio:cloud_mp_830293263384_3363366193797120473          ACKED     1618529574783547920   type.googleapis.com/envoy.config.cluster.v3.Cluster                  3 seconds ago
cloud-internal-istio:cloud_mp_830293263384_3566964729007423588          ACKED     86                    type.googleapis.com/envoy.config.endpoint.v3.ClusterLoadAssignment   2 seconds ago
cloud-internal-istio:cloud_mp_830293263384_3363366193797120473          ACKED     86                    type.googleapis.com/envoy.config.endpoint.v3.ClusterLoadAssignment   2 seconds ago
cloud-internal-istio:cloud_mp_830293263384_7383783194368524341          ACKED     86                    type.googleapis.com/envoy.config.endpoint.v3.ClusterLoadAssignment   2 seconds ago

Eine Definition des Konfigurationsstatus finden Sie in der Dokumentation für den Envoy-Proxy. Kurz gesagt lautet der Status einer xDS-Ressource REQUESTED, DOES_NOT_EXIST, ACKED oder NACKED.

Führen Sie den folgenden Befehl aus, um einen rohen xDS-Konfigurationsdump abzurufen:

grpcdebug localhost:28881 xds config

Sie sehen eine JSON-Liste des Objekts PerXdsConfig:

{
  "config":  [
    {
      "node":  {
        "id":  "projects/830293263384/networks/default/nodes/6e98b038-6d75-4a4c-8d35-b0c7a8c9cdde",
        "cluster":  "cluster",
        "metadata":  {
          "INSTANCE_IP":  "10.240.0.38",
          "TRAFFICDIRECTOR_GCP_PROJECT_NUMBER":  "830293263384",
          "TRAFFICDIRECTOR_NETWORK_NAME":  "default"
        },
        "locality":  {
          "zone":  "us-central1-a"
        },
        "userAgentName":  "gRPC Go",
        "userAgentVersion":  "1.37.0",
        "clientFeatures":  [
          "envoy.lb.does_not_support_overprovisioning"
        ]
      },
      "xdsConfig":  [
        {
          "listenerConfig":  {
            "versionInfo":  "1618529930989701137",
            "dynamicListeners":  [
              {
...

Wenn die Rohkonfigurationsausgabe zu ausführlich ist, können Sie mit grpcdebug nach bestimmten xDS-Typen filtern. Beispiel:

$ grpcdebug localhost:28881 xds config --type=cds
{
  "versionInfo":  "1618530076226619310",
  "dynamicActiveClusters":  [
    {
      "versionInfo":  "1618530076226619310",
      "cluster":  {
        "@type":  "type.googleapis.com/envoy.config.cluster.v3.Cluster",
        "name":  "cloud-internal-istio:cloud_mp_830293263384_7383783194368524341",
        "altStatName":  "/projects/830293263384/global/backendServices/grpcwallet-stats-service",
        "type":  "EDS",
        "edsClusterConfig":  {
          "edsConfig":  {
            "ads":  {},
            "initialFetchTimeout":  "15s",
...

Sie können auch die Konfiguration mehrerer xDS-Typen gleichzeitig als Dump speichern:

$ grpcdebug localhost:28881 xds config --type=lds,eds
{
  "versionInfo":  "1618530076226619310",
  "dynamicListeners":  [...]
}
{
  "dynamicEndpointConfigs":  [...]
}

Nächste Schritte