OpenTelemetry géré pour GKE

Ce document décrit Managed OpenTelemetry pour Google Kubernetes Engine (GKE), qui vous permet d'envoyer des traces, des métriques et des journaux OTLP (OpenTelemetry Protocol) à Google Cloud Observability à partir d'applications exécutées sur GKE. Managed OpenTelemetry fournit la seule solution gérée par Google Cloud pour collecter des données de trace sur GKE.

Pour utiliser Managed OpenTelemetry pour Google Kubernetes Engine (GKE), les applications doivent déjà être instrumentées pour générer des signaux à l'aide du protocole OpenTelemetry. Pour en savoir plus, consultez la section Charges de travail compatibles.

Managed OpenTelemetry pour GKE comporte deux composants :

  • Collecte gérée : le collecteur géré fournit un point de terminaison OpenTelemetry Protocol dans le cluster comme destination pour que les charges de travail envoient des traces, des métriques et des journaux au format OTLP, sans avoir à gérer de collecteur.

  • Configuration automatique : une ressource personnalisée appelée Instrumentation permet une configuration automatique pour que vos charges de travail GKE génèrent et ingèrent des traces, des métriques et des journaux OpenTelemetry corrélés. Cette approche est compatible avec le Agent Development Kit (ADK) et les données de prompts et de réponses multimodales.

    Vous pouvez utiliser la ressource personnalisée Instrumentation pour les charges de travail qui utilisent le SDK OpenTelemetry et qui sont configurées avec des variables d'environnement OpenTelemetry standards. Cette ressource personnalisée Instrumentation, instrumentations.telemetry.googleapis.com, est différente de la ressource Instrumentation pour l'opérateur OpenTelemetry.

Pour savoir comment utiliser Managed OpenTelemetry pour GKE, consultez Déployer Managed OpenTelemetry pour GKE.

Managed OpenTelemetry pour GKE vous permet de collecter des données de télémétrie OTLP sans avoir à gérer ni à exploiter de collecteur OpenTelemetry. L'exécution de votre propre collecteur peut entraîner une surcharge, y compris pour l'authentification, la configuration, les mises à niveau et la surveillance. Toutefois, si vous avez besoin de filtrage et de contrôles au niveau du collecteur, vous pouvez utiliser le collecteur OpenTelemetry conçu par Google au lieu de ce service géré.

OpenTelemetry fournit des API, des bibliothèques et des SDK pour générer des traces, des métriques et des journaux distribués pour la surveillance des applications. Pour en savoir plus sur OpenTelemetry, consultez la documentation sur OpenTelemetry et le OpenTelemetry Protocol (OTLP). Pour en savoir plus sur la génération et la collecte des données de comportement d'exécution de votre application, consultez la section Instrumentation et observabilité.

Fonctionnement de Managed OpenTelemetry pour GKE

Managed OpenTelemetry pour GKE comporte deux composants : la collecte gérée et la configuration automatique.

Collecte gérée

La collecte gérée fournit un point de terminaison OTLP dans le cluster en déployant un collecteur OpenTelemetry géré dans votre cluster. Ce point de terminaison OTLP dans le cluster reçoit des traces, des métriques et des journaux au format OTLP. Pour recevoir des données d'une charge de travail, celle-ci doit être configurée pour envoyer des données au collecteur.

Le point de terminaison du collecteur géré est le suivant : http://opentelemetry-collector.gke-managed-otel.svc.cluster.local:4318.

La collecte gérée envoie les données collectées à Google Cloud Observability. Les données sont ensuite disponibles dans les services suivants :

Le collecteur géré peut être activé pour un cluster GKE à l'aide de la console ou de gcloud CLI. Pour obtenir des instructions, consultez la section Activer Managed OpenTelemetry pour GKE dans un cluster.

Configuration automatique

La configuration automatique permet à GKE de configurer les charges de travail exécutées sur GKE pour envoyer des signaux au point de terminaison du collecteur géré.

Il existe différentes méthodes pour configurer une charge de travail. La configuration automatique utilise des variables d'environnement injectées dans le conteneur de la charge de travail pour que celle-ci envoie des signaux au collecteur géré. Si vous configurez manuellement la charge de travail, vous pouvez utiliser d'autres méthodes. Pour en savoir plus, consultez la section Configuration manuelle.

Lorsque vous utilisez la configuration automatique, vous définissez la configuration à l'aide de la ressource personnalisée Instrumentation. Ensuite, GKE injecte des variables d'environnement, telles que le point de terminaison de l'exportateur OTLP, dans les conteneurs de la charge de travail. Lorsque les conteneurs de la charge de travail disposent de ces variables d'environnement, les données OpenTelemetry sont envoyées au collecteur géré lors de l'exécution de la charge de travail.

La configuration automatique est disponible pour les charges de travail qui sont compatibles en mode natif avec OpenTelemetry, ce qui signifie qu'elles utilisent le SDK OpenTelemetry et qu'elles sont configurées à l'aide de variables d'environnement OpenTelemetry standards. Pour en savoir plus, consultez la section Charges de travail compatibles.

Pour savoir comment configurer votre application à l'aide de la configuration automatique, consultez Configurer votre application pour utiliser le collecteur Managed OpenTelemetry.

Ressource personnalisée Instrumentation

Vous utilisez la ressource personnalisée Instrumentation pour effectuer les opérations suivantes :

  • Spécifiez si vous souhaitez injecter les variables d'environnement dans les conteneurs des pods sélectionnés ou de tous les pods d'un espace de noms.
  • Contrôlez le type de données collectées (journaux, métriques et traces).
  • Contrôlez la fréquence à laquelle les données de métriques sont envoyées au collecteur géré.
  • Contrôlez le taux d'échantillonnage des données de trace.

Pour en savoir plus sur l'utilisation de la ressource personnalisée Instrumentation, consultez Modifier la configuration.

Injecter automatiquement des variables d'environnement

Pour injecter automatiquement des variables d'environnement OpenTelemetry dans vos charges de travail GKE, vous devez configurer un objet Instrumentation dans votre cluster. Ensuite, lorsque vous déployez l'application dans le cluster avec l'objet Instrumentation, les variables sont injectées par GKE.

L'objet Instrumentation doit se trouver dans le cluster lorsque l'application est déployée et que les pods sont créés. Si vous avez déployé l'application avant de créer l'objet Instrumentation, vous devez redémarrer les pods de l'application pour déclencher l'injection automatique des variables d'environnement.

Variables d'environnement

Lorsqu'une charge de travail est déployée dans l'espace de noms où la configuration automatique est activée, GKE injecte des variables d'environnement dans les conteneurs des charges de travail. Ces variables d'environnement sont des variables OpenTelemetry issues de la configuration du SDK OpenTelemetry.

La liste suivante contient toutes les variables d'environnement qui peuvent être injectées par Managed OpenTelemetry pour GKE. Les variables d'environnement spécifiques injectées dans un conteneur dépendent de la configuration de la ressource personnalisée Instrumentation.

Les variables d'environnement qui peuvent être injectées automatiquement dans les conteneurs sont les suivantes :

  • Point de terminaison de l'exportateur OpenTelemetry.
    • OTEL_EXPORTER_OTLP_ENDPOINT: URL de point de terminaison de base pour tout type de signal. Ce point de terminaison pointe toujours vers le point de terminaison HTTP du collecteur OpenTelemetry géré dans le cluster pour les journaux, les métriques et les traces. Le point de terminaison est le suivant : http://opentelemetry-collector.gke-managed-otel.svc.cluster.local:4318.
  • Configuration du taux d'échantillonnage des traces.
    • OTEL_TRACES_SAMPLER : définit l'échantillonneur utilisé pour échantillonner les traces par le SDK sur l'une des valeurs suivantes :
      • parentbased_traceidratio lorsque l'échantillonnage des traces est configuré dans la ressource personnalisée.
      • parentbased_always_on est la valeur par défaut de cette variable d'environnement. Elle est utilisée si cette variable d'environnement n'est pas configurée ou est nulle dans la ressource personnalisée.
    • OTEL_TRACES_SAMPLER_ARG: spécifie le taux d'échantillonnage des traces (entre 0,0 et 1,0). Si elle n'est pas configurée dans la ressource personnalisée, la valeur 1,0 est utilisée.
  • Intervalle de délai entre le début de deux exportations de métriques consécutives.
    • OTEL_METRIC_EXPORT_INTERVAL: intervalle de temps (en millisecondes) entre le début de deux tentatives d'exportation (min. : 5 000, max. : 300 000, par défaut : 30 000).
  • Désactivation de l'exportation de données de télémétrie OTLP par type de signal. Les exportateurs de signaux sont désactivés lorsque tracer_provider, meter_provider ou logger_provider sont définis sur null dans le fichier Instrumentation.
    • OTEL_TRACES_EXPORTER: désactive l'exportation des traces lorsqu'elle est définie sur none. Valeur par défaut : otlp.
    • OTEL_METRICS_EXPORTER: désactive l'exportation des métriques lorsqu'elle est définie sur none. Valeur par défaut : otlp.
    • OTEL_LOGS_EXPORTER: désactive l'exportation des journaux lorsqu'elle est définie sur none. Valeur par défaut : otlp.
  • Identification des pods hostNetwork pour associer les métadonnées par le processeur d'attributs Kubernetes du collecteur OpenTelemetry.
    • K8S_POD_UID: UID du pod hostNetwork pour remplir le paramètre k8s.pod.uid dans la variable d'environnement OTEL_RESOURCE_ATTRIBUTES.
    • OTEL_RESOURCE_ATTRIBUTES: la valeur inclut k8s.pod.uid=$(K8S_POD_UID) pour permettre au processeur d'attributs Kubernetes d'associer des métadonnées, telles que k8s.namespace.name, k8s.deployment.name et k8s.node.name, aux pods hostNetwork. L'association de métadonnées et de pods hostNetwork permet d'ajouter les métadonnées extraites aux segments, aux métriques et aux journaux en tant qu'attributs de ressource.
  • Prompts et réponses.
    • OTEL_INSTRUMENTATION_GENAI_UPLOAD_FORMAT='jsonl' : demande à OpenTelemetry de mettre en forme les objets Cloud Storage en tant que lignes JSON. Cette variable d'environnement a une valeur fixe : jsonl.
    • OTEL_INSTRUMENTATION_GENAI_COMPLETION_HOOK='upload' : demande à OpenTelemetry d'importer les données de prompt et de réponse au lieu d'intégrer ce contenu dans les segments de trace. Les références aux objets importés sont incluses dans une entrée de journal. Cette variable d'environnement a une valeur fixe : upload.
    • OTEL_SEMCONV_STABILITY_OPT_IN='gen_ai_latest_experimental' : demande à OpenTelemetry d'utiliser les conventions sémantiques les plus récentes pour l'IA générative. Cette variable d'environnement a une valeur fixe : gen_ai_latest_experimental.
    • OTEL_INSTRUMENTATION_GENAI_UPLOAD_BASE_PATH: spécifiez le chemin d'accès aux objets. Par exemple, gs://STORAGE_BUCKET_NAME/PATH

Configuration manuelle

Vous pouvez utiliser différentes méthodes pour configurer une charge de travail afin qu'elle envoie des signaux au point de terminaison du collecteur géré. Si vous configurez manuellement votre charge de travail, vous pouvez ajouter et modifier manuellement des variables d'environnement, ou utiliser une autre méthode, telle que des options de ligne de commande.

Nous vous déconseillons d'utiliser à la fois la configuration manuelle et la configuration automatique pour la même charge de travail, car la configuration automatique peut remplacer les modifications manuelles. Cette combinaison peut rendre plus difficile le suivi des modifications apportées à la configuration.

Pour en savoir plus sur la configuration automatique, consultez la section Configuration automatique.

Charges de travail compatibles

Les charges de travail compatibles sont celles qui utilisent OpenTelemetry pour collecter des données sur le comportement d'exécution de l'application. Les charges de travail sont compatibles en mode natif avec OpenTelemetry si elles utilisent le SDK OpenTelemetry et qu'elles sont configurées à l'aide de variables d'environnement OpenTelemetry standards. Par exemple, le Agent Development Kit (ADK) est compatible en mode natif avec OpenTelemetry.

Pour en savoir plus sur la génération et la collecte des données de comportement d'exécution de votre application, consultez la section Instrumentation et observabilité.

Si une charge de travail est compatible avec certains types de données OTLP, mais pas avec d'autres, Managed OpenTelemetry pour GKE collecte les données OTLP. Par exemple, si une charge de travail utilise le SDK OpenTelemetry pour implémenter des traces, mais pas pour les journaux ni les métriques, les données de journaux et de métriques ne sont pas collectées par Managed OpenTelemetry pour GKE. Pour savoir comment contrôler le type de données à collecter, consultez Sélectionner les types de signaux à collecter.

L'injection de configuration OpenTelemetry n'est pas compatible avec les charges de travail privilégiées des partenaires GKE Autopilot.

Facturation

Lorsque vous envoyez des données de télémétrie à Google Cloud, vous êtes facturé en fonction du volume d'ingestion. Les métriques sont facturées selon les tarifs de Google Cloud Managed Service pour Prometheus, les journaux selon les tarifs de Cloud Logging et les traces selon les tarifs de Cloud Trace.

Pour en savoir plus sur les coûts associés à l'ingestion de traces, de journaux et de métriques Google Cloud Managed Service pour Prometheus, consultez les tarifs de Google Cloud Observability.

Quotas

Lorsque vous utilisez Managed OpenTelemetry pour GKE, les quotas des services Google Cloud Observability s'appliquent. Pour plus de détails, consultez les pages suivantes :

Étape suivante