Arbeitslasten für das bestärkende Lernen in GKE überwachen

In diesem Dokument wird beschrieben, wie Sie wichtige Messwerte und Traces für Python-basierte Anwendungen für maschinelles Lernen mit Verstärkung (Reinforcement Learning, RL) ausgeben, erfassen und ansehen, die in Google Kubernetes Engine (GKE) ausgeführt werden.

Dieses Dokument enthält Anleitungen für folgende Aufgaben:

  • Instrumentieren Sie die RL-Anwendung, um Messwerte und Traces auszugeben. Die verwendete Instrumentierung ist für Messwerte und Traces im OpenTelemetry-Format.
  • Messwerte und Traces erfassen, wenn die Anwendung in GKE ausgeführt wird. Daten werden mit Managed OpenTelemetry für GKE (Vorabversion) erhoben.
  • Sehen Sie sich die erfassten Messwerte in Cloud Monitoring und die Traces in Cloud Trace an.
  • Kritische RL-Messwerte anhand von OpenTelemetry-Semantikkonventionen und goldenen Signalen identifizieren und nachvollziehen. Goldene Signale sind die vier wichtigsten Messwerte eines Dienstes, die einen allgemeinen Überblick über seinen Zustand geben: Latenz, Traffic, Fehler und Auslastung.

Hinweis

  1. Sie benötigen eine Python-basierte RL-Anwendung, die Sie mit Messwerten und Trace-Daten überwachen möchten.

  2. Sie benötigen ein Google Cloud -Projekt mit aktivierter Abrechnung.

  3. Sie benötigen einen GKE-Cluster mit GKE-Version 1.34.1-gke.2178000 oder höher. In diesen Versionen ist Managed OpenTelemetry für GKE (Vorschau) verfügbar.

  4. Aktivieren Sie die folgenden Google Cloud APIs:

    • container.googleapis.com (GKE)
    • monitoring.googleapis.com (Monitoring)
    • cloudtrace.googleapis.com (Trace)
    • telemetry.googleapis.com (OpenTelemetry Telemetry API)

    Sie können diese APIs mit gcloud aktivieren:

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

  5. OpenTelemetry SDK installieren:Installieren Sie in der Umgebung Ihrer Python-RL-Anwendung das OpenTelemetry SDK und den OTLP-Exporter:

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

    Möglicherweise benötigen Sie auch Instrumentierungsbibliotheken für alle Frameworks, die von Ihrer RL-App verwendet werden, z. B. opentelemetry-instrumentation-flask.

Kosten

Wenn Sie Telemetriedaten an Google Cloudsenden, wird Ihnen das Aufnahmevolumen in Rechnung gestellt. Messwerte werden gemäß den Preisen für Google Cloud Managed Service for Prometheus abgerechnet, Logs gemäß den Preisen für Cloud Logging und Traces gemäß den Preisen für Cloud Trace.

Informationen zu den Kosten für die Aufnahme von Traces, Logs und Google Cloud Managed Service for Prometheus-Messwerten finden Sie unter Google Cloud Observability-Preise.

Anwendung mit OpenTelemetry instrumentieren

Instrumentieren Sie Ihren Python-RL-Anwendungscode so, dass er OpenTelemetry-Messwerte ausgeben kann. So instrumentieren Sie die Anwendung:

  1. Initialisieren Sie OpenTelemetry, indem Sie Ihrer Anwendung den folgenden Code hinzufügen:

    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. Erstellen Sie Instrumente für jeden Messwert und erfassen Sie Werte, die von der Anwendung ausgegeben werden sollen. Hängen Sie relevante semantische Konventionen als Attribute an.

    Anhand der Liste der semantischen Konventionen und goldenen Signale können Sie ermitteln, welche Messwerte für Ihre Anwendung instrumentiert werden sollen.

    Hier ein Beispiel für Instrumente für bestimmte Messwerte:

    # 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()

Nachdem Sie OpenTelemetry initialisiert und Instrumente für bestimmte Messwerte erstellt haben, gibt die Anwendung die angegebenen Telemetriedaten aus, wenn sie ausgeführt wird.

Erhebung von Messwerten und Tracedaten in GKE aktivieren

Um die Telemetriedaten zu erfassen, die von der Anwendung während der Ausführung ausgegeben werden, können Sie Managed OpenTelemetry für GKE (Vorabversion) verwenden. Bei dieser Funktion werden Telemetriedaten wie Messwerte und Traces erfasst und an Google Cloud Observability gesendet.

So aktivieren und konfigurieren Sie verwaltetes OpenTelemetry für GKE:

  1. Aktivieren Sie Managed OpenTelemetry für GKE für den Cluster, in dem die Anwendung ausgeführt wird. Folgen Sie dazu der Anleitung unter Verwaltetes OpenTelemetry für GKE in einem Cluster aktivieren.

  2. Kommentieren Sie die Bereitstellung Ihrer Anwendung mit Umgebungsvariablen, um das OpenTelemetry SDK anzuweisen, Telemetriedaten an den OTLP-Endpunkt des verwalteten Collectors zu senden. Für eine Python-basierte RL-Anwendung können Sie die automatische Konfiguration von Managed OpenTelemetry für GKE nicht verwenden.

    Fügen Sie stattdessen den folgenden env-Abschnitt in die Containerspezifikation in Ihrem Deployment-Manifest ein:

    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

Nachdem die Anwendung instrumentiert und der verwaltete Collector aktiviert und konfiguriert wurde, werden Messwerte und Traces an Google Cloud Observability gesendet, wenn die Anwendung im GKE-Cluster ausgeführt wird.

Sie können diese Telemetriedaten in Monitoring und Trace ansehen.

Messwerte in Monitoring ansehen

Sobald Ihre RL-Anwendung in GKE mit aktiviertem Managed OpenTelemetry ausgeführt wird, werden Messwerte an Monitoring gesendet. Die Messwerte sind in der Regel unter der Domain prometheus.googleapis.com/ verfügbar.

So rufen Sie Ihre benutzerdefinierten RL-Messwerte in Monitoring auf:

  1. Wenn Sie die RL-Messwerte in einem Dashboard aufrufen möchten, haben Sie folgende Möglichkeiten:

  2. Suchen Sie im Feld Messwert des Dashboards nach Messwerten, die mit prometheus.googleapis.com/ beginnen. Die verfügbaren Messwerte entsprechen den Messwerten, die Sie in der App implementiert haben. Beispiele für diese Messwerte:

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

  3. Filtern und Gruppieren:Mit den Filtern im Metrics Explorer können Sie die semantischen Konventionen nutzen, die Sie als Attribute hinzugefügt haben. Im Folgenden wird beispielsweise die Schleifendauer für einen bestimmten Lauf und Algorithmus angegeben:

    • Filter: metric.label."rl_run_id" == "run-42"
    • Filter: metric.label."rl_algorithm" == "PPO"
    • „Gruppieren nach“: metric.label."rl_environment_name", um die Leistung in verschiedenen Umgebungen zu vergleichen.

Traces in Trace ansehen

Verteilte Traces bieten eine Zeitachse der Vorgänge und helfen Ihnen, den Ausführungsablauf in Ihrem RL-System zu debuggen.

  1. Öffnen Sie in der Google Cloud Console den Trace Explorer in der Google Cloud Console:

    Zur Seite „Trace Explorer“

  2. Sie können Traces abfragen und filtern. Da Sie "service.name": "rl-training-service" als Ressourcenattribut festgelegt haben, können Sie Traces nach resource.labels.service_name="rl-training-service" filtern.

    Einzelne Zeiträume in einem Trace stellen verschiedene Teile Ihres RL-Workloads dar. Diese Spannen können Aufrufe externer Dienste oder verschiedene Phasen des RL-Loops umfassen, je nachdem, wie Sie das Tracing in der Anwendung instrumentiert haben.

Semantische Konventionen und wichtige Signale für RL

In diesem Abschnitt werden OpenTelemetry-Messwerte aufgeführt, mit denen Sie Probleme erkennen können, die auftreten, wenn die RL-Anwendung in GKE ausgeführt wird.

Mit den Informationen in diesem Abschnitt können Sie Folgendes tun:

  • Entscheiden Sie, welche Messwerte und Traces für Ihre Anwendung erfasst werden sollen.
  • Legen Sie fest, wie Sie die aus Ihrer Anwendung erhobenen Messwerte und Tracedaten ansehen und verwenden möchten.

Um RL-Arbeitslasten effektiv mit OpenTelemetry zu überwachen, ist es hilfreich, sich auf „Golden Signals“ zu konzentrieren. Goldene Signale sind die vier wichtigsten Messwerte eines Dienstes, die einen allgemeinen Überblick über seinen Zustand bieten: Latenz, Traffic, Fehler und Auslastung. Wenn Sie Ihre RL-Anwendung mit diesen Messwerten instrumentieren, können Sie Leistungsprobleme schnell erkennen und debuggen.

In den folgenden Abschnitten finden Sie die semantischen Konventionen und Messwertnamen, kategorisiert nach den Golden Signals, die sie in einem RL-Kontext darstellen.

Semantische Konventionen für RL

Die folgenden Attribute sind für Ihre Messwerte verfügbar. Diese Attribute liefern Kontext für das Filtern und Analysieren in Monitoring.

  • RL_SYSTEM = „rl.system“: Der Name des RL-Systems oder ‑Frameworks (z. B. „MyCustomRL“).
  • RL_SYSTEM_VERSION = „rl.system.version“: Version des RL-Systems.
  • RL_RUN_ID = „rl.run.id“: Eindeutige Kennung für einen bestimmten Trainingslauf.
  • RL_ALGORITHM = „rl.algorithm“: Der verwendete RL-Algorithmus (z. B. „PPO“, „DQN“).
  • RL_ENVIRONMENT_NAME = „rl.environment.name“: Der Name der RL-Umgebung (z. B. „CartPole-v1“).
  • RL_MODEL_NAME = „rl.model.name“: Der Name oder die Kennung des Richtlinien-/Wertmodells.
  • RL_LOOP = „rl.loop“: Kennung für die Haupttrainingsschleife.
  • RL_LOOP_ITERATION = „rl.loop.iteration“: Aktuelle Iterationsnummer der RL-Schleife.
  • RL_SAMPLE = „rl.sample“: Kontext für die Sampling-Phase.
  • RL_SAMPLE_EPISODES = „rl.sample.episodes“: Anzahl der Stichprobenfolgen.
  • RL_SAMPLE_STEPS = „rl.sample.steps“: Anzahl der Stichprobenschritte.
  • RL_SAMPLE_BATCH_SIZE = „rl.sample.batch_size“: Batchgröße, die beim Sampling verwendet wird.
  • RL_REWARD = „rl.reward“: Kontext für die Berechnung von Prämien.
  • RL_REWARD_BATCH_SIZE = "rl.reward.batch_size": Batchgröße für die Berechnung von Belohnungen.
  • RL_REWARD_SANDBOX = „rl.reward.sandbox“: Kennung für die Sandbox zur Berechnung von Prämien.
  • RL_TRAIN = „rl.train“: Kontext für die Trainingsphase.
  • RL_TRAIN_STEPS = „rl.train.steps“: Anzahl der Trainingsschritte.
  • RL_TRAIN_BATCH_SIZE = „rl.train.batch_size“: Die Batchgröße, die während des Trainings verwendet wird.
  • RL_TRAIN_TOKENS = „rl.train.tokens“: Anzahl der während des Trainings verarbeiteten Tokens.
  • RL_SYNC = „rl.sync“: Kontext für Synchronisierungsvorgänge.
  • RL_SYNC_BYTES = „rl.sync.bytes“: Byte, die während der Synchronisierung übertragen wurden.
  • RL_SYNC_SOURCE = „rl.sync.source“: Quelle der Synchronisierung.
  • RL_SYNC_DESTINATION = „rl.sync.destination“: Ziel der Synchronisierung.

Wichtige Signale und RL-Messwerte

In den folgenden Abschnitten werden RL-Messwerte aufgeführt, die sich auf die vier goldenen Signale beziehen: Latenz, Traffic, Fehler und Auslastung.

Weitere Informationen zu goldenen Signalen finden Sie im Buch „Site Reliability Engineering“ von Google in Kapitel 6 unter Die vier goldenen Signale.

Latenz

Wie lange dauert es, wichtige Vorgänge abzuschließen? Eine hohe Latenz kann auf Verzögerungen beim Ausführen wichtiger Vorgänge hinweisen. Die folgenden Messwerte können Ihnen helfen, Latenzprobleme zu erkennen, die auftreten, wenn Ihre RL-Anwendung in GKE ausgeführt wird.

  • rl.loop.duration (Histogramm): Eine lange Schleifendauer verlangsamt den gesamten Trainingsprozess. So lassen sich Leistungsverschlechterungen in jedem Teil des RL-Zyklus erkennen.
  • rl.sample.duration (Histogramm): Langsames Sampling wirkt sich direkt darauf aus, wie schnell neue Daten für das Training generiert werden.
  • rl.reward.duration (Histogramm): Die Berechnung der Prämie kann komplex sein. Wenn Sie die Latenz im Blick behalten, können Sie diesen wichtigen Schritt optimieren.
  • rl.train.duration (Histogramm): Die Trainingszeit ist entscheidend für die Iterationsgeschwindigkeit. Spitzenwerte können auf Probleme im Trainingsalgorithmus oder in der Hardware hinweisen.
  • rl.sync.duration (Histogramm): Eine effiziente Synchronisierung ist für verteiltes RL unerlässlich. Lange Synchronisierungszeiten können zu veralteten Daten führen und das Lernen verlangsamen.
  • rl.step.duration (Histogramm): Granulare Latenz einzelner Umgebungsschritte.

Traffic und Durchsatz

Wie viel Arbeit wird erledigt? Ein niedriger Durchsatz kann auf eine ineffiziente Ressourcennutzung hindeuten. Die folgenden Messwerte können Ihnen helfen, Probleme mit Traffic oder Durchsatz zu erkennen, die auftreten, wenn Ihre RL-Anwendung in GKE ausgeführt wird.

  • rl.sample.samples (Zähler): Stellt das Volumen der erfassten Erfahrungsdaten dar. Ein Rückgang deutet auf Probleme beim Sampling hin.
  • rl.sample.episodes (Zähler): Erfasst die Anzahl der abgeschlossenen Episoden.
  • rl.train.steps (Zähler): Misst den Trainingsfortschritt in Bezug auf Optimierungsschritte.
  • rl.train.tokens (Zähler): Erfasst die Gesamtzahl der verarbeiteten Tokens. Dieser Messwert ist für das RL großer Modelle relevant.
  • rl.tokens.rate / rl.tokens.rate_per_gpu (Messgerät/Rate): Direkte Messwerte für Trainingsgeschwindigkeit und ‑effizienz, insbesondere bei tokenbasierten Modellen.
  • rl.samples.rate / rl.samples.rate_per_gpu (Messgerät/Rate): Misst, wie schnell das System neue Stichproben erfasst.

Fehler

Gibt es Leistungs- oder Laufzeitfehler? In der RL können sich „Fehler“ in unerwartetem Verhalten oder schlechter Leistung äußern. Die folgenden Messwerte können Ihnen helfen, Fehler zu erkennen, die auftreten, wenn Ihre RL-Anwendung in GKE ausgeführt wird.

  • rl.environment.reward.mean (Messgerät): Obwohl es sich nicht um einen herkömmlichen Fehler handelt, ist ein drastischer Rückgang der durchschnittlichen Belohnung ein wichtiges Signal dafür, dass etwas mit der Interaktion zwischen Agent und Umgebung nicht stimmt. Dieser Messwert gibt Aufschluss über den Lernfortschritt und die Leistung des Agenten.
  • rl.environment.episode.length.mean (Messgerät): Ähnlich wie bei der Belohnung können unerwartete Änderungen der Episodenlänge auf Probleme hinweisen.
  • rl.train.loss (Messgerät): Ein plötzlicher Anstieg oder ein unregelmäßiges Verhalten des Trainingsverlusts deutet darauf hin, dass das Modell nicht effektiv lernt. Wichtiger Indikator für die Stabilität und den Erfolg des Trainings.

Sättigung

Ist das System überlastet? Eine hohe Sättigung kann zu Leistungseinbußen führen. Mit dem folgenden Messwert können Sie Probleme mit der Sättigung erkennen, die auftreten, wenn Ihre RL-Anwendung in GKE ausgeführt wird.

  • rl.train.mfu (Gauge): Modell für die Flop-Auslastung (Model Flop Utilization, MFU). Gibt an, wie effektiv Rechenressourcen (z. B. GPUs oder TPUs) während des Trainings genutzt werden. Ein niedriger MFU-Wert deutet auf eine Unterauslastung oder Engpässe hin.

Nächste Schritte