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 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 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
Instrumentationpermet 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
Instrumentationpour les charges de travail qui utilisent le SDK OpenTelemetry et qui sont configurées avec des variables d'environnement OpenTelemetry standards. CetteInstrumentationressource personnalisée,instrumentations.telemetry.googleapis.com, est une ressource différente de laInstrumentationressource 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 des frais généraux, y compris pour l'authentification, la configuration, les mises à niveau et la surveillance. Toutefois, si vous avez besoin de filtrer et de contrôler 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 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 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 à
le 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 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
object,
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_traceidratiolorsque l'échantillonnage des traces est configuré dans la ressource personnalisée.parentbased_always_onest 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 : 60 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, oulogger_providersont définis surnulldans le fichierInstrumentation.OTEL_TRACES_EXPORTER: désactive l'exportation des traces lorsqu'elle est définie surnone. Valeur par défaut :otlp.OTEL_METRICS_EXPORTER: désactive l'exportation des métriques lorsqu'elle est définie surnone. Valeur par défaut :otlp.OTEL_LOGS_EXPORTER: désactive l'exportation des journaux lorsqu'elle est définie surnone. 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 de pod d'un pod hostNetwork pour remplir lek8s.pod.uidparamètre dans laOTEL_RESOURCE_ATTRIBUTESvariable d'environnement.OTEL_RESOURCE_ATTRIBUTES: la valeur inclutk8s.pod.uid=$(K8S_POD_UID)pour permettre au processeur d'attributs Kubernetes d'associer des métadonnées, telles quek8s.namespace.name,k8s.deployment.nameetk8s.node.name, aux pods hostNetwork. L'association de métadonnées et de pods hostNetwork permet d' ajouter les métadonnées extraites aux étendues, aux métriques et aux journaux en tant qu'attributs de ressource.
Configuration manuelle
Il existe 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 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, l' 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, alors 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 sont facturés selon les tarifs de Cloud Logging et les traces sont facturées 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 :
- Quotas et limites de Cloud Logging
- Quotas et limites de Cloud Monitoring
- Quotas et limites de Cloud Trace
Étape suivante
- Pour déployer le collecteur, consultez Déployer Managed OpenTelemetry pour GKE.
- Pour une alternative auto-déployée à Managed OpenTelemetry pour GKE, consultez Collecteur OpenTelemetry conçu par Google.
- Pour savoir comment configurer l'instrumentation OpenTelemetry afin de générer des traces, des métriques et des journaux à partir de vos applications, consultez les pages suivantes :
- Ajouter des traces et des métriques personnalisées à votre application avec OpenTelemetry.