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 bestärkendes Lernen (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 gilt für Messwerte und Traces im OpenTelemetry-Format.
  • Erfassen Sie Messwerte und Traces, wenn die Anwendung in GKE ausgeführt wird. Daten werden mit Managed OpenTelemetry for GKE (Vorschau) erfasst.
  • Sehen Sie sich die erfassten Messwerte in Cloud Monitoring und die Traces in Cloud Trace an.
  • Identifizieren und verstehen Sie wichtige RL-Messwerte basierend auf semantischen OpenTelemetry-Konventionen und goldenen Signalen. 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 (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-Anwendung verwendet werden, z. B. opentelemetry-instrumentation-flask.

Kosten

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

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

Anwendung mit OpenTelemetry instrumentieren

Instrumentieren Sie den Code Ihrer Python-RL-Anwendung, damit OpenTelemetry-Messwerte ausgegeben werden können. 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 zeichnen Sie die Werte auf, die von der Anwendung ausgegeben werden sollen. Fügen Sie relevante semantische Konventionen als Attribute hinzu.

    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 Trace-Daten in GKE aktivieren

Wenn Sie die Telemetriedaten erfassen möchten, die von der Anwendung während der Ausführung ausgegeben werden, können Sie Managed OpenTelemetry for GKE (Vorschau) verwenden. Mit dieser Funktion werden Telemetriedaten wie Messwerte und Traces erfasst und an Google Cloud Observability gesendet.

So aktivieren und konfigurieren Sie Managed OpenTelemetry for GKE:

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

  2. Annotieren 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 for GKE nicht verwenden.

    Fügen Sie stattdessen den folgenden env-Abschnitt zur Containerspezifikation im Bereitstellungsmanifest hinzu:

    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 sehen Sie sich Ihre benutzerdefinierten RL-Messwerte in Monitoring an:

  1. Wenn Sie die RL-Messwerte in einem Dashboard ansehen 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 Anwendung instrumentiert haben. Beispiele für diese Messwerte sind:

    • 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:Sie können die Filter im Metrics Explorer verwenden, um die semantischen Konventionen zu nutzen, die Sie als Attribute hinzugefügt haben. Im Folgenden wird beispielsweise die Schleifendauer für eine bestimmte Ausführung und einen bestimmten 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:

    Seite Trace Explorer aufrufen

  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 Spans in einem Trace stellen verschiedene Teile Ihrer RL-Arbeitslast dar. Diese Spans können Aufrufe an externe Dienste oder verschiedene Phasen der RL-Schleife enthalten, je nachdem, wie Sie das Tracing in der Anwendung instrumentiert 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.

Verwenden Sie die Informationen in diesem Abschnitt für folgende Aufgaben:

  • Entscheiden Sie, welche Messwerte und Traces für Ihre Anwendung erfasst werden sollen.
  • Entscheiden Sie, wie Sie die von Ihrer Anwendung erfassten Messwerte und Trace-Daten ansehen und verwenden.

Um RL-Arbeitslasten mit OpenTelemetry effektiv zu überwachen, ist es hilfreich, sich auf „goldene Signale“ 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 debuggen.

In den folgenden Abschnitten sind die semantischen Konventionen und Messwertnamen nach den goldenen Signalen kategorisiert, die sie in einem RL-Kontext darstellen.

Semantische Konventionen für RL

Im Folgenden finden Sie Attribute für Ihre Messwerte. Diese Attribute bieten 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 Stichprobenphase.
  • RL_SAMPLE_EPISODES = "rl.sample.episodes": Anzahl der Stichprobenepisoden.
  • RL_SAMPLE_STEPS = "rl.sample.steps": Anzahl der Stichprobenschritte.
  • RL_SAMPLE_BATCH_SIZE = "rl.sample.batch_size": Batchgröße, die während der Stichprobenerhebung verwendet wird.
  • RL_REWARD = "rl.reward": Kontext für die Belohnungsberechnung.
  • RL_REWARD_BATCH_SIZE = "rl.reward.batch_size": Batchgröße für die Belohnungsberechnung.
  • RL_REWARD_SANDBOX = "rl.reward.sandbox": Kennung für die Sandbox zur Belohnungsberechnung.
  • 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": 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.

Goldene Signale und RL-Messwerte

In den folgenden Abschnitten werden RL-Messwerte aufgeführt, die mit den vier goldenen Signalen zusammenhängen: Latenz, Traffic, Fehler und Sättigung.

Weitere Informationen zu goldenen Signalen finden Sie unter Die vier goldenen Signale in Kapitel 6 des Google-Buchs Site Reliability Engineering (SRE).

Latenz

Wie lange dauert es, wichtige Vorgänge abzuschließen? Eine hohe Latenz kann auf Verzögerungen beim Abschließen wichtiger Vorgänge hindeuten. Mit den folgenden Messwerten können Sie Latenzprobleme identifizieren, die auftreten, wenn Ihre RL-Anwendung in GKE ausgeführt wird.

  • rl.loop.duration (Histogramm): Eine lange Schleifendauer verlangsamt den gesamten Trainingsprozess. Wenn Sie diesen Messwert im Blick behalten, können Sie Leistungsregressionen 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 Belohnungsberechnung 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 mit dem Trainingsalgorithmus oder der Hardware hindeuten.
  • rl.sync.duration (Histogramm): Eine effiziente Synchronisierung ist in verteilten RL-Systemen 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. Mit den folgenden Messwerten können Sie Probleme mit Traffic oder Durchsatz identifizieren, 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 im Stichprobenprozess 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 RL mit großen Modellen relevant.
  • rl.tokens.rate / rl.tokens.rate_per_gpu (Messgerät/Rate): Direkte Messungen der 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 Ausführungsfehler? In RL können sich „Fehler“ als unerwartetes Verhalten oder schlechte Leistung äußern. Mit den folgenden Messwerten können Sie Fehler identifizieren, die auftreten, wenn Ihre RL-Anwendung in GKE ausgeführt wird.

  • rl.environment.reward.mean (Messgerät): Obwohl dies kein herkömmlicher Fehler ist, 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 direkt Aufschluss über den Lernfortschritt und die Leistung des Agents.
  • rl.environment.episode.length.mean (Messgerät): Ähnlich wie bei der Belohnung können unerwartete Änderungen der Episodenlänge auf Probleme hindeuten.
  • 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. Grundlegender Indikator für die Trainingsstabilität und den Trainingserfolg.

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 identifizieren, die auftreten, wenn Ihre RL-Anwendung in GKE ausgeführt wird.

  • rl.train.mfu (Messgerät): 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