Cette page a été traduite par l'API Cloud Translation.

Observabilité avec les applications gRPC sans proxy

Ce document fournit des instructions sur l'utilisation des fonctionnalités d'observabilité de gRPC avec des services utilisant Traffic Director. Ces fonctionnalités vous permettent d'accéder à des métriques de surveillance et de traçage qui vous aident à résoudre les problèmes au sein de votre déploiement.

Vous y apprendrez également à exporter les informations vers Cloud Trace et Cloud Monitoring.

Prérequis

Pour créer les exemples du présent document, procédez comme suit :

Configurez Traffic Director avec les VM Compute Engine et les services gRPC sans proxy.
Suivez les instructions de la page Configurer la gestion avancée du trafic avec des services gRPC sans proxy pour déployer l'application de portefeuille gRPC.

Certaines des fonctionnalités d'observabilité nécessitent des paramètres de ligne de commande supplémentaires pour les applications gRPC. Ces paramètres sont décrits dans le présent document. Les caractéristiques et fonctionnalités décrites dans ce document font toutes partie de la bibliothèque gRPC. Vous n'avez pas à effectuer de configuration supplémentaire de Traffic Director.

Métriques et traçage

Les clients et serveurs gRPC sont intégrés à OpenCensus pour exporter les métriques et les traces vers différents backends, y compris Trace et Monitoring. Ce document fournit des exemples dans les langages gRPC suivants :

C++
Go
Java

Les mises en œuvre d'OpenCensus dans d'autres langages peuvent être compatibles avec certaines des fonctionnalités décrites dans ce document, mais nous ne garantissons pas leur fonctionnement. Pour en savoir plus, consultez la documentation OpenCensus.

Lorsque les métriques et le traçage sont activés, les clients et serveurs gRPC exportent les vues, c'est-à-dire des agrégations sur une métrique donnée, qui sont spécifiées dans la spécification des métriques gRPC OpenCensus :

grpc.io/{client,server}/sent_bytes_per_rpc
grpc.io/{client,server}/received_bytes_per_rpc
grpc.io/{client,server}/sent_messages_per_rpc
grpc.io/{client,server}/received_messages_per_rpc
grpc.io/{client,server}/started_rpcs
grpc.io/client/roundtrip_latency
grpc.io/server/server_latency

Activer les API Cloud Monitoring et Cloud Trace

L'intégration OpenCensus de gRPC accepte un large éventail de backends pour l'exportation de métriques et de traces. Les exemples suivants montrent comment exporter ces informations vers Monitoring et Trace. Ces éléments sont désignés collectivement sous l'intitulé stackdriver dans les dépendances figurant ailleurs dans le présent document.

Pour que ces exemples fonctionnent et que vous puissiez visualiser les métriques et les traces sur la console Google Cloud de votre projet, suivez les instructions d'activation de l'API Monitoring et de l'API Cloud Trace.

Instrumenter des applications gRPC

L'exemple de code de portefeuille gRPC est déjà instrumenté pour les métriques et le traçage. Pour activer les métriques et le traçage, exécutez le client et les serveurs gRPC avec l'option de ligne de commande suivante :

 --gcp_client_project=PROJECT_ID

Remplacez PROJECT_ID par l'ID de votre projet. Si vous utilisez l'option create_service.sh script du dépôt de l'exemple de portefeuille gRPC, comme indiqué dans la section Configurer la gestion avancée du trafic avec des services gRPC sans proxy, ajoutez cette option comme dernier argument fourni au script shell.

Exemple :

./create_service.sh go stats 50052 stats \
    --account_server="xds:///account.grpcwallet.io" \
    --gcp_client_project=PROJECT_ID'

Les modifications de code requises pour ajouter une instrumentation à une application gRPC existante sont les suivantes. Une bonne pratique dans vos propres applications consiste à gérer le code d'instrumentation derrière une option de ligne de commande ou une variable d'environnement, ce qui permet aux déploiements gRPC sans proxy de choisir de manière dynamique d'activer ou de désactiver des métriques et le traçage sans nécessiter de modifications supplémentaires du code.

L'exemple de code montre comment configurer simultanément les métriques et le traçage. Vous pouvez également les configurer séparément ou utiliser l'une de ces options seulement. Le code montre comment les configurer ensemble, car les étapes respectives sont semblables.

C++

Le plug-in gRPC C++ pour OpenCensus nécessite la compilation avec Bazel. Vous devez modifier deux fichiers de build pour inclure les dépendances OpenCensus.

Ajoutez le code ci-dessous à votre fichier WORKSPACE :

load("@com_google_googleapis//:repository_rules.bzl", "switched_rules_by_language")

http_archive(
    name = "com_google_googleapis",
    sha256 = "150be57ff83646e5652e03683c949f0830d9a0e73ef787786864210e45537fe0",
    strip_prefix = "googleapis-6e3b55e26bf5a9f7874b6ba1411a0cc50cb87a48",
   urls =       ["https://github.com/googleapis/googleapis/archive/6e3b55e26bf5a9f7874b6ba1411a0cc50cb87a48.zip"],
)

switched_rules_by_language(
    name = "com_google_googleapis_imports",
    cc = True,
    grpc = True,
)

Ajoutez les dépendances suivantes à la cible de compilation dans le fichier BUILD :

cc_binary(
   name = "client",
   srcs = ["client.cc"],
   defines = ["BAZEL_BUILD"],
   deps = [
       # New dependencies:
       "@com_github_grpc_grpc//:grpc_opencensus_plugin",
       "@io_opencensus_cpp//opencensus/trace:trace",
       "@io_opencensus_cpp//opencensus/stats:stats",
       "@io_opencensus_cpp//opencensus/exporters/trace/stackdriver:stackdriver_exporter",
       "@io_opencensus_cpp//opencensus/exporters/stats/stackdriver:stackdriver_exporter",
   ],
)

Instrumentez votre application C++. Les clients et les serveurs sont tous instrumentés de manière globale dans le processus, comme suit :

#include <grpcpp/opencensus.h>
#include "opencensus/exporters/stats/stackdriver/stackdriver_exporter.h"
#include "opencensus/exporters/trace/stackdriver/stackdriver_exporter.h"

ABSL_FLAG(std::string, gcp_client_project, "", "Google Cloud project for metric/trace uploads");

int main(int argc, char** argv) {
  // Optionally configure OpenCensus before using gRPC
  if (!absl::GetFlag(FLAGS_gcp_client_project).empty()) {
    grpc::RegisterOpenCensusPlugin();
    grpc::RegisterOpenCensusViewsForExport();
    // For demo purposes, always sample (probability=1.0)
    opencensus::trace::TraceConfig::SetCurrentTraceParams(
        {128, 128, 128, 128, opencensus::trace::ProbabilitySampler(1.0)});
    opencensus::exporters::trace::StackdriverOptions trace_opts;
    trace_opts.project_id = absl::GetFlag(FLAGS_gcp_client_project);
    opencensus::exporters::trace::StackdriverExporter::Register(std::move(trace_opts));
    opencensus::exporters::stats::StackdriverOptions stats_opts;
    stats_opts.project_id = absl::GetFlag(FLAGS_gcp_client_project);
    // This must be unique among all processes exporting to Stackdriver
    stats_opts.opencensus_task = "wallet-server-" + std::to_string(getpid());
    opencensus::exporters::stats::StackdriverExporter::Register(std::move(stats_opts));
  }

  // Now use gRPC as usual.
}

Go

Pour Go, procédez comme suit :

Instrumentez un client à l'aide d'un ClientHandler :

import (
  "go.opencensus.io/plugin/ocgrpc"
  "go.opencensus.io/stats/view"
  "go.opencensus.io/trace"
  "contrib.go.opencensus.io/exporter/stackdriver"
)

if gcpClientProject != "" {
    view.Register(ocgrpc.DefaultClientViews...)
    sd, err := stackdriver.NewExporter(stackdriver.Options{
        ProjectID:    gcpClientProject,
    })
    defer sd.Flush()
    trace.RegisterExporter(sd)
    sd.StartMetricsExporter()
    defer sd.StopMetricsExporter()
    trace.ApplyConfig(trace.Config{DefaultSampler: trace.AlwaysSample()})

    channel, err := grpc.Dial(serverAddr, grpc.WithInsecure(),
       grpc.WithStatsHandler(new(ocgrpc.ClientHandler)))
}

Instrumentez un serveur à l'aide d'un ServerHandler :

import (
  "go.opencensus.io/plugin/ocgrpc"
  "go.opencensus.io/stats/view"
  "go.opencensus.io/trace"
  "contrib.go.opencensus.io/exporter/stackdriver"
)

if gcpClientProject != "" {
    view.Register(ocgrpc.DefaultServerViews...)
    sd, err := stackdriver.NewExporter(stackdriver.Options{
        ProjectID:    gcpClientProject,
    })
    defer sd.Flush()
    trace.RegisterExporter(sd)
    sd.StartMetricsExporter()
    defer sd.StopMetricsExporter()
    trace.ApplyConfig(trace.Config{DefaultSampler: trace.AlwaysSample()})

    srv := grpc.NewServer(grpc.StatsHandler(&ocgrpc.ServerHandler{}))
}

Java

Pour Java, ajoutez les dépendances suivantes à votre fichier build.gradle :

def opencensusVersion = "0.28.0"
def grpcVersion = "1.35.0"

dependencies {
  // New dependencies:
  compile "io.grpc:grpc-census:{$grpcVersion}",
               "io.opencensus:opencensus-api:${opencensusVersion}",
               "io.opencensus:opencensus-contrib-grpc-metrics:${opencensusVersion}",
               "io.opencensus:opencensus-exporter-stats-stackdriver:${opencensusVersion}",
               "io.opencensus:opencensus-exporter-trace-stackdriver:${opencensusVersion}"
 runtime "io.opencensus:opencensus-impl:${opencensusVersion}"
}

Pour les clients et les serveurs Java, l'ajout de la dépendance sur io.grpc:grpc-census ajoute automatiquement l'instrumentation des métriques et du traçage à vos RPC. Cependant, vous devez spécifier un exportateur OpenCensus pour obtenir des données :

import io.opencensus.contrib.grpc.metrics.RpcViews;
import io.opencensus.exporter.stats.stackdriver.StackdriverStatsConfiguration;
import io.opencensus.exporter.stats.stackdriver.StackdriverStatsExporter;
import io.opencensus.exporter.trace.stackdriver.StackdriverTraceConfiguration;
import io.opencensus.exporter.trace.stackdriver.StackdriverTraceExporter;
import io.opencensus.trace.Tracing;
import io.opencensus.trace.config.TraceConfig;
import io.opencensus.trace.samplers.Samplers;

if (gcpClientProject != "") {
  // Configure export to Monitoring and Trace
  RpcViews.registerAllViews();
  TraceConfig traceConfig = Tracing.getTraceConfig();
  traceConfig.updateActiveTraceParams(
      traceConfig.getActiveTraceParams().toBuilder()
          .setSampler(Samplers.alwaysSample())
          .build());

  StackdriverStatsExporter.createAndRegister(
      StackdriverStatsConfiguration.builder().setProjectId(gcpClientProject).build());
  StackdriverTraceExporter.createAndRegister(
      StackdriverTraceConfiguration.builder().setProjectId(gcpClientProject).build());
}

Afficher les métriques sur le tableau de bord Monitoring

Une fois vos applications instrumentées, les métriques gRPC sont exportées vers Monitoring et consultables dans l'explorateur de métriques de la console Google Cloud.

Console

Pour afficher les métriques, procédez comme suit :

Dans Google Cloud Console, accédez à la page Monitoring.

Accéder à Monitoring
Dans le volet de navigation de gauche, cliquez sur Explorateur de métriques.
Sous Créer votre requête, choisissez comme type de ressource Instance de VM ou Conteneur GKE.
Dans le champ Métrique, choisissez l'un des noms de métriques répertoriés dans Métriques et traçage tels que OpenCensus/grpc.io/client/roundtrip_latency.
Dans la liste déroulante Agrégateur, sélectionnez comme type Moyenne. Un graphique semblable au suivant s'affiche :

Explorateur de métriques (cliquez pour agrandir)

En plus des vues détaillées standards de Monitoring, telles que le filtrage pour afficher uniquement les statistiques d'un groupe d'instances spécifique, vous pouvez ventiler les statistiques par grpc_client_method ou grpc_server_method, car chaque métrique envoyée par OpenCensus est annotée avec le nom de la méthode gRPC correspondante.

Vous pouvez intégrer ces vues de métriques dans des tableaux de bord et graphiques Monitoring, et vous pouvez les utiliser comme base pour les alertes automatisées.

Afficher les traces sur Trace

Une fois le processus de configuration terminé, vos serveurs et clients gRPC instrumentés envoient des traces à Trace. La page Présentation de Trace de la console Google Cloud affiche une liste des traces récentes. Vous pouvez sélectionner une trace individuelle pour afficher une répartition de votre trafic, conformément à ce qui est décrit dans la section suivante.

Compatibilité de Trace avec le proxy Envoy

L'exportation de traces vers Trace avec Traffic Director et le proxy Envoy, comme décrit dans la section Observabilité avec Envoy, utilise la configuration du traceur OpenCensus d'Envoy, ce qui permet aux traces exportées à partir d'applications gRPC sans proxy et de proxys Envoy d'être totalement compatibles au sein d'un maillage de services. Pour assurer la compatibilité avec gRPC sans proxy, l'amorçage d'Envoy doit configurer le contexte de trace afin d'inclure le format de trace GRPC_TRACE_BIN dans son fichier OpenCensusConfig. Exemple :

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"]

Exposer l'interface d'administration

Parfois, les métriques et les données de traçage ne sont pas suffisantes pour résoudre un problème. Vous devrez peut-être examiner la configuration ou l'état d'exécution de la bibliothèque gRPC dans votre application. Ces informations incluent les informations sur le résolveur, l'état de la connectivité aux pairs, les statistiques RPC sur un canal et la configuration reçue de Traffic Director.

Pour obtenir ces informations, les applications gRPC peuvent exposer l'interface d'administration sur un port particulier. Vous pouvez ensuite interroger l'application pour comprendre la configuration des services et leur exécution. Dans cette section, vous trouverez des instructions sur la configuration de l'interface d'administration pour les applications écrites dans chacun des langages compatibles.

Dans votre application, nous vous recommandons de créer un serveur gRPC distinct qui écoute sur un port réservé à cette fin. Cela vous permet d'accéder à vos applications gRPC même lorsque les ports de données sont inaccessibles en raison d'un problème de configuration ou de problèmes de réseau. Nous vous recommandons d'exposer l'interface d'administration uniquement sur localhost ou sur un socket de domaine Unix.

Les extraits de code suivants montrent comment créer une interface d'administration.

C++

En C++, utilisez le code suivant pour créer une interface d'administration :

#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());

Go

En Go, utilisez le code suivant pour créer une interface d'administration :

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

En Java, utilisez le code suivant pour créer une interface d'administration :

import io.grpc.services.AdminInterface;

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

Python

En Python, utilisez le code suivant pour créer une interface d'administration :

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()

Se connecter à une VM via SSH

L'exemple de portefeuille gRPC active déjà l'interface d'administration. Vous pouvez modifier le port de l'interface d'administration en fournissant l'option :

 --admin-port=PORT

Le port d'administration par défaut est localhost:28881.

Pour déboguer votre application gRPC, vous pouvez utiliser SSH pour vous connecter à l'une des VM qui diffuse le wallet-service. Vous pouvez ainsi accéder à 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

Installez l'outil `grpcdebug`

Pour accéder à l'interface d'administration, vous avez besoin d'un client gRPC capable de communiquer avec les services d'administration de l'application gRPC. Dans les exemples suivants, vous utilisez un outil nommé grpcdebug, que vous pouvez télécharger et installer sur la VM ou sur le pod exécutant votre application gRPC. Le dépôt de grpcdebug se trouve à l'emplacement grpc-ecosystem/grpcdebug.

La version minimale compatible de Golang est la version 1.12. Le guide d'installation officiel de Golang est disponible sur le site de Golang. Si vous suivez le guide de création d'une VM Linux pour wallet-service, vous pouvez installer Golang 1.16 à l'aide des commandes suivantes :

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

Pour installer l'outil grpcdebug, exécutez les commandes suivantes :

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

Vous avez maintenant accès à l'interface de ligne de commande grpcdebug. L'aide contient des informations sur les commandes compatibles :

$ 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

Pour obtenir plus d'informations sur une commande particulière, utilisez la commande suivante :

 grpcdebug <target address> [command] --help

Utiliser l'outil `grpcdebug` pour déboguer vos applications

Vous pouvez utiliser l'outil grpcdebug pour déboguer vos applications. L'outil grpcdebug fournit une configuration de type ssh_config compatible avec l'utilisation d'alias, la réécriture du nom d'hôte et le réglage de la sécurité des connexions (non sécurisé/TLS). Pour en savoir plus sur cette fonctionnalité avancée, consultez la section grpcdebug/Connect&Security.

Les sections suivantes décrivent les services exposés par l'interface d'administration et expliquent comment y accéder.

Utiliser Channelz

Le service Channelz donne accès à des informations d'exécution concernant les connexions à différents niveaux de la bibliothèque gRPC de votre application. Vous pouvez l'utiliser pour une analyse en direct des applications présentant des problèmes liés à la configuration ou au réseau. Les exemples suivants supposent que vous avez déployé l'exemple de portefeuille gRPC en suivant les instructions de la section Configurer la gestion avancée du trafic avec des services gRPC sans proxy et en utilisant l'option suivante :

 --admin-port=PORT

Une fois que vous avez envoyé quelques RPC à partir d'un client de test, comme indiqué dans la section Vérifier la configuration, utilisez les commandes suivantes pour accéder aux données Channelz pour les services gRPC :

Utilisez SSH pour vous connecter à une VM qui exécute wallet-service.
Configurez grpcdebug pour vous connecter à l'application gRPC en cours d'exécution.

La sortie par défaut de grpcdebug est dans un format de table compatible avec la console. Si vous spécifiez l'option --json, le résultat est encodé au format JSON.

La commande grpcdebug channelz permet de récupérer et de présenter les informations de débogage provenant du service Channelz. La commande fonctionne à la fois pour les clients gRPC et les serveurs gRPC.

Pour les clients gRPC, la commande grpcdebug channelz channels fournit une liste des canaux existants ainsi que des informations de base :

$ 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

Si vous avez besoin d'informations supplémentaires concernant un canal particulier, vous pouvez utiliser grpcdebug channelz channel [CHANNEL_ID] pour inspecter les informations détaillées relatives à ce canal. L'identifiant de canal peut être l'ID de canal ou l'adresse cible, s'il n'existe qu'une seule adresse cible. Un canal gRPC peut contenir plusieurs sous-canaux, ce qui représente l'abstraction de gRPC par-dessus une connexion TCP.

$ 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

Vous pouvez également consulter les informations détaillées d'un sous-canal :

$ 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

Vous pouvez récupérer des informations sur les sockets TCP :

$ 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

Du côté serveur, vous pouvez utiliser Channelz pour inspecter l'état de votre application serveur. Par exemple, vous pouvez obtenir la liste des serveurs à l'aide de la commande grpcdebug channelz servers :

$ 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

Pour obtenir plus d'informations sur un serveur spécifique, utilisez la commande grpcdebug channelz server. Vous pouvez inspecter les sockets serveur de la même manière que vous inspectez les sockets client.

$ 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

Utiliser le Client Status Discovery Service

L'API Client Status Discovery Service (CSDS) fait partie des API xDS. Dans une application gRPC, le service CSDS fournit l'accès à la configuration (également appelée configuration xDS) qu'il reçoit de Traffic Director. Cela vous permet d'identifier et de résoudre les problèmes liés à la configuration de votre maillage.

Dans les exemples suivants, nous partons du principe que vous avez déployé l'exemple de portefeuille gRPC en suivant les instructions de la section Configurer la gestion avancée du trafic avec des services gRPC sans proxy.

Pour examiner la configuration à l'aide de CSDS, procédez comme suit :

Utilisez SSH pour vous connecter à une VM qui exécute wallet-service. Suivez les instructions de la section Se connecter à une VM via SSH.
Exécutez le client grpcdebug.

Pour obtenir une vue d'ensemble de l'état de la configuration, exécutez la commande suivante :

grpcdebug localhost:28881 xds status

Un résultat semblable aux lignes suivantes doit s'afficher :

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

Vous pouvez trouver la définition de l'état de la configuration dans la documentation du proxy Envoy. En bref, l'état d'une ressource xDS est décrit par l'un des éléments suivants : REQUESTED, DOES_NOT_EXIST, ACKED ou NACKED.

Pour obtenir un vidage de configuration xDS brut, exécutez la commande suivante :

grpcdebug localhost:28881 xds config

Vous obtenez un listing JSON de l'objet 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":  [
              {
...

Si la sortie de la configuration brute est trop détaillée, grpcdebug vous permet de filtrer en fonction de types xDS spécifiques. Exemple :

$ 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",
...

Vous pouvez également obtenir le vidage de plusieurs types xDS à la fois :

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

Étapes suivantes

Pour obtenir des informations associées, consultez la page Observabilité avec Envoy.
Pour résoudre les problèmes de configuration lorsque vous déployez des services gRPC sans proxy, consultez la page Résoudre les problèmes de déploiement qui utilisent gRPC sans proxy.

Observabilité avec les applications gRPC sans proxy

Prérequis

Métriques et traçage

Activer les API Cloud Monitoring et Cloud Trace

Instrumenter des applications gRPC

C++

Go

Java

Afficher les métriques sur le tableau de bord Monitoring

Console

Afficher les traces sur Trace

Compatibilité de Trace avec le proxy Envoy

Exposer l'interface d'administration

C++

Go

Java

Python

Se connecter à une VM via SSH

Installez l'outil grpcdebug

Utiliser l'outil grpcdebug pour déboguer vos applications

Utiliser Channelz

Utiliser le Client Status Discovery Service

Étapes suivantes

Installez l'outil `grpcdebug`

Utiliser l'outil `grpcdebug` pour déboguer vos applications