Memantau workload reinforcement learning di GKE

Dokumen ini menunjukkan cara memancarkan, mengumpulkan, dan melihat metrik dan rekaman aktivitas utama untuk aplikasi pembelajaran penguatan (RL) berbasis Python yang berjalan di Google Kubernetes Engine (GKE).

Dokumen ini menunjukkan cara melakukan hal berikut:

  • Menginstrumentasikan aplikasi RL untuk memancarkan metrik dan rekaman aktivitas. Instrumentasi yang digunakan adalah untuk metrik dan rekaman aktivitas yang mengikuti format OpenTelemetry.
  • Mengumpulkan metrik dan rekaman aktivitas saat aplikasi berjalan di GKE. Data dikumpulkan menggunakan Managed OpenTelemetry untuk GKE (Pratinjau).
  • Melihat metrik yang dikumpulkan di Cloud Monitoring dan rekaman aktivitas di Cloud Trace.
  • Mengidentifikasi dan memahami metrik RL penting berdasarkan konvensi semantik OpenTelemetry dan sinyal emas. Sinyal emas adalah empat metrik utama layanan yang memberikan ringkasan tingkat tinggi tentang kondisinya: Latensi, Traffic, Error, dan Saturasi.

Sebelum memulai

  1. Pastikan Anda memiliki aplikasi RL berbasis Python yang ingin dipantau menggunakan data metrik dan rekaman aktivitas.

  2. Pastikan Anda memiliki Google Cloud project dengan penagihan diaktifkan.

  3. Anda memerlukan cluster GKE yang menjalankan GKE versi 1.34.1-gke.2178000 atau yang lebih tinggi, yang merupakan versi tempat Managed OpenTelemetry untuk GKE (Pratinjau) tersedia.

  4. Aktifkan Google Cloud APIs berikut:

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

    Anda dapat mengaktifkan API ini menggunakan gcloud:

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

  5. Menginstal OpenTelemetry SDK: Di lingkungan aplikasi RL Python Anda, instal OpenTelemetry SDK dan OTLP Exporter:

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

    Anda mungkin juga memerlukan library instrumentasi untuk framework apa pun yang digunakan aplikasi RL Anda, misalnya, opentelemetry-instrumentation-flask.

Biaya

Saat Anda mengirim data telemetri ke Google Cloud, Anda akan ditagih berdasarkan volume penyerapan. Metrik ditagih menggunakan harga Google Cloud Managed Service for Prometheus, log ditagih menggunakan harga Cloud Logging, dan rekaman aktivitas ditagih menggunakan harga Cloud Trace.

Untuk mengetahui informasi tentang biaya yang terkait dengan penyerapan rekaman aktivitas, log, dan metrik Google Cloud Managed Service for Prometheus, lihat Harga Google Cloud Observability.

Menginstrumentasikan aplikasi dengan OpenTelemetry

Instrumentasikan kode aplikasi RL Python Anda sehingga dapat memancarkan metrik OpenTelemetry. Untuk menginstrumentasikan aplikasi, lakukan langkah berikut:

  1. Inisialisasi OpenTelemetry dengan menambahkan kode berikut ke aplikasi Anda:

    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. Buat instrumen untuk setiap metrik dan catat nilai yang ingin Anda pancarkan oleh aplikasi. Lampirkan konvensi semantik yang relevan sebagai atribut.

    Gunakan daftar konvensi semantik dan sinyal emas untuk membantu menentukan metrik mana yang akan diinstrumentasikan untuk aplikasi Anda.

    Berikut adalah contoh instrumen untuk metrik tertentu:

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

Setelah Anda menginisialisasi OpenTelemetry dan membuat instrumen untuk metrik tertentu, aplikasi akan memancarkan data telemetri yang ditentukan saat dijalankan.

Mengaktifkan pengumpulan data metrik dan rekaman aktivitas di GKE

Untuk mengumpulkan data telemetri yang dipancarkan aplikasi saat berjalan, Anda dapat menggunakan Managed OpenTelemetry untuk GKE (Pratinjau). Fitur ini mengumpulkan data telemetri, seperti metrik dan rekaman aktivitas, lalu mengirimkan data ke Google Cloud Observability.

Untuk mengaktifkan dan mengonfigurasi Managed OpenTelemetry untuk GKE, lakukan langkah berikut:

  1. Aktifkan Managed OpenTelemetry untuk GKE di cluster tempat aplikasi berjalan. Untuk melakukannya, ikuti langkah-langkah di Mengaktifkan Managed OpenTelemetry untuk GKE di cluster.

  2. Anotasikan Deployment aplikasi Anda dengan variabel lingkungan untuk mengarahkan OpenTelemetry SDK agar mengirim data telemetri ke endpoint OTLP pengumpul terkelola. Untuk aplikasi RL berbasis Python, Anda tidak dapat menggunakan fitur konfigurasi otomatis dari Managed OpenTelemetry untuk GKE.

    Sebagai gantinya, tambahkan bagian env berikut ke spesifikasi container di manifes Deployment Anda:

    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

Setelah aplikasi diinstrumentasikan, dan pengumpul terkelola diaktifkan serta dikonfigurasi, saat aplikasi berjalan di cluster GKE, metrik dan rekaman aktivitas akan dikirim ke Google Cloud Observability.

Anda dapat melihat data telemetri ini di Monitoring dan Trace.

Melihat metrik di Monitoring

Setelah aplikasi RL Anda berjalan di GKE dengan Managed OpenTelemetry diaktifkan, metrik akan dikirim ke Monitoring. Metrik biasanya tersedia di domain prometheus.googleapis.com/.

Untuk melihat metrik RL kustom di Monitoring, lakukan langkah berikut:

  1. Untuk melihat metrik RL di dasbor, Anda dapat melakukan salah satu hal berikut:

  2. Di kolom Metric dasbor, telusuri metrik yang dimulai dengan prometheus.googleapis.com/. Metrik yang tersedia sesuai dengan metrik yang Anda instrumentasikan di aplikasi. Contoh metrik ini dapat mencakup:

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

  3. Memfilter dan Mengelompokkan: Anda dapat menggunakan filter di Metrics Explorer untuk memanfaatkan konvensi semantik yang Anda tambahkan sebagai atribut. Misalnya, berikut menentukan durasi loop untuk algoritma dan proses tertentu:

    • Filter: metric.label."rl_run_id" == "run-42"
    • Filter: metric.label."rl_algorithm" == "PPO"
    • Kelompokkan Berdasarkan: metric.label."rl_environment_name" untuk membandingkan performa di berbagai lingkungan.

Melihat rekaman aktivitas di Trace

Rekaman aktivitas terdistribusi memberikan linimasa operasi dan membantu Anda men-debug alur eksekusi dalam sistem RL.

  1. Di Google Cloud konsol, buka Trace Explorer di Google Cloud konsol:

    Buka halaman Trace Explorer

  2. Anda dapat membuat kueri dan memfilter rekaman aktivitas. Karena Anda menetapkan "service.name": "rl-training-service" sebagai atribut resource, Anda dapat memfilter rekaman aktivitas berdasarkan resource.labels.service_name="rl-training-service".

    Rentang individual dalam rekaman aktivitas mewakili berbagai bagian dari workload RL Anda. Rentang ini dapat mencakup panggilan ke layanan eksternal atau berbagai fase loop RL, bergantung pada cara Anda menginstrumentasikan rekaman aktivitas di aplikasi.

Konvensi semantik dan sinyal emas RL

Bagian ini mencantumkan metrik OpenTelemetry yang dapat membantu Anda mengidentifikasi masalah yang terjadi saat aplikasi RL berjalan di GKE.

Gunakan informasi di bagian ini untuk melakukan hal berikut:

  • Tentukan metrik dan rekaman aktivitas yang akan dikumpulkan untuk aplikasi Anda.
  • Tentukan cara melihat dan menggunakan data metrik dan rekaman aktivitas yang dikumpulkan dari aplikasi Anda.

Untuk memantau workload RL secara efektif menggunakan OpenTelemetry, sebaiknya fokus pada "sinyal emas". Sinyal emas adalah empat metrik utama layanan yang memberikan ringkasan tingkat tinggi tentang kondisinya: Latensi, Traffic, Error, dan Saturasi. Dengan menginstrumentasikan aplikasi RL Anda menggunakan metrik ini, Anda dapat dengan cepat memahami dan men-debug masalah performa.

Bagian berikut memiliki konvensi semantik dan nama metrik yang dikategorikan berdasarkan sinyal emas yang diwakilinya dalam konteks RL.

Konvensi semantik RL

Berikut adalah atribut pada metrik Anda. Atribut ini memberikan konteks untuk pemfilteran dan analisis di Monitoring.

  • RL_SYSTEM = "rl.system": Nama sistem atau framework RL (misalnya, "MyCustomRL").
  • RL_SYSTEM_VERSION = "rl.system.version": Versi sistem RL.
  • RL_RUN_ID = "rl.run.id": ID unik untuk proses pelatihan tertentu.
  • RL_ALGORITHM = "rl.algorithm": Algoritma RL yang digunakan (misalnya, "PPO", "DQN").
  • RL_ENVIRONMENT_NAME = "rl.environment.name": Nama lingkungan RL (misalnya, "CartPole-v1").
  • RL_MODEL_NAME = "rl.model.name": Nama atau ID model kebijakan/nilai.
  • RL_LOOP = "rl.loop": ID untuk loop pelatihan utama.
  • RL_LOOP_ITERATION = "rl.loop.iteration": Nomor iterasi saat ini dari loop RL.
  • RL_SAMPLE = "rl.sample": Konteks untuk fase pengambilan sampel.
  • RL_SAMPLE_EPISODES = "rl.sample.episodes": Jumlah episode yang diambil sampelnya.
  • RL_SAMPLE_STEPS = "rl.sample.steps": Jumlah langkah yang diambil sampelnya.
  • RL_SAMPLE_BATCH_SIZE = "rl.sample.batch_size": Ukuran batch yang digunakan selama pengambilan sampel.
  • RL_REWARD = "rl.reward": Konteks untuk penghitungan reward.
  • RL_REWARD_BATCH_SIZE = "rl.reward.batch_size": Ukuran batch untuk penghitungan reward.
  • RL_REWARD_SANDBOX = "rl.reward.sandbox": ID untuk sandbox penghitungan reward.
  • RL_TRAIN = "rl.train": Konteks untuk fase pelatihan.
  • RL_TRAIN_STEPS = "rl.train.steps": Jumlah langkah pelatihan.
  • RL_TRAIN_BATCH_SIZE = "rl.train.batch_size": Ukuran batch yang digunakan selama pelatihan.
  • RL_TRAIN_TOKENS = "rl.train.tokens": Jumlah token yang diproses selama pelatihan.
  • RL_SYNC = "rl.sync": Konteks untuk operasi sinkronisasi.
  • RL_SYNC_BYTES = "rl.sync.bytes": Byte yang ditransfer selama sinkronisasi.
  • RL_SYNC_SOURCE = "rl.sync.source": Sumber sinkronisasi.
  • RL_SYNC_DESTINATION = "rl.sync.destination": Tujuan sinkronisasi.

Sinyal emas dan metrik RL

Bagian berikut mencantumkan metrik RL yang terkait dengan empat sinyal emas: Latensi, Traffic, Error, dan Saturasi.

Untuk mengetahui detail tentang sinyal emas, lihat Empat Sinyal Emas di Bab 6 buku Google Site Reliability Engineering (SRE).

Latensi

Berapa lama waktu yang diperlukan untuk menyelesaikan operasi utama? Latensi tinggi dapat menunjukkan penundaan saat menyelesaikan operasi utama. Metrik berikut dapat membantu Anda mengidentifikasi masalah latensi yang terjadi saat aplikasi RL berjalan di GKE.

  • rl.loop.duration (Histogram): durasi loop yang tinggi memperlambat seluruh proses pelatihan. Memantau hal ini membantu mengidentifikasi regresi performa di bagian mana pun dari siklus RL.
  • rl.sample.duration (Histogram): pengambilan sampel yang lambat secara langsung memengaruhi kecepatan pembuatan data baru untuk pelatihan.
  • rl.reward.duration (Histogram): penghitungan reward dapat menjadi kompleks; melacak latensinya membantu mengoptimalkan langkah penting ini.
  • rl.train.duration (Histogram): waktu pelatihan sangat penting untuk kecepatan iterasi. Lonjakan di sini dapat menunjukkan masalah dalam algoritma atau hardware pelatihan.
  • rl.sync.duration (Histogram): sinkronisasi yang efisien sangat penting dalam RL terdistribusi. Waktu sinkronisasi yang lama dapat menyebabkan data yang tidak valid dan memperlambat pembelajaran.
  • rl.step.duration (Histogram): latensi granular dari langkah lingkungan individual.

Traffic dan throughput

Berapa banyak pekerjaan yang dilakukan? Throughput rendah dapat berarti penggunaan resource yang tidak efisien. Metrik berikut dapat membantu Anda mengidentifikasi masalah terkait traffic atau throughput yang terjadi saat aplikasi RL berjalan di GKE.

  • rl.sample.samples (Penghitung): mewakili volume data pengalaman yang dikumpulkan. Penurunan menunjukkan masalah dalam proses pengambilan sampel.
  • rl.sample.episodes (Penghitung): melacak jumlah episode lengkap yang dijalankan.
  • rl.train.steps (Penghitung): mengukur progres pelatihan dalam hal langkah pengoptimalan.
  • rl.train.tokens (Penghitung): melacak total token yang diproses. Metrik ini relevan untuk RL model besar.
  • rl.tokens.rate / rl.tokens.rate_per_gpu (Pengukur/Laju): Pengukuran langsung kecepatan dan efisiensi pelatihan, terutama dalam model berbasis token.
  • rl.samples.rate / rl.samples.rate_per_gpu (Pengukur/Laju): Mengukur kecepatan sistem mengumpulkan sampel baru.

Error

Apakah ada error performa atau error yang sedang berjalan? Dalam RL, "error" dapat muncul sebagai perilaku yang tidak terduga atau performa yang buruk. Metrik berikut dapat membantu Anda mengidentifikasi error yang terjadi saat aplikasi RL berjalan di GKE.

  • rl.environment.reward.mean (Pengukur): meskipun bukan error tradisional, penurunan drastis dalam reward rata-rata adalah sinyal penting bahwa ada yang salah dengan interaksi agen atau lingkungan. Metrik ini secara langsung mencerminkan progres pembelajaran dan performa agen.
  • rl.environment.episode.length.mean (Pengukur): mirip dengan reward, perubahan panjang episode yang tidak terduga dapat menandakan masalah.
  • rl.train.loss (Pengukur): peningkatan mendadak atau perilaku tidak menentu dalam kehilangan pelatihan menunjukkan bahwa model tidak belajar secara efektif. Indikator mendasar dari stabilitas dan keberhasilan pelatihan.

Saturasi

Apakah sistem kelebihan beban? Saturasi tinggi dapat menyebabkan penurunan performa. Metrik berikut dapat membantu Anda mengidentifikasi masalah terkait saturasi yang terjadi saat aplikasi RL berjalan di GKE.

  • rl.train.mfu (Pengukur): model Flop Utilization (MFU). Menunjukkan seberapa efektif resource komputasi (seperti GPU atau TPU) digunakan selama pelatihan. MFU rendah menunjukkan pemanfaatan yang kurang atau bottleneck.

Langkah berikutnya