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. Die Daten werden mit Managed OpenTelemetry für GKE (Vorabversion) erhoben.
  • Die erfassten Messwerte können Sie in Cloud Monitoring und die Traces in Cloud Trace ansehen.
  • Kritische RL-Messwerte anhand von OpenTelemetry-Konventionen und Golden Signals identifizieren und verstehen. Goldene Signale sind die vier wichtigsten Messwerte eines Dienstes, die einen allgemeinen Überblick über seinen Zustand geben: Latenz, Traffic, Fehler und Sättigung.

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 for GKE (Vorabversion) 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 Messwerten für Google Cloud Managed Service for Prometheus 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.

    Im Folgenden finden Sie 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.

Erfassung 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. Fügen Sie Ihrer Anwendungsbereitstellung Umgebungsvariablen hinzu, 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 Bereitstellungsmanifest 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. Sie haben folgende Möglichkeiten, um die RL-Messwerte in einem Dashboard aufzurufen:

  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 Anwendung 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 Beispiel wird 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 Spannen in einem Trace stellen verschiedene Teile Ihrer RL-Arbeitslast dar. Diese Spannen können Aufrufe externer Dienste oder verschiedene Phasen des RL-Loops umfassen, je nachdem, wie Sie das Tracing in der Anwendung eingerichtet haben.

Semantische Konventionen und goldene Signale für RL

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

Anhand der 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 Messwerte und Trace-Daten, die von Ihrer Anwendung erfasst werden, 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 geben: Latenz, Traffic, Fehler und Sättigung. Wenn Sie Ihre RL-Anwendung mit diesen Messwerten instrumentieren, können Sie Leistungsprobleme schnell erkennen und beheben.

In den folgenden Abschnitten finden Sie die semantischen Konventionen und Messwertnamen, die nach den Goldenen Signalen kategorisiert sind, 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“: Während der Synchronisierung übertragene Byte.
  • 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 Sättigung.

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

Latenz

Wie lange dauert es, Schlüsselvorgänge auszuführen? Eine hohe Latenz kann auf Verzögerungen beim Ausführen wichtiger Vorgänge hinweisen. Mit den folgenden Messwerten können Sie Latenzprobleme 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): Eine langsame Stichprobenerhebung wirkt sich direkt darauf aus, wie schnell neue Daten für das Training generiert werden.
  • rl.reward.duration (Histogramm): Die Berechnung von Prämien 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 erhobenen Daten dar. Ein Rückgang deutet auf Probleme beim Sampling hin.
  • rl.sample.episodes (Zähler): Erfasst die Anzahl der vollständig ausgeführten 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 bestärkende Lernen mit großen Modellen 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 RL können sich „Fehler“ in unerwartetem Verhalten oder schlechter Leistung äußern. Mithilfe der folgenden Messwerte können Sie Fehler 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 des durchschnittlichen Rewards 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 KI-Agents.
  • 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. Ein grundlegender 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 (Messgerät): 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. Eine niedrige MFU deutet auf eine Unterauslastung oder Engpässe hin.

Nächste Schritte