Observabilidade para Sistemas de LLM: Métricas, Rastreamentos, Logs e Testes em Produção

Sistemas de LLM falham de formas que o monitoramento tradicional de API não pode detectar — filas enchem-se silenciosamente, a memória da GPU se enche antes que o CPU pareça ocupado, e a latência explode na camada de lotes, e não na camada de aplicação. Este guia abrange uma estratégia de observabilidade de ponta a ponta para a inferência de LLM e aplicações de LLM: o que medir, como instrumentar com Prometheus, OpenTelemetry e Grafana, e como implantar o pipeline de telemetria em larga escala.

TL;DR (Resumo executivo)

Sistemas de LLM degradam-se de formas que o monitoramento clássico “latência HTTP + taxa de erro” não pode explicar. A Observabilidade de sistemas de LLM de produção deve responder rapidamente e defensivamente:

• Se a experiência do usuário está se deteriorando (latência de cauda, tempo até o primeiro token, latência entre tokens, erros e interrupções).
• Onde o tempo é gasto (fila vs lotes vs execução do modelo; recuperação/ferramentas/filtros de segurança vs inferência).
• O que se enche primeiro (utilização da GPU e pressão de memória, pressão da fila/KV-cache, tokenização do CPU).
• Como custo e capacidade se desviam (tokens por solicitação, tokens por segundo por GPU, taxa de acerto em cache, gerações desperdiçadas).
• Se a telemetria é segura para armazenar (prompt pode conter PII; evite vazamento de dados sensíveis em logs/atributos).

O design mais resiliente é um pipeline com múltiplos sinais:

• Métricas para detecção rápida e planejamento de capacidade (Prometheus + PromQL; armazenamento de longo prazo opcional via Thanos/Cortex/Mimir/VictoriaMetrics).
• Trilhas para causalidade no nível da solicitação (OpenTelemetry com OTLP; backends como Tempo/Jaeger/Zipkin/Elastic APM).
• Logs para contexto, correlacionados a trilhas (Loki/Elastic/OpenSearch), projetados para metadados de baixa cardinalidade.
• Perfilamento para hotspots de CPU/memória e latência de cauda (Grafana Pyroscope).
• Testes sintéticos + de carga para detectar regressões antes que os usuários percebam (Grafana k6; probing do tipo blackbox).
• SLOs para medir resultados do usuário e impulsionar alertas ações (orçamento de erros; estilo de taxa de queima).

O que torna a observabilidade para sistemas de LLM diferente

Nota de escopo: o framework de LLM-alvo é não especificado. Exemplos neste artigo abrangem servidores/frameworks comuns (Triton, vLLM, TGI, LangChain/LangSmith) e permanecem aplicáveis a outros stacks substituindo métricas e spans equivalentes.

LLMs introduzem comportamentos operacionais que diferem dos serviços web convencionais:

• Trabalho variável por solicitação: contagens de tokens (entrada/saída) variam amplamente, então “solicitações por segundo” podem parecer estáveis enquanto a throughput de tokens colapsa. TGI e vLLM exportam explicitamente métricas e telemetria relacionadas a tokens e latência de tokens para apoiar este estilo de monitoramento.
• Fila + lotes contínuos: o throughput depende de disciplinas de lotes/filas; tamanho da fila e tamanho do lote tornam-se indicadores de primeira classe (TGI expõe ambos).
• Experiência de streaming: os usuários se preocupam com TTFT e latência entre tokens pelo menos tanto quanto com o tempo de resposta completo; o OpenTelemetry até padroniza métricas do servidor TTFT/tempo por token sob convenções semânticas de GenAI.
• Pressão da GPU domina os modos de falha: utilização da GPU e memória da GPU (incluindo memória usada) são centrais para a confiabilidade; o exportador DCGM da NVIDIA existe especificamente para expor telemetria da GPU em um ponto de extremidade /metrics do Prometheus.
• Pipelines de múltiplas etapas: recuperação, chamadas de ferramentas, filtros de segurança e pós-processamento significam que a latência de ponta a ponta é uma composição de múltiplos spans/filas — tornando o rastreamento distribuído e o projeto cuidadoso de métricas essenciais.

Exemplos concretos de servidores de inferência populares destacam isso:

• Servidor de inferência NVIDIA Triton expõe métricas como texto plano via /metrics (comumente :8002/metrics) e fornece bandeiras para habilitar/desabilitar métricas e selecionar uma porta de métricas.
• vLLM expõe um ponto de extremidade extenso do Prometheus /metrics com o prefixo vllm:; sua documentação inclui contadores para tokens de geração e histogramas como tempo até o primeiro token.
• Hugging Face TGI documenta um ponto de extremidade /metrics com tamanho da fila, tamanho do lote, duração da solicitação de ponta a ponta, tokens gerados e duração da fila.

Tarefas centrais de observabilidade e telemetria necessária para LLM

A observabilidade para sistemas de LLM é mais fácil de implementar quando você mapeia tarefas → sinais → ferramentas e, em seguida, restringe cardinalidade e amostragem desde o primeiro dia.

Métricas: Para sistemas de servidores online, as próprias diretrizes de instrumentação do Prometheus destacam a contagem de consultas, erros e latência como métricas-chave; LLMs expandem isso com TTFT, throughput/latência por token, comprimento da fila, tamanho do lote e utilização da GPU.

Trilhas: Trilhas são como você atribui latência e falhas entre etapas de recuperação/ferramentas/safe/inferência; o OpenTelemetry estrutura trilhas/exportadores como uma forma neutra de emissão e envio de telemetria para coletores ou backends.

Logs: Logs fornecem contexto legível por humanos e “por que”, mas só permanecem úteis em larga escala se você evitar o indexamento de valores ilimitados (exemplo: Loki indexa rótulos apenas e armazena blocos comprimidos de logs em armazenamento de objetos).

Perfilamento: O perfilamento contínuo captura comportamento de CPU/memória em produção com amostragem de baixo custo; o Grafana Pyroscope é posicionado especificamente para isso.

Testes sintéticos e de carga: O Grafana k6 é uma ferramenta de teste de carga de código aberto, e o Grafana nota que o Monitoramento Sintético é alimentado pelo k6 e vai além de verificação de protocolo simples.

SLOs: As diretrizes de SRE da Google definem um SLO como um valor/intervalo de alvo para um nível de serviço medido por um SLI, e fornece diretrizes para alertar sobre SLOs (trade-offs de precisão/revocação/tempo de detecção).

Blueprints de métricas centrais de LLM

Convenções semânticas de GenAI do OpenTelemetry para padronização

O OpenTelemetry fornece convenções semânticas de GenAI (status: “Desenvolvimento”) com nomes padronizados para métricas de GenAI, como:

• gen_ai.client.token.usage e gen_ai.client.operation.duration
• gen_ai.server.request.duration, gen_ai.server.time_per_output_token, e gen_ai.server.time_to_first_token

Essa padronização é um levar prático para estratégias portáveis de “monitoramento de modelos LLM com OpenTelemetry”: emita uma vez e roteie a mesma telemetria para backends de código aberto ou fornecedores mais tarde.

Designando o pipeline de telemetria

Puxar vs empurrar

O Prometheus é baseado em puxar. Processos expõem métricas em um formato de exposição suportado, e o Prometheus as puxa de acordo com empregos de coleta configurados.

Empurrar é para exceções. O guia “Quando usar o Pushgateway” do Prometheus recomenda explicitamente o Pushgateway apenas em casos limitados (não como substituição geral para empurrar), e o README do Pushgateway enfatiza que ele não pode “transformar o Prometheus em um sistema de monitoramento baseado em empurrar”.

Padrão prático específico para LLM:

• Use puxar para servidores de inferência/exportadores (pontos de extremidade de métricas do Triton/vLLM/TGI; exportador DCGM; métricas do nó).
• Use OTLP empurrar para trilhas/logs/métricas OTel (O protocolo OpenTelemetry define transporte/encoding/delivery entre fontes, coletores e backends).
• Use escrita remota ao escalar além de um único Prometheus (o Prometheus fornece orientação de ajuste de escrita remota; Mimir/Thanos/Cortex fornecem opções de armazenamento de longo prazo e/ou HA).

Agente vs sidecar vs coletores de gateway

O OpenTelemetry documenta um padrão de implantação de agente, onde a telemetria é enviada para um Coletor que está executando ao lado da aplicação ou no mesmo host (sidecar/DaemonSet), depois exportada.

Para Kubernetes, a injeção de sidecar é suportada via o Operador OpenTelemetry (injeção baseada em anotação).

Regra prática para pilhas de LLM:

• Use um agente DaemonSet para enriquecimento de nível de host e pipelines compartilhados entre muitos pods.
• Use um sidecar quando você precisar de isolamento estrito por carga de trabalho ou filtragem local dedicada (comum quando prompts podem conter dados sensíveis).
• Use um coletor de gateway para amostragem de cauda centralizada, lotes, retenções e exportação de fã-out.

Amostragem e controle de cardinalidade

O OpenTelemetry esclarece que a amostragem de cauda permite decisões de amostragem usando critérios derivados de uma trilha (não possível com amostragem de cabeça sozinha).

As diretrizes de instrumentação do Prometheus alertam contra o uso excessivo de rótulos, fornecem uma regra de dedo para manter a cardinalidade baixa e aconselham redesenhar métricas se a cardinalidade potencial exceder ~100.

“Armadilhas de cardinalidade” específicas de LLM para banir cedo:

• Texto de prompt, texto de resposta, IDs de conversa, IDs de solicitação como rótulos/atributos.
• Blobs de argumentos de ferramenta como atributos de span.
• “user_id” ilimitados como rótulos.

Prefira dimensões limitadas: modelo, família do modelo, endpoint, região, código de status, implantação, inquilino (apenas se limitado).

Comparação de ferramentas de observabilidade de LLM

Ferramentas mapeadas para tarefas de observabilidade

Grafana vs alternativas para visualização

• Dashboards da Grafana são compostos por painéis que consultam fontes de dados (incluindo Loki e Mimir) para produzir gráficos e visualizações.
• Kibana fornece dashboards/visualizações como camada de interface do Elastic Stack.
• OpenSearch Dashboards fornece ferramentas de visualização de dados para OpenSearch.
• A documentação da InfluxData posiciona o Chronograf como componente de visualização dentro do ecossistema Influx.

Prometheus vs alternativas para backends de métricas

• Armazenamento local padrão do Prometheus: se bandeiras de retenção não forem definidas, a retenção padrão é de 15d (planeje retenção/custo cedo).
• Grafana Mimir é descrito como armazenamento de longa duração, HA, multi-inquilino para métricas do Prometheus e OpenTelemetry, escalável horizontalmente.
• Thanos é descrito como uma configuração de Prometheus altamente disponível com capacidades de armazenamento de longa duração.
• Cortex descreve-se como uma solução de armazenamento de longa duração, HA, multi-inquilino horizontalmente escalável para métricas do Prometheus e OpenTe乐.
• VictoriaMetrics Cloud documenta a integração de escrita remota do Prometheus para armazenamento de longa duração.
• O Serviço Gerenciado do Amazon para Prometheus descreve uma oferta gerenciada que escala com necessidades de ingestão/consulta e suporta PromQL e escrita remota.

Cozinheiro prático de implementação

Nomes e tipos de métricas para implementar hoje

As convenções semânticas de GenAI do OpenTelemetry (status: Desenvolvimento) definem nomes de métricas que você pode padronizar imediatamente:

• gen_ai.client.token.usage
• gen_ai.client.operation.duration
• gen_ai.server.request.duration
• gen_ai.server.time_per_output_token
• gen_ai.server.time_to_first_token

Exemplos de servidor que você pode coletar imediatamente:

• O ponto de extremidade do Prometheus do vLLM inclui contadores (ex: total de tokens de geração) e histogramas (TTFT) e documenta uma estratégia de rótulo model_name.
• O TGI documenta métricas incluindo tamanho da fila, duração da solicitação, tokens gerados e tempo médio por token.
• O Triton documenta a exposição /metrics e interruptores de métrica.

Exemplos de PromQL para dashboards de latência e throughput de LLM

# p95 latência de ponta a ponta para um histograma de aplicação
histogram_quantile(
  0.95,
  sum(rate(llm_request_latency_seconds_bucket[5m])) by (le, model)
)

# Taxa de erro em porcentagem (5xx)
100 *
(
  sum(rate(llm_requests_total{status_code=~"5.."}[5m]))
  /
  sum(rate(llm_requests_total[5m]))
)

# Tokens/sec (saída) em todos os modelos
sum(rate(llm_tokens_total{direction="out"}[5m]))

# Tamanho da fila TGI (gauge)
max(tgi_queue_size) by (instance)

# p95 TTFT do vLLM
histogram_quantile(
  0.95,
  sum(rate(vllm:time_to_first_token_seconds_bucket[5m])) by (le, model_name)
)

As diretrizes do histograma do Prometheus explicam que os quantis de histograma são calculados no lado do servidor a partir de baldes usando histogram_quantile().

Notas de instrumentação do OpenTelemetry para sistemas de LLM

• OTLP é o Protocolo OpenTelemetry que especifica como a telemetria é codificada/transportada entre fontes, coletores e backends.
• A documentação de configuração do SDK do OpenTelemetry documenta variáveis de ambiente como OTEL_EXPORTER_OTLP_ENDPOINT (e opções de protocolo) para exportar telemetria.
• A documentação do contributo do OpenTelemetry Python documenta suporte à instrumentação automática e manual para FastAPI.
• As convenções semânticas GenAI incluem um mecanismo de estabilidade opt-in via OTEL_SEMCONV_STABILITY_OPT_IN para migração de convenções GenAI.

Exemplo curto de Python: métricas + trilhas + logs

O snippet abaixo demonstra:

• Exposição de métricas do Prometheus (/metrics) para “monitoramento de inferência de LLM com Prometheus”
• Trilhas exportadas via OTLP (neutro de fornecedor)
• Logs estruturados correlacionados com contexto de trilha, com um padrão seguro de privacidade (não logar prompts brutos)

import logging
import time

from fastapi import FastAPI, Request
from pydantic import BaseModel

# Prometheus (métricas baseadas em puxar)
from prometheus_client import Counter, Histogram, generate_latest, CONTENT_TYPE_LATEST
from starlette.responses import Response

# OpenTelemetry (exportação OTLP de trilhas)
from opentelemetry import trace
from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter

app = FastAPI(title="API de Inferência de LLM", version="1.0.0")
FastAPIInstrumentor.instrument_app(app)

# --- Logging (padrão seguro de privacidade) ---
logger = logging.getLogger("llm")
logging.basicConfig(level=logging.INFO, format="%(message)s")

def trace_id_hex() -> str:
    span = trace.get_current_span()
    ctx = span.get_span_context()
    return format(ctx.trace_id, "032x") if ctx.is_valid else ""

# --- Métricas do Prometheus ---
LLM_REQUESTS = Counter(
    "llm_requests_total",
    "Total de solicitações LLM",
    ["rota", "código de status", "modelo"],
)
LLM_LATENCY = Histogram(
    "llm_request_latency_seconds",
    "Latência de solicitação de LLM de ponta a ponta (segundos)",
    ["rota", "modelo"],
    buckets=(0.1, 0.2, 0.35, 0.5, 0.75, 1, 1.5, 2, 3, 5, 8, 13),
)

# --- Fornecedor de tracer do OpenTelemetry ---
resource = Resource.create({"service.name": "llm-inference-api"})
trace.set_tracer_provider(TracerProvider(resource=resource))
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter())  # configure via OTEL_EXPORTER_OTLP_* variáveis de ambiente
)
tracer = trace.get_tracer(__name__)

class GenerateRequest(BaseModel):
    prompt: str
    modelo: str = "não especificado"
    max_tokens: int = 256

class GenerateResponse(BaseModel):
    modelo: str
    output: str
    latency_ms: int

@app.post("/v1/generate", response_model=GenerateResponse)
async def generate(req: GenerateRequest, request: Request):
    rota = "/v1/generate"
    start = time.perf_counter()

    with tracer.start_as_current_span("llm.generate") as span:
        # Evite logar o prompt completo; emita metadados seguros
        span.set_attribute("gen_ai.request.model", req.modelo)
        span.set_attribute("gen_ai.request.max_tokens", req.max_tokens)

        # Substitua pela chamada real do LLM (cliente Triton/vLLM/TGI)
        time.sleep(0.15)
        output = "Olá do modelo."

        latency_s = time.perf_counter() - start
        LLM_LATENCY.labels(rota=rota, modelo=req.modelo).observe(latency_s)
        LLM_REQUESTS.labels(rota=rota, status_code="200", modelo=req.modelo).inc()

        logger.info(
            {
                "msg": "llm_request_complete",
                "trace_id": trace_id_hex(),
                "modelo": req.modelo,
                "latency_ms": int(latency_s * 1000),
                # Não inclua prompt/output bruto a menos que a política o permita.
            }
        )

        return GenerateResponse(modelo=req.modelo, output=output, latency_ms=int(latency_s * 1000))

@app.get("/metrics")
def metrics():
    return Response(generate_latest(), media_type=CONTENT_TYPE_LATEST)

Implantação, escala, segurança e solução de problemas

Opções de implantação

Escalabilidade e retenção: restrições práticas

• Armazenamento local do Prometheus: sem bandeiras de tamanho/tempo explícitas, o tempo de retenção padrão é de 15d.
• Escrita remota do Prometheus: o Prometheus documenta ajustes de escrita remota para escalar além de “padrões razoáveis”.
• Grafana Tempo: posicionado como backend de trilhas de grande escala e pode gerar métricas a partir de spans usando o gerador de métricas (escrita remota para uma fonte de dados Prometheus).
• Armazenamento do Loki: os documentos do Loki enfatizam indexação de rótulos apenas e armazenamento de blocos comprimidos (armazenamento de objetos), tornando a estratégia de rótulo central para escala e custo.

Segurança e privacidade: prompts podem conter PII

As diretrizes de segurança do OpenTelemetry destacam que a coleta de telemetria pode acidentalmente capturar informações sensíveis/pessoais; você é responsável por lidar com isso apropriadamente.

As diretrizes de segurança do Prometheus alertam que endpoints do Prometheus não devem ser expostos a redes acessíveis publicamente (como a internet) porque eles servem informações sobre sistemas monitorados.

Controles de privacidade operacionais que mantêm “observabilidade para sistemas de LLM” seguros:

• Padrão para não logar prompts/respostas brutos; logar contagens de tokens, nome do modelo, latência e IDs de trilha em vez disso.
• Redigir/dropar atributos sensíveis em coletores/pipelines (filtragem de nível de coletor é uma abordagem comum em ecossistemas).
• Impor RBAC e políticas de retenção para logs/trilhas; considere varreduras de dados sensíveis onde apropriado (ex: fornecedores documentam varreduras de telemetria).

Checklist de solução de problemas

Se seu dashboard de latência de LLM da Grafana parece errado, debugue nesta ordem:

• Saúde de ingestão
  • Prometheus: valide sucesso de coleta e semântica de configuração (a configuração do Prometheus define empregos de coleta/instâncias).
  • OTLP: confirme configuração do endpoint do exportador (SDKs usam OTEL_EXPORTER_OTLP_ENDPOINT, configurações de protocolo).
• Desmatch de schema
  • O dashboard espera modelo, mas seu servidor emite model_name (vLLM documenta explicitamente rótulos model_name).
• Explosão de cardinalidade
  • Alguém rotulou por IDs de solicitação/hashes de prompt; o Prometheus alerta que conjuntos de rótulos aumentam custos de RAM/CPU/disco/rede e fornece diretrizes de cardinalidade.
• Uso incorreto de histograma
  • Certifique-se de calcular quantis a partir de séries _bucket com rate() e le; o Prometheus explica trade-offs no cálculo de quantil de histograma.
• Gaps de amostragem de trilha
  • Se você amostrar a cabeça muito agressivamente, trilhas lentas/erradas raras desaparecem; a amostragem de cauda retém “trilhas importantes” com base em critérios de trilhas completas.
• Problemas de métricas de span do Tempo
  • Se usando métricas-generator e span-métricas do Tempo, confirme que está habilitado e ajustado (o Tempo documenta métricas-generator e span-métricas processadores; existem soluções de problemas para problemas do gerador).
• Métricas de GPU ausentes
  • Confirme que o exportador DCGM está implantado e /metrics está acessível (o exportador DCGM expõe métricas da GPU via HTTP para o Prometheus).

Links úteis

• Observabilidade: Guia de Monitoramento, Métricas, Prometheus & Grafana
• Monitoramento com Prometheus: Configuração & Práticas Recomendadas
• Desempenho de LLM: Benchmarks, Bottlenecks & Otimização
• Host de LLM: Comparação de Local, Auto-hospedado e Infraestrutura em Nuvem
• Tutorial passo a passo de RAG
• Documentação de configuração do Prometheus
• Formatos de exposição do Prometheus
• Melhores práticas de instrumentação do Prometheus
• Nomeação de métricas do Prometheus
• Histogramas e resumos do Prometheus
• Regras de alerta do Prometheus
• Visão geral de alertas do Prometheus
• Configuração do Alertmanager
• Modelo JSON do dashboard do Grafana
• Provisionamento do Grafana
• Métricas do servidor de inferência NVIDIA Triton
• API de métricas do TorchServe
• Exportador DCGM da NVIDIA
• Gráfico Helm do kube-prometheus-stack
• Começando com o Operador Prometheus
• Especificações do exportador Prometheus do OpenTelemetry
• Guia do Prometheus para receber OTLP
• Rastreamento com OpenTelemetry no LangSmith