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 OpenTelemetry Protocol (OTLP) à Google Cloud Observability à partir d'applications exécutées sur GKE. Managed OpenTelemetry est 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 Charges de travail compatibles.

Managed OpenTelemetry pour GKE se compose de deux éléments :

  • Collecte gérée : le collecteur géré fournit un point de terminaison OpenTelemetry Protocol dans le cluster comme destination pour les charges de travail qui 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 l'Agent Development Kit (ADK).

    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 un collecteur OpenTelemetry. L'exécution de votre propre collecteur peut entraîner des frais généraux, y compris pour l'authentification, la configuration, les mises à niveau et la surveillance. Toutefois, si vous avez besoin de filtres et de contrôles au niveau du collecteur, vous pouvez utiliser le collecteur OpenTelemetry intégré à Google au lieu de ce service géré.

OpenTelemetry fournit des API, des bibliothèques et des SDK permettant de 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 protocole OpenTelemetry (OTLP). Pour en savoir plus sur la génération et la collecte des données sur le comportement d'exécution de votre application, consultez Instrumentation et observabilité.

Fonctionnement d'OpenTelemetry géré 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 :

Vous pouvez activer le collecteur géré pour un cluster GKE à l'aide de la console ou de la gcloud CLI. Pour obtenir des instructions, consultez 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 qu'elles envoient 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 Configuration manuelle.

Lorsque vous utilisez la configuration automatique, vous définissez la configuration à l'aide de la ressource personnalisée Instrumentation. GKE injecte ensuite 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 sont configurées à l'aide de variables d'environnement OpenTelemetry standards. Pour en savoir plus, consultez Charges de travail compatibles.

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

Ressource personnalisée Instrumentation

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

  • Indiquez 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 savoir comment utiliser 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 provenant 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.

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

  • 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 : http://opentelemetry-collector.gke-managed-otel.svc.cluster.local:4318.
  • Configuration du ratio d'échantillonnage des traces.
    • OTEL_TRACES_SAMPLER : définit le sampler utilisé par le SDK pour échantillonner les traces sur l'une des valeurs suivantes :
      • parentbased_traceidratio lorsque l'échantillonnage de trace est configuré dans la ressource personnalisée.
      • parentbased_always_on est la valeur par défaut de cette variable d'environnement. Il est utilisé 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 : 60 000).
  • Désactivation de l'exportation de la 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'il est défini 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 des métadonnées et des pods hostNetwork permet d'ajouter les métadonnées extraites aux spans, aux métriques et aux journaux en tant qu'attributs de ressources.

Configuration manuelle

Il existe différentes méthodes pour configurer une charge de travail afin d'envoyer 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, comme 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 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 sont configurées à l'aide des variables d'environnement OpenTelemetry standards. Par exemple, l'Agent Development Kit (ADK) est compatible avec OpenTelemetry.

Pour en savoir plus sur la façon dont les données de comportement d'exécution de votre application sont générées et collectées, consultez 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 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 :

Étapes suivantes