Observabilité pour gRPC sans proxy

Preview

Ce produit ou cette fonctionnalité est soumis aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent bénéficier d'une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

L'observabilité du maillage de services Cloud pour gRPC sans proxy s'appuie sur le plug-in OpenTelemetry gRPC existant, enregistre des métriques (latence, taille des messages, etc.) pour tous les canaux et serveurs gRPC compatibles avec le maillage de services Cloud, et fournit des attributs supplémentaires qui affichent des informations de maillage topologique pour le trafic du maillage de services Cloud. Un gRPC est considéré comme activé si Cloud Service Mesh est activé à partir du plan de contrôle Cloud Service Mesh, tandis que tous les services gRPC sont considérés comme étant activés.

Attributs de réseau maillé

Les attributs de maillage suivants sont disponibles pour les métriques.

Étiquettes d'environnement locales:

• csm.mesh_id
  • ID du réseau maillé.
• Les autres attributs d'environnement local sont obtenus via la Ressource OpenTelemetry.
  • Managed Service pour Prometheus (GMP) peuvent être configurés de façon à utiliser l'infrastructure Google pour stocker des métriques. Si vous l'utilisez, des attributs de ressource qui décrivent l'environnement local de l'application automatiquement ajouté en tant que MonitoredResource :
  • Si vous utilisez une infrastructure autre que Google pour exporter et stocker des métriques, le pipeline de collecte doit ajouter des attributs aux métriques qui décrivent l'environnement sur lequel l'application s'exécute.

Libellés d'environnement distants :

• csm.remote_workload_type
  • Type du pair distant. ("gcp_kubernetes_engine" pour GKE).
• En fonction du type de pair, des attributs supplémentaires sont présents.
  • Pour un pair s'exécutant sur GKE :
  • csm.remote_workload_project_id
    • Identifiant du projet associé à cette ressource, par exemple "my-project".
  • csm.remote_workload_location * Emplacement physique du cluster contenant le conteneur.
  • csm.remote_workload_cluster_name
    • Cluster sur lequel le conteneur s'exécute.
  • csm.remote_workload_namespace_name
    • The namespace where the container is running.
  • csm.remote_workload_name
    • Nom de la charge de travail distante. Il doit s'agir du nom de l'objet contenant la définition du pod (par exemple, un déploiement, un ReplicaSet, ou simplement le nom d'un pod nu).

Libellés de service : informations sur le service de backend (cluster xDS) vers lequel la RPC est acheminée. Notez que cette option n'est disponible que si le service de backend a via l'API Gateway.

• csm.service_name
  • Nom du service.
• csm.service_namespace_name
  • Nom de l'espace de noms du service.

Le terme "remote_workload" fait référence au pair, c'est-à-dire que, pour les clients, le serveur Le pod cible d'un RPC est la charge de travail distante, tandis que pour les serveurs, le pod client qui a initié le RPC est la charge de travail distante.

Notez que ces attributs ne seront pas disponibles dans grpc.client.attempt.started. et grpc.server.call.started puisque toutes les informations du maillage topologique ne sont pas disponibles au point de collecte de ces métriques.

Remarque :grpc.client.call.duration n'est pas disponible en tant que métrique. grpc.client.attempt.duration et grpc.server.call.duration sont disponibles.

Instructions de configuration de l'observabilité

Cette section explique comment activer l'observabilité Cloud Service Mesh pour gRPC sans proxy sur une configuration de maillage de services.

C++

La compatibilité de l'observabilité n'est assurée que via le système de compilation Bazel. La grpcpp_csm_observability cible doit être ajoutée en tant que dépendance.

Modifications de code requises

Le code suivant doit être ajouté à vos clients et serveurs gRPC dans pour utiliser l'observabilité de Cloud Service Mesh.

#include <grpcpp/ext/csm_observability.h>

int main() {
  // …
  auto observability = grpc::CsmObservabilityBuilder()
                          .SetMeterProvider(std::move(meter_provider))
                          .BuildAndRegister();
  assert(observability.ok());
  // …
}

Avant toute opération gRPC, y compris pour créer un canal, un serveur ou des identifiants, utilisez l'API CsmObservabilityBuilder pour enregistrer un plug-in. L'exemple suivant montre comment configurer l'observabilité de Cloud Service Mesh avec un exportateur Prometheus.

  opentelemetry::exporter::metrics::PrometheusExporterOptions opts;
  opts.url = "0.0.0.0:9464";
  auto prometheus_exporter =
      opentelemetry::exporter::metrics::PrometheusExporterFactory::Create(opts);
  auto meter_provider =
      std::make_shared<opentelemetry::sdk::metrics::MeterProvider>();
  meter_provider->AddMetricReader(std::move(prometheus_exporter));
  auto observability = grpc:::CsmObservabilityBuilder()
                          .SetMeterProvider(std::move(meter_provider))
                          .BuildAndRegister();

L'API SetMeterProvider() sur CsmObservabilityBuilder() permet aux utilisateurs de définir un objet MeterProvider pouvant être configuré avec des exportateurs.

Java

Pour activer l'observabilité du service de maillage Cloud pour les applications gRPC Java, procédez comme suit :

1. Assurez-vous que le projet inclut l'artefact grpc-gcp-csm-observability. Utilisez la version 1.65.0 ou ultérieure de gRPC.

2. Dans la méthode main(), initialisez l'observabilité de Cloud Service Mesh en fournissant une instance de SDK OpenTelemetry configurée avec un MeterProvider pour collecter et exporter des métriques.

   Avant d'effectuer des opérations gRPC, comme la configuration d'un canal ou veillez à utiliser l'API CsmObservability.Builder() pour enregistrer le SDK OpenTelemetry.

   Une fois l'instance CsmObservability créée, l'appel de registerGlobal() sur l'instance active l'observabilité Cloud Service Mesh pour tous les canaux et serveurs Cloud Service Mesh.

   L'exemple suivant montre comment configurer l'observabilité Cloud Service Mesh à l'aide de comme exportateur Prometheus.

import io.grpc.gcp.csm.observability.CsmObservability;
...

public static void main(String[] args) {
    ...

    int prometheusPort = 9464;

    SdkMeterProvider sdkMeterProvider = SdkMeterProvider.builder()
        .registerMetricReader(
            PrometheusHttpServer.builder().setPort(prometheusPort).build())
        .build();

    OpenTelemetrySdk openTelemetrySdk = OpenTelemetrySdk.builder()
        .setMeterProvider(sdkMeterProvider)
        .build();

    CsmObservability observability = new CsmObservability.Builder()
        .sdk(openTelemetrySdk)
        .build();
    observability.registerGlobal();

    // ... (continue with channel and server configuration)
}

Go

Avant toute opération gRPC, y compris pour créer un ClientConn ou un serveur, ou des identifiants, configurez l'observabilité du service de maillage de services Cloud de manière globale avec un MeterProvider. L'exemple suivant montre comment configurer Cloud Service Mesh Observabilité. Une fois l'observabilité Cloud Service Mesh configurée, tous les canaux Cloud Service Mesh et tous les serveurs détectent un plug-in de statistiques OpenTelemetry configuré avec les options fournies et avec des libellés Cloud Service Mesh supplémentaires. Les canaux autres que Cloud Service Mesh recevront une Plug-in de statistiques OpenTelemetry sans libellés Cloud Service Mesh.

  import (
  "context"

  "google.golang.org/grpc/stats/opentelemetry"
  "google.golang.org/grpc/stats/opentelemetry/csm"

  "go.opentelemetry.io/otel/sdk/metric"
)

func main() {
  reader := metric.NewManualReader()
  provider := metric.NewMeterProvider(metric.WithReader(reader))
  opts := opentelemetry.Options{
    MetricsOptions: opentelemetry.MetricsOptions{
        MeterProvider: provider,
    },
  }
  cleanup := csm.EnableObservability(context.Background(), opts)
  defer cleanup()
  // Any created ClientConns and servers will be configured with an
  // OpenTelemetry stats plugin configured with provided options.

}

Python

Les dépendances gRPC suivantes sont requises pour Cloud Service Mesh Observabilité:

grpcio>=1.65.0
grpcio-observability>=1.65.0
grpcio-csm-observability>=1.65.0

Avant toute opération gRPC, y compris pour créer un canal, un serveur ou des identifiants, utilisez l'API CsmOpenTelemetryPlugin pour créer et enregistrer un plug-in :

import grpc_csm_observability

# ...
csm_plugin = grpc_csm_observability.CsmOpenTelemetryPlugin(
    meter_provider=[your_meter_provider],
)
csm_plugin.register_global()

# Create server or client 

Après toutes les opérations gRPC, utilisez le code suivant pour annuler l'enregistrement et nettoyer ressources:

csm_plugin.deregister_global()

L'exemple suivant montre comment configurer l'observabilité de Cloud Service Mesh avec un exportateur Prometheus :

import grpc_csm_observability
from opentelemetry.exporter.prometheus import PrometheusMetricReader
from prometheus_client import start_http_server

start_http_server(port=9464, addr="0.0.0.0")
reader = PrometheusMetricReader()
meter_provider = MeterProvider(metric_readers=[reader])
csm_plugin = CsmOpenTelemetryPlugin(
    meter_provider=meter_provider,
)
csm_plugin.register_global()

# Clean up after use

csm_plugin.deregister_global()

Dans l'exemple précédent, vous pouvez récupérer localhost:9464/metrics pour obtenir signalées par l'observabilité Cloud Service Mesh.

Notez que pour que les attributs de maillage ajoutés aux métriques gRPC fonctionnent, les deux les binaires du client et du serveur doivent être configurés avec CsmObservability.

Si vous utilisez une infrastructure autre que Google pour exporter et stocker des métriques, le pipeline de collecte doit ajouter des attributs aux métriques qui décrivent l'environnement sur lequel l'application s'exécute. Cela, ainsi que les attributs de maillage décrits précédemment, peut être utilisé pour obtenir une vue du trafic exécuté sur le maillage.

Modifications des spécifications

L'observabilité de Cloud Service Mesh détermine les informations topologiques du réseau maillé via des variables d'environnement qui doivent être ajoutées à l'environnement du conteneur, à la fois pour les clients et les serveurs. Ces informations sont mises à la disposition des pairs pour les rapports sur les métriques via l'observabilité de Cloud Service Mesh.

spec:
  containers:
  - image: IMAGE_NAME
    name: CONTAINER_NAME
    env:
    - name: GRPC_XDS_BOOTSTRAP
      value: "/tmp/grpc-xds/td-grpc-bootstrap.json" #created by td-grpc-bootstrap
    - name: POD_NAME
      valueFrom:
        fieldRef:
          fieldPath: metadata.name
    - name: NAMESPACE_NAME
      valueFrom:
        fieldRef:
          fieldPath: metadata.namespace
     - name: CSM_WORKLOAD_NAME
       value: CSM_WORKLOAD_NAME
     - name: CONTAINER_NAME
       value: CONTAINER_NAME
     - name: OTEL_RESOURCE_ATTRIBUTES
       value: k8s.pod.name=$(POD_NAME),k8s.namespace.name=$(NAMESPACE_NAME),k8s.container.name=CONTAINER_NAME

En remplaçant les éléments suivants :

• IMAGE_NAME par le nom de l'image.
• CONTAINER_NAME par le nom du conteneur.
• CSM_WORKLOAD_NAME par le nom de la charge de travail, par exemple le nom du déploiement.