Monitorar cargas de trabalho de aprendizado por reforço no GKE

Neste documento, mostramos como emitir, coletar e visualizar métricas e rastreamentos principais para aplicativos de aprendizado por reforço (RL, na sigla em inglês) baseados em Python que estão sendo executados no Google Kubernetes Engine (GKE).

Esta página mostra como fazer o seguinte:

  • Instrumente o aplicativo de RL para emitir métricas e traces. A instrumentação usada é para métricas e traces que seguem o formato OpenTelemetry.
  • Colete métricas e rastreamentos quando o aplicativo for executado no GKE. Os dados são coletados usando o OpenTelemetry gerenciado para GKE (pré-lançamento).
  • Veja as métricas coletadas no Cloud Monitoring e os traces no Cloud Trace.
  • Identificar e entender as métricas de RL críticas com base nas convenções semânticas do OpenTelemetry e nos indicadores de ouro. Os indicadores de ouro são as quatro métricas principais de um serviço que fornecem uma visão geral de alto nível da integridade dele: latência, tráfego, erros e saturação.

Antes de começar

  1. Verifique se você tem um aplicativo de RL baseado em Python que quer monitorar usando métricas e dados de rastreamento.

  2. Verifique se você tem um projeto do Google Cloud com o faturamento ativado.

  3. Você precisa de um cluster do GKE executando a versão 1.34.1-gke.2178000 ou mais recente, que são as versões em que o Managed OpenTelemetry para GKE (Pré-lançamento) está disponível.

  4. Ative as seguintes APIs Google Cloud :

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

    É possível ativar essas APIs usando gcloud:

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

  5. Instale o SDK do OpenTelemetry:no ambiente do seu aplicativo de RL em Python, instale o SDK do OpenTelemetry e o exportador OTLP:

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

    Você também pode precisar de bibliotecas de instrumentação para qualquer framework usado pelo seu app de RL, por exemplo, opentelemetry-instrumentation-flask.

Custos

Quando você envia dados de telemetria para Google Cloud, a cobrança é feita pelo volume de ingestão. As métricas são faturadas usando os preços do Google Cloud Managed Service para Prometheus, os registros usando os preços do Cloud Logging e os rastreamentos usando os preços do Cloud Trace.

Para informações sobre os custos associados à ingestão de rastreamentos, registros e métricas do Google Cloud Managed Service para Prometheus, consulte Preços do Google Cloud Observability.

Instrumentar o aplicativo com o OpenTelemetry

Instrumente o código do aplicativo Python de RL para que ele possa emitir métricas do OpenTelemetry. Para instrumentar o aplicativo, faça o seguinte:

  1. Inicialize o OpenTelemetry adicionando o seguinte código ao seu aplicativo:

    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. Crie instrumentos para cada métrica e registre os valores que você quer emitidos pelo aplicativo. Anexe as convenções semânticas relevantes como atributos.

    Use a lista de convenções semânticas e indicadores dourados para ajudar a determinar quais métricas instrumentar para seu aplicativo.

    Confira a seguir um exemplo de instrumentos para métricas específicas:

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

Agora que você inicializou o OpenTelemetry e criou instrumentos para métricas específicas, o aplicativo emite os dados de telemetria especificados quando é executado.

Ativar a coleta de métricas e dados de rastreamento no GKE

Para coletar os dados de telemetria emitidos pelo aplicativo durante a execução, use o Managed OpenTelemetry para GKE (pré-lançamento). Esse recurso coleta dados de telemetria, como métricas e traces, e os envia para o Google Cloud Observability.

Para ativar e configurar o OpenTelemetry gerenciado para GKE, faça o seguinte:

  1. Ative o OpenTelemetry gerenciado para GKE no cluster em que o aplicativo é executado. Para fazer isso, siga as etapas em Ativar o OpenTelemetry gerenciado para GKE em um cluster.

  2. Anotar a implantação do aplicativo com variáveis de ambiente para direcionar o SDK do OpenTelemetry a enviar dados de telemetria para o endpoint OTLP do coletor gerenciado. Para um aplicativo de RL baseado em Python, não é possível usar o recurso de configuração automática do Managed OpenTelemetry para GKE.

    Em vez disso, adicione a seguinte seção env à especificação do contêiner no manifesto de implantação:

    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

Agora que o aplicativo está instrumentado e o coletor gerenciado está ativado e configurado, quando o aplicativo é executado no cluster do GKE, métricas e rastreamentos são enviados para o Google Cloud Observability.

É possível conferir esses dados de telemetria no Monitoring e no Trace.

Ver métricas no Monitoring

Depois que o aplicativo de RL estiver em execução no GKE com o Managed OpenTelemetry ativado, as métricas serão enviadas ao Monitoring. As métricas geralmente estão disponíveis no domínio prometheus.googleapis.com/.

Para conferir suas métricas personalizadas de RL no Monitoring, faça o seguinte:

  1. Para ver as métricas de RL em um painel, faça o seguinte:

  2. No campo Métrica do painel, pesquise métricas que começam com prometheus.googleapis.com/. As métricas disponíveis correspondem às que você instrumentou no aplicativo. Exemplos dessas métricas:

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

  3. Filtragem e agrupamento:use os filtros no Metrics Explorer para aproveitar as convenções semânticas adicionadas como atributos. Por exemplo, o seguinte especifica a duração do loop para uma execução e um algoritmo específicos:

    • Filtro: metric.label."rl_run_id" == "run-42"
    • Filtro: metric.label."rl_algorithm" == "PPO"
    • Agrupar por: metric.label."rl_environment_name" para comparar a performance em diferentes ambientes.

Ver traces no Trace

Os rastreamentos distribuídos fornecem uma linha do tempo de operações e ajudam a depurar o fluxo de execução no sistema de RL.

  1. No console Google Cloud , abra o Explorador de traces no console Google Cloud :

    Acessar a página do Explorador de traces

  2. É possível consultar e filtrar traces. Como você definiu "service.name": "rl-training-service" como um atributo de recurso, é possível filtrar os rastreamentos por resource.labels.service_name="rl-training-service".

    Intervalos individuais em um rastreamento representam diferentes partes da sua carga de trabalho de RL. Esses intervalos podem incluir chamadas para serviços externos ou diferentes fases do loop de RL, dependendo de como você instrumentou o rastreamento no aplicativo.

Convenções semânticas de RL e indicadores de ouro

Esta seção lista as métricas do OpenTelemetry que podem ajudar você a identificar problemas que ocorrem quando o aplicativo de RL é executado no GKE.

Use as informações desta seção para fazer o seguinte:

  • Decida quais métricas e rastreamentos coletar para seu aplicativo.
  • Decida como visualizar e usar as métricas e os dados de rastreamento coletados do seu aplicativo.

Para monitorar com eficiência as cargas de trabalho de RL usando o OpenTelemetry, é útil se concentrar nos "indicadores de ouro". Os indicadores de ouro são as quatro métricas principais de um serviço que fornecem uma visão geral de alto nível da integridade dele: latência, tráfego, erros e saturação. Ao instrumentar seu aplicativo de RL com essas métricas, você pode entender e depurar rapidamente problemas de desempenho.

As seções a seguir têm as convenções semânticas e os nomes de métricas categorizados pelos indicadores de ouro que representam em um contexto de RL.

Convenções semânticas de RL

Estes são atributos das suas métricas. Esses atributos fornecem contexto para filtragem e análise no Monitoring.

  • RL_SYSTEM = "rl.system": o nome do sistema ou framework de RL (por exemplo, "MyCustomRL").
  • RL_SYSTEM_VERSION = "rl.system.version": versão do sistema de RL.
  • RL_RUN_ID = "rl.run.id": identificador exclusivo de uma execução de treinamento específica.
  • RL_ALGORITHM = "rl.algorithm": o algoritmo de RL usado (por exemplo, "PPO", "DQN").
  • RL_ENVIRONMENT_NAME = "rl.environment.name": o nome do ambiente de RL (por exemplo, "CartPole-v1").
  • RL_MODEL_NAME = "rl.model.name": o nome ou identificador do modelo de política/valor.
  • RL_LOOP = "rl.loop": identificador do loop de treinamento principal.
  • RL_LOOP_ITERATION = "rl.loop.iteration": número da iteração atual do loop de RL.
  • RL_SAMPLE = "rl.sample": contexto para a fase de amostragem.
  • RL_SAMPLE_EPISODES = "rl.sample.episodes": número de episódios de amostra.
  • RL_SAMPLE_STEPS = "rl.sample.steps": número de etapas de amostragem.
  • RL_SAMPLE_BATCH_SIZE = "rl.sample.batch_size": tamanho do lote usado durante a amostragem.
  • RL_REWARD = "rl.reward": contexto para cálculo da recompensa.
  • RL_REWARD_BATCH_SIZE = "rl.reward.batch_size": tamanho do lote para cálculo da recompensa.
  • RL_REWARD_SANDBOX = "rl.reward.sandbox": identificador do sandbox de cálculo de recompensa.
  • RL_TRAIN = "rl.train": contexto para a fase de treinamento.
  • RL_TRAIN_STEPS = "rl.train.steps": número de etapas de treinamento.
  • RL_TRAIN_BATCH_SIZE = "rl.train.batch_size": tamanho do lote usado durante o treinamento.
  • RL_TRAIN_TOKENS = "rl.train.tokens": número de tokens processados durante o treinamento.
  • RL_SYNC = "rl.sync": contexto para operações de sincronização.
  • RL_SYNC_BYTES = "rl.sync.bytes": bytes transferidos durante a sincronização.
  • RL_SYNC_SOURCE = "rl.sync.source": origem da sincronização.
  • RL_SYNC_DESTINATION = "rl.sync.destination": Destination of the synchronization.

Indicadores de ouro e métricas de RL

As seções a seguir listam as métricas de RL relacionadas aos quatro indicadores de ouro: latência, tráfego, erros e saturação.

Para detalhes sobre os indicadores de ouro, consulte Os quatro indicadores de ouro no capítulo 6 do livro Google Site Reliability Engineering (SRE).

Latência

Quanto tempo leva para concluir as principais operações? Latência alta pode indicar atrasos na conclusão de operações importantes. As métricas a seguir podem ajudar a identificar problemas de latência que ocorrem quando o aplicativo de RL é executado no GKE.

  • rl.loop.duration (histograma): uma duração longa do loop atrasa todo o processo de treinamento. O monitoramento ajuda a identificar regressões de desempenho em qualquer parte do ciclo de RL.
  • rl.sample.duration (histograma): a amostragem lenta afeta diretamente a velocidade com que novos dados são gerados para treinamento.
  • rl.reward.duration (histograma): o cálculo da recompensa pode ser complexo. Rastrear a latência ajuda a otimizar essa etapa crítica.
  • rl.train.duration (histograma): o tempo de treinamento é crucial para a velocidade de iteração. Picos aqui podem indicar problemas no algoritmo de treinamento ou no hardware.
  • rl.sync.duration (histograma): a sincronização eficiente é vital no RL distribuído. Tempos de sincronização longos podem causar dados desatualizados e diminuir o aprendizado.
  • rl.step.duration (histograma): latência granular de etapas individuais do ambiente.

Tráfego e capacidade de processamento

Quanto trabalho está sendo feito? Uma baixa capacidade de processamento pode significar uso ineficiente de recursos. As métricas a seguir podem ajudar você a identificar problemas com tráfego ou capacidade de processamento que ocorrem quando o aplicativo de RL é executado no GKE.

  • rl.sample.samples (contador): representa o volume de dados de experiência coletados. Uma queda indica problemas no processo de amostragem.
  • rl.sample.episodes (contador): rastreia o número de episódios completos executados.
  • rl.train.steps (contador): mede o progresso do treinamento em termos de etapas de otimização.
  • rl.train.tokens (contador): rastreia o total de tokens processados. Essa métrica é relevante para o RL de modelos grandes.
  • rl.tokens.rate / rl.tokens.rate_per_gpu (medição/taxa): medidas diretas de velocidade e eficiência do treinamento, principalmente em modelos baseados em tokens.
  • rl.samples.rate / rl.samples.rate_per_gpu (medidor/taxa): mede a velocidade com que o sistema coleta novas amostras.

Erros

Há erros de desempenho ou de execução? Na RL, os "erros" podem se manifestar como comportamento inesperado ou desempenho ruim. As métricas a seguir podem ajudar você a identificar erros que ocorrem quando o aplicativo de RL é executado no GKE.

  • rl.environment.reward.mean (medidor): embora não seja um erro tradicional, uma queda drástica na recompensa média é um sinal crítico de que algo está errado com a interação do agente ou do ambiente. Essa métrica reflete diretamente o progresso do aprendizado e a performance do agente.
  • rl.environment.episode.length.mean (Medidor): semelhante à recompensa, mudanças inesperadas na duração do episódio podem indicar problemas.
  • rl.train.loss (medidor): um aumento repentino ou um comportamento errático na perda de treinamento indica que o modelo não está aprendendo de maneira eficaz. Indicador fundamental de estabilidade e sucesso do treinamento.

Saturação

O sistema está sobrecarregado? A alta saturação pode levar à degradação da performance. A métrica a seguir pode ajudar você a identificar problemas de saturação que ocorrem quando o aplicativo de RL é executado no GKE.

  • rl.train.mfu (Gauge): utilização de ponto flutuante do modelo (MFU, na sigla em inglês). Indica a eficiência com que os recursos de computação (como GPUs ou TPUs) estão sendo usados durante o treinamento. Um MFU baixo sugere subutilização ou gargalos.

A seguir