Memantau workload reinforcement learning di GKE

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

Dokumen ini menunjukkan cara melakukan hal berikut:

  • Instrumentasikan aplikasi RL untuk memancarkan metrik dan rekaman aktivitas. Instrumentasi yang digunakan adalah untuk metrik dan rekaman aktivitas yang mengikuti format OpenTelemetry.
  • Kumpulkan metrik dan rekaman aktivitas saat aplikasi berjalan di GKE. Data dikumpulkan menggunakan Managed OpenTelemetry untuk GKE (Pratinjau).
  • Lihat metrik yang dikumpulkan di Cloud Monitoring dan trace di Cloud Trace.
  • Identifikasi dan pahami metrik RL penting berdasarkan konvensi semantik OpenTelemetry dan sinyal emas. Sinyal emas adalah empat metrik utama layanan yang memberikan ringkasan umum tentang kesehatannya: Latensi, Traffic, Error, dan Saturasi.

Sebelum memulai

  1. Pastikan Anda memiliki aplikasi RL berbasis Python yang ingin dipantau menggunakan metrik dan data 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 API berikut:

    • container.googleapis.com (GKE)
    • monitoring.googleapis.com (Pemantauan)
    • 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. Instal 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 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 Anda dengan OpenTelemetry

Instrumentasikan kode aplikasi RL Python Anda agar dapat memancarkan metrik OpenTelemetry. Untuk menginstrumentasi aplikasi, lakukan hal berikut:

  1. Lakukan 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 dipancarkan oleh aplikasi. Lampirkan konvensi semantik yang relevan sebagai atribut.

    Gunakan daftar konvensi semantik dan sinyal keemasan untuk membantu menentukan metrik yang akan diukur 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 melakukan inisialisasi OpenTelemetry dan membuat instrumen untuk metrik tertentu, aplikasi akan memancarkan data telemetri yang ditentukan saat dijalankan.

Mengaktifkan pengumpulan metrik dan data 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 tersebut ke Google Cloud Observability.

Untuk mengaktifkan dan mengonfigurasi Managed OpenTelemetry untuk GKE, lakukan hal 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 SDK OpenTelemetry 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 penampung dalam 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 dan dikonfigurasi, saat aplikasi berjalan di cluster GKE, metrik dan trace 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 hal 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 ukur dalam 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 ini menentukan durasi loop untuk algoritma dan proses tertentu:

    • Filter: metric.label."rl_run_id" == "run-42"
    • Filter: metric.label."rl_algorithm" == "PPO"
    • Kelompokkan Menurut: 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 Anda.

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

    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 menurut resource.labels.service_name="rl-training-service".

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

Konvensi semantik RL dan sinyal emas

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 metrik serta data rekaman aktivitas yang dikumpulkan dari aplikasi Anda.

Untuk memantau beban kerja RL secara efektif menggunakan OpenTelemetry, sebaiknya fokuslah pada "sinyal emas". Sinyal emas adalah empat metrik utama layanan yang memberikan ringkasan tingkat tinggi tentang performanya: Latensi, Traffic, Error, dan Saturasi. Dengan menginstrumentasi 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 menurut sinyal keemasan 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 operasi 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 perhitungan 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 dalam buku Site Reliability Engineering (SRE) Google.

Latensi

Berapa lama waktu yang dibutuhkan untuk menyelesaikan operasi utama? Latensi tinggi dapat menunjukkan penundaan saat menyelesaikan operasi kunci. Metrik berikut dapat membantu Anda mengidentifikasi masalah latensi yang terjadi saat aplikasi RL Anda 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 dalam siklus RL.
  • rl.sample.duration (Histogram): pengambilan sampel yang lambat berdampak langsung pada seberapa cepat data baru dibuat untuk pelatihan.
  • rl.reward.duration (Histogram): penghitungan reward bisa rumit; melacak latensinya membantu mengoptimalkan langkah penting ini.
  • rl.train.duration (Histogram): waktu pelatihan sangat penting untuk kecepatan iterasi. Lonjakan di sini dapat menunjukkan masalah pada algoritma pelatihan atau hardware.
  • rl.sync.duration (Histogram): sinkronisasi yang efisien sangat penting dalam RL terdistribusi. Waktu sinkronisasi yang lama dapat menyebabkan data tidak berlaku dan memperlambat pembelajaran.
  • rl.step.duration (Histogram): latensi terperinci dari setiap langkah lingkungan.

Traffic dan throughput

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

  • rl.sample.samples (Counter): merepresentasikan volume data pengalaman yang dikumpulkan. Penurunan menunjukkan masalah dalam proses pengambilan sampel.
  • rl.sample.episodes (Penghitung): melacak jumlah episode yang selesai diputar.
  • rl.train.steps (Counter): 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/Kecepatan): Pengukuran langsung kecepatan dan efisiensi pelatihan, terutama dalam model berbasis token.
  • rl.samples.rate / rl.samples.rate_per_gpu (Pengukur/Rasio): Mengukur seberapa cepat sistem mengumpulkan sampel baru.

Error

Apakah ada error performa atau error saat 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 kerugian pelatihan menunjukkan bahwa model tidak belajar secara efektif. Indikator mendasar dari stabilitas dan keberhasilan pelatihan.

Saturasi

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

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

Langkah berikutnya