Surveiller les charges de travail d'apprentissage par renforcement sur GKE

Ce document vous explique comment émettre, collecter et afficher des métriques et des traces clés pour les applications d'apprentissage par renforcement (RL) basées sur Python qui s'exécutent sur Google Kubernetes Engine (GKE).

Ce document vous explique comment :

  • Instrumenter l'application RL pour émettre des métriques et des traces. L'instrumentation utilisée concerne les métriques et les traces qui suivent le format OpenTelemetry.
  • Collecter des métriques et des traces lorsque l'application s'exécute sur GKE. Les données sont collectées à l'aide d'OpenTelemetry géré pour GKE (bêta).
  • Afficher les métriques collectées dans Cloud Monitoring et les traces dans Cloud Trace.
  • Identifier et comprendre les métriques RL critiques en fonction des conventions sémantiques OpenTelemetry et des signaux clés. Les signaux clés sont les quatre métriques clés d'un service qui fournissent une vue d'ensemble de son état : Latence, Trafic, Erreurs et Saturation.

Avant de commencer

  1. Assurez-vous de disposer d'une application RL basée sur Python que vous souhaitez surveiller à l'aide de métriques et de données de trace.

  2. Vous devez disposer d'un Google Cloud projetpour lequel la facturation est activée.

  3. Vous avez besoin d'un cluster GKE exécutant la version 1.34.1-gke.2178000 ou une version ultérieure de GKE, qui sont les versions où OpenTelemetry géré pour GKE (bêta) est disponible.

  4. Activez les Google Cloud API suivantes :

    • container.googleapis.com (GKE)
    • monitoring.googleapis.com (Monitoring)
    • cloudtrace.googleapis.com (Trace)
    • telemetry.googleapis.com (API de télémétrie OpenTelemetry)

    Vous pouvez activer ces API à l'aide de gcloud :

    gcloud services enable \
    container.googleapis.com \
    monitoring.googleapis.com \
    cloudtrace.googleapis.com \
    telemetry.googleapis.com

  5. Installer le SDK OpenTelemetry : dans l'environnement de votre application Python RL, installez le SDK OpenTelemetry et l'exportateur OTLP :

    pip install opentelemetry-sdk \
            opentelemetry-exporter-otlp-proto-grpc \
            opentelemetry-api

    Vous aurez peut-être également besoin de bibliothèques d'instrumentation pour tous les frameworks utilisés par votre application RL, par exemple opentelemetry-instrumentation-flask.

Coûts

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.

Instrumenter votre application avec OpenTelemetry

Instrumentez le code de votre application Python RL afin qu'il puisse émettre des métriques OpenTelemetry. Pour instrumenter l'application, procédez comme suit :

  1. Initialisez OpenTelemetry en ajoutant le code suivant à votre application :

    import os
import time
from opentelemetry import metrics, trace
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader
from opentelemetry.exporter.otlp.proto.grpc.metric_exporter import OTLPMetricExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.resources import Resource
from opentelemetry.metrics import Counter, Histogram, UpDownCounter

resource = Resource.create({
    "service.name": "rl-training-service",
    "service.namespace": "opentelemetry-demo",
})

# Initialize Metrics
reader = PeriodicExportingMetricReader(
    OTLPMetricExporter(
        endpoint=os.environ.get("OTEL_EXPORTER_OTLP_METRICS_ENDPOINT", "localhost:4317"),
        insecure=True
    )
)
meter_provider = MeterProvider(metric_readers=[reader], resource=resource)
metrics.set_meter_provider(meter_provider)
meter = metrics.get_meter("rl-training-meter")

# Initialize Tracing
trace_provider = TracerProvider(resource=resource)
trace_processor = BatchSpanProcessor(
    OTLPSpanExporter(
        endpoint=os.environ.get("OTEL_EXPORTER_OTLP_TRACES_ENDPOINT", "localhost:4317"),
        insecure=True
    )
)
trace_provider.add_span_processor(trace_processor)
trace.set_tracer_provider(trace_provider)
tracer = trace.get_tracer("rl-training-tracer")

  2. Créez des instruments pour chaque métrique et enregistrez les valeurs que vous souhaitez que l'application émette. Associez les conventions sémantiques pertinentes en tant qu'attributs.

    Utilisez la liste des conventions sémantiques et des signaux clés pour déterminer les métriques à instrumenter pour votre application.

    Voici un exemple d'instruments pour des métriques spécifiques :

    # Latency Histograms
rl_loop_duration = meter.create_histogram(
    name="rl.loop.duration", description="Duration of a single RL loop iteration.", unit="ms"
)
rl_sample_duration = meter.create_histogram(
    name="rl.sample.duration", description="Duration of the sampling phase.", unit="ms"
)
rl_train_duration = meter.create_histogram(
    name="rl.train.duration", description="Duration of the training phase.", unit="ms"
)
# ... create other duration histograms (reward, train, sync, step)

# Throughput Counters
rl_sample_samples = meter.create_counter(
    name="rl.sample.samples", description="Number of samples generated.", unit="{samples}"
)
rl_train_steps = meter.create_counter(
    name="rl.train.steps", description="Number of training steps completed.", unit="{steps}"
)
# ... create other counter metrics (rl.sample.episodes, rl.train.tokens)

# Performance/Saturation Gauges (using UpDownCounter)
rl_reward_mean = meter.create_up_down_counter(
    name="rl.environment.reward.mean", description="Mean reward observed.", unit="1"
)
rl_train_loss = meter.create_up_down_counter(
    name="rl.train.loss", description="Current training loss.", unit="1"
)
rl_train_mfu = meter.create_up_down_counter(
    name="rl.train.mfu", description="Model Flop Utilization.", unit="1"
)
_rl_reward_mean_val, _rl_train_loss_val = 0.0, 0.0

def get_common_attributes(rl_system, rl_run_id, rl_algorithm, rl_env_name, rl_model_name):
    return {
        "rl.system": rl_system,
        "rl.run.id": rl_run_id,
        "rl.algorithm": rl_algorithm,
        "rl.environment.name": rl_env_name,
        "rl.model.name": rl_model_name,
    }

# Example Usage within your RL code:
common_attrs = get_common_attributes("MyPPO", "run-42", "PPO", "Acrobot-v1", "PolicyModelV1")

# Inside the main RL loop:
with tracer.start_as_current_span("rl_loop_iteration", attributes={**common_attrs, "rl.loop.iteration": 5}) as span:
    loop_start_time = time.perf_counter()
# --- Sampling Phase ---
sample_start = time.perf_counter()
# ... perform sampling ...
sampled_count = 1024
rl_sample_samples.add(sampled_count, attributes={**common_attrs, "rl.sample.batch_size": 128})
rl_sample_duration.record((time.perf_counter() - sample_start) * 1000, attributes=common_attrs)

# --- Training Phase ---
train_start = time.perf_counter()
# ... perform training step ...
rl_train_steps.add(1, attributes={**common_attrs, "rl.loop.iteration": 5})
current_loss = 0.125
rl_train_loss.add(current_loss - _rl_train_loss_val, attributes=common_attrs) # Record current loss
_rl_train_loss_val = current_loss
rl_train_duration.record((time.perf_counter() - train_start) * 1000, attributes=common_attrs)

# --- Record Mean Reward ---
current_mean_reward = -5.5
rl_reward_mean.add(current_mean_reward - _rl_reward_mean_val, attributes=common_attrs)
_rl_reward_mean_val = current_mean_reward

loop_duration = (time.perf_counter() - loop_start_time) * 1000
rl_loop_duration.record(loop_duration, attributes={**common_attrs, "rl.loop.iteration": 5})

# Ensure metrics are pushed before application exit in short-lived scripts
# For long-running services, PeriodicExportingMetricReader handles this.
# meter_provider.shutdown()

Maintenant que vous avez initialisé OpenTelemetry et créé des instruments pour des métriques spécifiques, l'application émet les données de télémétrie spécifiées lors de son exécution.

Activer la collecte de métriques et de données de trace dans GKE

Pour collecter les données de télémétrie que l'application émet lors de son exécution, vous pouvez utiliser OpenTelemetry géré pour GKE (bêta). Cette fonctionnalité collecte des données de télémétrie, telles que des métriques et des traces, et les envoie à Google Cloud Observability.

Pour activer et configurer OpenTelemetry géré pour GKE, procédez comme suit :

  1. Activez OpenTelemetry géré pour GKE sur le cluster où l'application s'exécute. Pour ce faire, suivez les étapes décrites dans Activer OpenTelemetry géré pour GKE dans un cluster.

  2. Annotez le déploiement de votre application avec des variables d'environnement pour demander au SDK OpenTelemetry d'envoyer des données de télémétrie au point de terminaison OTLP du collecteur géré. Pour une application RL basée sur Python, vous ne pouvez pas utiliser la fonctionnalité de configuration automatique d'OpenTelemetry géré pour GKE.

    Ajoutez plutôt la section env suivante à la spécification de votre conteneur dans le fichier manifeste de votre déploiement :

    env:
  - name: OTEL_COLLECTOR_NAME
    value: 'opentelemetry-collector'
  - name: OTEL_COLLECTOR_NAMESPACE
    value: 'gke-managed-otel'
  - name: OTEL_EXPORTER_OTLP_METRICS_ENDPOINT
    value: $(OTEL_COLLECTOR_NAME).$(OTEL_COLLECTOR_NAMESPACE).svc.cluster.local:4317
  - name: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT
    value: $(OTEL_COLLECTOR_NAME).$(OTEL_COLLECTOR_NAMESPACE).svc.cluster.local:4317
  - name: OTEL_SERVICE_NAME
    value: 'rl-training-service'
  - name: OTEL_RESOURCE_ATTRIBUTES
    value: service.namespace=opentelemetry-demo

Maintenant que l'application est instrumentée et que le collecteur géré est activé et configuré, lorsque l'application s'exécute sur le cluster GKE, les métriques et les traces sont envoyées à Google Cloud Observability.

Vous pouvez afficher ces données de télémétrie dans Monitoring et Trace.

Afficher les métriques dans Monitoring

Une fois votre application RL exécutée sur GKE avec OpenTelemetry géré activé, les métriques sont envoyées à Monitoring. Les métriques sont généralement disponibles sous le domaine prometheus.googleapis.com/.

Pour afficher vos métriques RL personnalisées dans Monitoring, procédez comme suit :

  1. Pour afficher les métriques RL dans un tableau de bord, vous pouvez effectuer l'une des opérations suivantes :

  2. Dans le champ Métrique du tableau de bord, recherchez les métriques commençant par prometheus.googleapis.com/. Les métriques disponibles correspondent à celles que vous avez instrumentées dans l'application. Voici quelques exemples de ces métriques :

    • prometheus.googleapis.com/rl_loop_duration_histogram/
    • prometheus.googleapis.com/rl_sample_samples_total/
    • prometheus.googleapis.com/rl_environment_reward_mean_total/

  3. Filtrage et regroupement : vous pouvez utiliser les filtres de l'explorateur de métriques pour exploiter les conventions sémantiques que vous avez ajoutées en tant qu'attributs. Par exemple, le code suivant spécifie la durée de la boucle pour une exécution et un algorithme spécifiques :

    • Filtre : metric.label."rl_run_id" == "run-42"
    • Filtre : metric.label."rl_algorithm" == "PPO"
    • Regrouper par : metric.label."rl_environment_name" pour comparer les performances entre les environnements.

Afficher les traces dans Trace

Les traces distribuées fournissent une chronologie des opérations et vous aident à déboguer le flux d'exécution dans votre système RL.

  1. Dans la Google Cloud console, ouvrez l'explorateur Trace dans la Google Cloud console :

    Accéder à la page "Explorateur Trace"

  2. Vous pouvez interroger et filtrer les traces. Étant donné que vous avez défini "service.name": "rl-training-service" comme attribut de ressource, vous pouvez filtrer les traces par resource.labels.service_name="rl-training-service".

    Les délais individuels d'une trace représentent différentes parties de votre charge de travail RL. Ces délais peuvent inclure des appels à des services externes ou différentes phases de la boucle RL, en fonction de la façon dont vous avez instrumenté le traçage dans l'application.

Conventions sémantiques et signaux clés RL

Cette section répertorie les métriques OpenTelemetry qui peuvent vous aider à identifier les problèmes qui se produisent lors de l'exécution de l'application RL sur GKE.

Utilisez les informations de cette section pour effectuer les opérations suivantes :

  • Décidez des métriques et des traces à collecter pour votre application.
  • Décidez comment afficher et utiliser les métriques et les données de trace collectées à partir de votre application.

Pour surveiller efficacement les charges de travail RL à l'aide d'OpenTelemetry, il est utile de se concentrer sur les "signaux clés". Les signaux clés sont les quatre métriques clés d'un service qui fournissent une vue d'ensemble de son état : Latence, Trafic, Erreurs et Saturation. En instrumentant votre application RL avec ces métriques, vous pouvez rapidement comprendre et déboguer les problèmes de performances.

Les sections suivantes contiennent les conventions sémantiques et les noms de métriques classés par les signaux clés qu'ils représentent dans un contexte RL.

Conventions sémantiques RL

Voici les attributs de vos métriques. Ces attributs fournissent un contexte pour le filtrage et l'analyse dans Monitoring.

  • RL_SYSTEM = "rl.system" : nom du système ou du framework RL (par exemple, "MyCustomRL").
  • RL_SYSTEM_VERSION = "rl.system.version" : version du système RL.
  • RL_RUN_ID = "rl.run.id" : identifiant unique d'un cycle d'entraînement spécifique.
  • RL_ALGORITHM = "rl.algorithm" : algorithme RL utilisé (par exemple, "PPO", "DQN").
  • RL_ENVIRONMENT_NAME = "rl.environment.name" : nom de l'environnement RL (par exemple, "CartPole-v1").
  • RL_MODEL_NAME = "rl.model.name" : nom ou identifiant du modèle de stratégie/valeur.
  • RL_LOOP = "rl.loop" : identifiant de la boucle d'entraînement principale.
  • RL_LOOP_ITERATION = "rl.loop.iteration" : numéro d'itération actuel de la boucle RL.
  • RL_SAMPLE = "rl.sample" : contexte de la phase d'échantillonnage.
  • RL_SAMPLE_EPISODES = "rl.sample.episodes" : nombre d'épisodes échantillonnés.
  • RL_SAMPLE_STEPS = "rl.sample.steps" : nombre d'étapes échantillonnées.
  • RL_SAMPLE_BATCH_SIZE = "rl.sample.batch_size" : taille de lot utilisé lors de l'échantillonnage.
  • RL_REWARD = "rl.reward" : contexte du calcul de la récompense.
  • RL_REWARD_BATCH_SIZE = "rl.reward.batch_size" : taille de lot pour le calcul de la récompense.
  • RL_REWARD_SANDBOX = "rl.reward.sandbox" : identifiant du bac à sable de calcul de la récompense.
  • RL_TRAIN = "rl.train" : contexte de la phase d'entraînement.
  • RL_TRAIN_STEPS = "rl.train.steps" : nombre d'étapes d'entraînement.
  • RL_TRAIN_BATCH_SIZE = "rl.train.batch_size" : taille de lot utilisé lors de l'entraînement.
  • RL_TRAIN_TOKENS = "rl.train.tokens" : nombre de jetons traités lors de l'entraînement.
  • RL_SYNC = "rl.sync" : contexte des opérations de synchronisation.
  • RL_SYNC_BYTES = "rl.sync.bytes" : octets transférés lors de la synchronisation.
  • RL_SYNC_SOURCE = "rl.sync.source" : source de la synchronisation.
  • RL_SYNC_DESTINATION = "rl.sync.destination" : destination de la synchronisation.

Signaux clés et métriques RL

Les sections suivantes répertorient les métriques RL liées aux quatre signaux clés : Latence, Trafic, Erreurs et Saturation.

Pour en savoir plus sur les signaux clés, consultez Les quatre signaux clés au chapitre 6 du livre Google sur l'ingénierie de la fiabilité des sites (SRE).

Latence

Combien de temps faut-il pour effectuer les opérations clés ? Une latence élevée peut indiquer des retards lors de l'exécution des opérations clés. Les métriques suivantes peuvent vous aider à identifier les problèmes de latence qui se produisent lors de l'exécution de votre application RL sur GKE.

  • rl.loop.duration (histogramme) : une durée de boucle élevée ralentit l'ensemble du processus d'entraînement. La surveillance de cette métrique permet d'identifier les régressions de performances dans n'importe quelle partie du cycle RL.
  • rl.sample.duration (histogramme) : un échantillonnage lent a un impact direct sur la vitesse à laquelle de nouvelles données sont générées pour l'entraînement.
  • rl.reward.duration (histogramme) : le calcul de la récompense peut être complexe. Le suivi de sa latence permet d'optimiser cette étape critique.
  • rl.train.duration (histogramme) : la durée d'entraînement est essentielle pour la vitesse d'itération. Les pics peuvent indiquer des problèmes dans l'algorithme d'entraînement ou le matériel.
  • rl.sync.duration (histogramme) : une synchronisation efficace est essentielle dans le RL distribué. Des durées de synchronisation longues peuvent entraîner des données obsolètes et ralentir l'apprentissage.
  • rl.step.duration (histogramme) : latence granulaire des étapes d'environnement individuelles.

Trafic et débit

Quelle quantité de travail est effectuée ? Un faible débit peut signifier une utilisation inefficace des ressources. Les métriques suivantes peuvent vous aider à identifier les problèmes de trafic ou de débit qui se produisent lors de l'exécution de votre application RL sur GKE.

  • rl.sample.samples (compteur) : représente le volume de données d'expérience collectées. Une baisse indique des problèmes dans le processus d'échantillonnage.
  • rl.sample.episodes (compteur) : suit le nombre d'épisodes complets exécutés.
  • rl.train.steps (compteur) : mesure la progression de l'entraînement en termes d'étapes d'optimisation.
  • rl.train.tokens (compteur) : suit le nombre total de jetons traités. Cette métrique est pertinente pour le RL de grands modèles.
  • rl.tokens.rate / rl.tokens.rate_per_gpu (jauge/taux) : mesures directes de la vitesse et de l'efficacité de l'entraînement, en particulier dans les modèles basés sur des jetons.
  • rl.samples.rate / rl.samples.rate_per_gpu (jauge/taux) : mesure la vitesse à laquelle le système collecte de nouveaux échantillons.

Erreurs

Y a-t-il des erreurs d'exécution ou de performances ? Dans le RL, les "erreurs" peuvent se manifester par un comportement inattendu ou de mauvaises performances. Les métriques suivantes peuvent vous aider à identifier les erreurs qui se produisent lors de l'exécution de votre application RL sur GKE.

  • rl.environment.reward.mean (jauge) : bien qu'il ne s'agisse pas d'une erreur traditionnelle, une baisse spectaculaire de la récompense moyenne est un signal critique indiquant qu'un problème se produit avec l'interaction entre l'agent et l'environnement. Cette métrique reflète directement la progression de l'apprentissage et les performances de l'agent.
  • rl.environment.episode.length.mean (jauge) : comme pour la récompense, des modifications inattendues de la durée de l'épisode peuvent signaler des problèmes.
  • rl.train.loss (jauge) : une augmentation soudaine ou un comportement erratique de la perte d'entraînement indique que le modèle n'apprend pas efficacement. Indicateur fondamental de la stabilité et de la réussite de l'entraînement.

Saturation

Le système est-il surchargé ? Une saturation élevée peut entraîner une dégradation des performances. La métrique suivante peut vous aider à identifier les problèmes de saturation qui se produisent lors de l'exécution de votre application RL sur GKE.

  • rl.train.mfu (jauge) : utilisation des FLOPS du modèle (MFU). Indique l'efficacité avec laquelle les ressources de calcul (telles que les GPU ou les TPU) sont utilisées lors de l'entraînement. Une faible MFU suggère une sous-utilisation ou des goulots d'étranglement.

Étape suivante