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

Os sistemas de LLM falham de maneiras que a monitorização tradicional de APIs não consegue revelar — as filas enchem-se silenciosamente, a memória da GPU satura-se muito antes de a CPU parecer ocupada e a latência explode na camada de loteamento (batching) em vez da camada de aplicação.

Este guia abrange uma estratégia de observabilidade para 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 escala.

Stacks completas de assistentes adicionam recuperação, chamadas de ferramentas e roteamento por cima da inferência bruta; a Arquitetura de Assistente de IA mapeia onde a observabilidade se encaixa entre essas camadas.

TL;DR (Resumo executivo)

Os sistemas de LLM degradam-se de maneiras que a monitorização clássica de “latência HTTP + taxa de erro” não consegue explicar. A Observabilidade para sistemas de LLM de nível de produção deve responder, rapidamente e de forma defensável:

• Se a experiência do utilizador está a degradar (latência de cauda, tempo até ao primeiro token, latência inter-token, erros e abortos).
• Onde o tempo é gasto (fila vs loteamento vs execução do modelo; recuperação/filtros de segurança vs inferência).
• O que satura primeiro (utilização da GPU e pressão de memória, pressão de cache KV/fila, tokenização da CPU).
• Como o custo e a capacidade se desviam (tokens por pedido, tokens/seg por GPU, taxa de acerto no cache, gerações desperdiçadas).
• Se a telemetria é segura para armazenar (os prompts podem conter PII; prevenir fugas sensíveis para registos/atributos).

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

• Métricas para deteção rápida e planeamento de capacidade (Prometheus + PromQL; armazenamento a longo termo opcional via Thanos/Cortex/Mimir/VictoriaMetrics).
• Traços para causalidade a nível de pedido (OpenTelemetry com OTLP; backends como Tempo/Jaeger/Zipkin/Elastic APM).
• Registos para contexto, correlacionados com traços (Loki/Elastic/OpenSearch), desenhados para metadados de baixa cardinalidade.
• Perfilamento para pontos quentes de CPU/memória e latência de cauda (Grafana Pyroscope).
• Testes sintéticos e de carga para detetar regressões antes dos utilizadores (Grafana k6; sondagem estilo caixa preta).
• SLOs para medir resultados do utilizador e impulsionar alertas acionáveis (orçamentos de erro; estilo taxa de consumo).

O que torna a observabilidade para sistemas de LLM diferente

Nota de âmbito: o framework de LLM alvo é não especificado. Os exemplos neste artigo cobrem servidores/frameworks comuns (Triton, vLLM, TGI, LangChain/LangSmith) e permanecem aplicáveis a outras stacks substituindo métricas e spans equivalentes.

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

• Trabalho variável por pedido: as contagens de tokens (entrada/saída) variam amplamente, pelo que “pedidos por segundo” pode parecer estável enquanto o throughput de tokens colapsa. O TGI e o vLLM exportam explicitamente telemetria relacionada com tokens e latência de tokens para suportar este estilo de monitorização.
• Enfileiramento + loteamento contínuo: o throughput depende de disciplinas de loteamento/enfileiramento; o tamanho da fila e o tamanho do lote tornam-se indicadores de primeira classe (o TGI expõe ambos).
• UX de streaming: os utilizadores preocupam-se com o TTFT e a latência inter-token tanto quanto com o tempo total de resposta; o OpenTelemetry até padroniza métricas de servidor TTFT/tempo por token sob convenções semânticas de GenAI.
• A pressão da GPU domina os modos de falha: a utilização da GPU e a memória da GPU (incluindo memória utilizada) são centrais para a fiabilidade; o exporter DCGM da NVIDIA existe especificamente para expor telemetria da GPU num endpoint /metrics do Prometheus.
• Pipelines multi-etapa: recuperação, chamadas de ferramentas, filtros de segurança e pós-processamento significam que a latência ponta-a-ponta é uma composição de múltiplos spans/filas—tornando o rastreio distribuído e o design cuidadoso de métricas essenciais.

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

• O NVIDIA Triton Inference Server expõe métricas como texto simples via /metrics (comumente :8002/metrics) e fornece flags para ativar/desativar métricas e selecionar uma porta de métricas.
• O vLLM expõe um endpoint extenso de /metrics do Prometheus com um prefixo vllm:; a sua documentação inclui contadores para tokens de geração e histograms como tempo até ao primeiro token.
• O Hugging Face TGI documenta um endpoint /metrics com tamanho da fila, tamanho do lote, duração do pedido ponta-a-ponta, tokens gerados e duração da fila.

Tarefas principais de observabilidade e telemetria de LLM necessária

A Observabilidade para sistemas de LLM é mais fácil de implementar quando mapeia tarefas → sinais → ferramentas, e depois restringe a cardinalidade e a amostragem desde o primeiro dia.

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

Traços: Os traços são como você atribui latência e falhas através das etapas de recuperação/ferramentas/segurança/inferência; o OpenTelemetry enquadra traços/exportadores como uma forma neutra de fornecedor para emitir e enviar telemetria para coletores ou backends.

Registos: Os registos fornecem contexto legível por humanos e o “porquê”, mas só permanecem utilizáveis em escala se você evitar indexar valores ilimitados (exemplo: o Loki indexa apenas rótulos e armazena blocos de registos comprimidos em armazenamento de objetos).

Perfilamento: O perfilamento contínuo captura comportamento de CPU/memória de produção com amostragem de baixa sobrecarga; o Grafana Pyroscope é posicionado explicitamente 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ções simples de protocolo.

SLOs: A orientação SRE do Google define um SLO como um valor/faixa alvo para um nível de serviço medido por um SLI, e fornece orientação para alerta em SLOs (compensações precisão/recall/tempo de deteção).

Esquema chave de métricas 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 nomenclatura padrão para métricas de GenAI, tais 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

Esta padronização é uma alavanca prática para estratégias portáveis de “monitorização de modelos de LLM com OpenTelemetry”: emitir uma vez e encaminhar a mesma telemetria para backends OSS ou de fornecedores posteriormente.

Projetando o pipeline de telemetria

Pull vs push

O Prometheus é pull-first. Os processos expõem métricas num formato de exposição suportado, e o Prometheus raspa-os de acordo com os trabalhos de raspagem configurados.

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

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

• Usar pull para servidores de inferência/exporters (endpoints de métricas Triton/vLLM/TGI; exporter DCGM; métricas do nó).
• Usar push OTLP para traços/registos/métricas OTel (o Protocolo OpenTelemetry define transporte/codificação/entrega entre fontes, coletores e backends).
• Usar remote write 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 a longo termo e/ou HA).

Agentes vs sidecars vs coletores de gateway

O OpenTelemetry documenta um padrão de implantação de agente, onde a telemetria é enviada para um Collector executado junto da aplicação ou no mesmo host (sidecar/DaemonSet), e depois exportado.

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

Regra prática pragmática para stacks de LLM:

• Usar um agente DaemonSet para enriquecimento a nível de host e pipelines partilhados entre muitos pods.
• Usar um sidecar quando você precisa de isolamento estrito por workload ou filtragem local dedicada (comum quando os prompts podem conter dados sensíveis).
• Usar um coletor de gateway para amostragem de cauda centralizada, loteamento, repetições e exportação em leque.

Amostragem e controlo de cardinalidade

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

A orientação de instrumentação do Prometheus adverte contra o uso excessivo de rótulos, fornece uma regra prática para manter a cardinalidade baixa e aconselha o redesenho de métricas se a cardinalidade potencial exceder ~100.

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

• Texto do prompt, texto da resposta, IDs de conversa, IDs de pedido como rótulos/atributos.
• Blobs de argumentos de ferramentas como atributos de span.
• Rótulos “user_id” ilimitados.

Prefira dimensões limitadas: model, model_family, endpoint, region, status_code, deployment, tenant (apenas se limitado).

Comparação de ferramentas de observabilidade de LLM

Ferramentas mapeadas para tarefas de observabilidade

Grafana vs alternativas para visualização

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

Prometheus vs alternativas para backends de métricas

• Armazenamento local do Prometheus: se as flags de retenção não estiverem definidas, a retenção padrão é de 15d (planeie retenção/custo cedo).
• O Grafana Mimir é descrito como armazenamento a longo termo horizontalmente escalável, HA, multi-tenant para métricas do Prometheus e OpenTelemetry.
• O Thanos é descrito como uma configuração de alta disponibilidade do Prometheus com capacidades de armazenamento a longo termo.
• O Cortex descreve-se como uma solução de armazenamento a longo termo horizontalmente escalável, HA, multi-tenant para métricas do Prometheus e OpenTelemetry.
• A VictoriaMetrics Cloud documenta a integração de escrita remota do Prometheus para armazenamento a longo termo.
• O Amazon Managed Service for Prometheus descreve uma oferta gerida que escala com as necessidades de ingestão/consulta e suporta PromQL e escrita remota.

Livro de receitas de implementação prática

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 do lado do servidor que você pode raspar imediatamente:

• O endpoint 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 do pedido, tokens gerados e tempo médio por token.
• O Triton documenta exposição /metrics e alternadores de métricas.

Exemplos de PromQL para painéis de latência e throughput de LLM

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

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

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

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

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

A orientação de histograma do Prometheus explica que os quantis de histograma são computados no lado do servidor a partir de buckets usando histogram_quantile().

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

• O OTLP é o Protocolo OpenTelemetry que especifica como a telemetria é codificada/transmitida entre fontes, coletores e backends.
• A documentação de configuração do SDK OpenTelemetry documenta variáveis de ambiente como OTEL_EXPORTER_OTLP_ENDPOINT (e opções de protocolo) para exportar telemetria.
• O OpenTelemetry Python contrib documenta suporte de instrumentação FastAPI para instrumentação automática e manual.
• 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 em Python: métricas + traços + registos

O snippet abaixo demonstra:

• Exposição de métricas Prometheus (/metrics) para “monitorização de inferência de LLM com Prometheus”
• Traços do OpenTelemetry exportados via OTLP (neutro de fornecedor)
• Registos estruturados correlacionados com contexto de traço, com um padrão seguro de privacidade (não registar prompts brutos)

import logging
import time

from fastapi import FastAPI, Request
from pydantic import BaseModel

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

# OpenTelemetry (traços OTLP)
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="LLM Inference API", 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 Prometheus ---
LLM_REQUESTS = Counter(
    "llm_requests_total",
    "Total de pedidos LLM",
    ["route", "status_code", "model"],
)
LLM_LATENCY = Histogram(
    "llm_request_latency_seconds",
    "Latência ponta-a-ponta do pedido LLM (segundos)",
    ["route", "model"],
    buckets=(0.1, 0.2, 0.35, 0.5, 0.75, 1, 1.5, 2, 3, 5, 8, 13),
)

# --- Fornecedor de rastreador 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())  # configurar via variáveis de ambiente OTEL_EXPORTER_OTLP_*
)
tracer = trace.get_tracer(__name__)

class GenerateRequest(BaseModel):
    prompt: str
    model: str = "unspecified"
    max_tokens: int = 256

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

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

    with tracer.start_as_current_span("llm.generate") as span:
        # Evitar registar o prompt completo; emitir metadados seguros
        span.set_attribute("gen_ai.request.model", req.model)
        span.set_attribute("gen_ai.request.max_tokens", req.max_tokens)

        # Substituir com chamada real de LLM (cliente Triton/vLLM/TGI)
        time.sleep(0.15)
        output = "Hello from the model."

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

        logger.info(
            {
                "msg": "llm_request_complete",
                "trace_id": trace_id_hex(),
                "model": req.model,
                "latency_ms": int(latency_s * 1000),
                # NÃO incluir prompt/saída bruta a menos que a política o permita.
            }
        )

        return GenerateResponse(model=req.model, 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 resolução de problemas

Opções de implantação

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

• Armazenamento local do Prometheus: sem flags de tamanho/tempo explícitas, o tempo de retenção é, por defeito, 15d.
• Escrita remota do Prometheus: o Prometheus documenta o ajuste de escrita remota para escalar além dos “valores padrão sensatos”.
• Grafana Tempo: posicionado como um backend de rastreio de alta escala e pode gerar métricas a partir de spans usando o metrics-generator (escritas remotas para uma fonte de dados do Prometheus).
• Armazenamento Loki: a documentação do Loki enfatiza indexação apenas de rótulos e armazenamento de blocos comprimidos (armazenamento de objetos), tornando a estratégia de rótulos central para escala e custo.

Segurança e privacidade: os prompts podem conter PII

A orientação de segurança do OpenTelemetry enfatiza que a recolha de telemetria pode capturar inadvertidamente informações sensíveis/pessoais; você é responsável por tratá-las adequadamente.

O modelo de segurança do Prometheus adverte que os endpoints do Prometheus não devem ser expostos a redes acessíveis publicamente (como a internet) porque servem informações sobre sistemas monitorizados.

Controlos de privacidade operacionais que mantêm a “observabilidade para sistemas de LLM” segura:

• Por defeito, não registar prompts/respostas brutas; registar contagens de tokens, nome do modelo, latência e IDs de traço em vez disso.
• Redigir/soltar atributos sensíveis em coletores/pipelines (a filtragem a nível de coletor é uma abordagem comum em ecossistemas).
• Executar RBAC e políticas de retenção para registos/traços; considerar scanners de dados sensíveis onde apropriado (ex., fornecedores documentam scanners para telemetria).

Lista de verificação de resolução de problemas

Se o seu painel Grafana para latência de LLM parecer errado, depure nesta ordem:

• Saúde de ingestão
  • Prometheus: validar sucesso da raspagem e semântica de configuração (a configuração do Prometheus define trabalhos/instâncias de raspagem).
  • OTLP: confirmar configuração de endpoint do exportador (os SDKs usam OTEL_EXPORTER_OTLP_ENDPOINT, definições de protocolo).
• Incompatibilidade de esquema
  • O painel espera model, mas o seu servidor emite model_name (o vLLM documenta explicitamente rótulos model_name).
• Explosão de cardinalidade
  • Alguém rotulou por IDs de pedido/hashes de prompt; o Prometheus adverte que conjuntos de rótulos aumentam custos de RAM/CPU/disco/rede e fornece orientação de cardinalidade.
• Uso indevido de histogramas
  • Certifique-se de que computa quantis a partir de séries _bucket com rate() e le; o Prometheus explica as compensações de cálculo de quantis de histograma.
• Lacunas de amostragem de traços
  • Se você amostrar a cabeça de forma muito agressiva, traços lentos/de erro raros desaparecem; a amostragem de cauda retém traços “importantes” com base em critérios de traço completo.
• Problemas de métricas de spans do Tempo
  • Se estiver a usar o metrics-generator e span-metrics do Tempo, confirme que está ativado e ajustado (o Tempo documenta processadores metrics-generator e span-metrics; a resolução de problemas existe para problemas do gerador).
• Métricas da GPU ausentes
  • Confirmar que o exporter DCGM está implantado e /metrics está acessível (o exporter DCGM expõe métricas da GPU via HTTP para o Prometheus).

Links úteis

• Agentes de Polling em Assistentes de IA: 11 Padrões de Implementação — a secção da lista de verificação de observabilidade cobre exatamente quais métricas de agente de fundo, campos de registo e vistas administrativas instrumentar para sistemas de polling de produção
• Observabilidade: Guia de Monitorização, Métricas, Prometheus e Grafana
• A2A vs MCP: Os Agentes de IA Realmente Precisam de Ambos os Protocolos? — as secções de observabilidade e segurança lá cobrem o que rastrear em sistemas multi-agente que combinam ambos os protocolos
• Padrões de Orquestração Multi-Agente — a secção de observabilidade cobre requisitos de rastreio distribuído específicos para cada padrão: reprodução de quadro negro para enxame, atribuição de custos por agente e monitorização de convergência para malha
• Protocolo A2A do Google em 2026: Adoção, Hype e Realidade — as secções de segurança e erros comuns cobrem exatamente a observabilidade que você precisa ao implantar agentes através de fronteiras A2A
• O Que é o Protocolo A2A? Agent Cards e Tarefas Explicados — a secção de observabilidade explica o que um traço de tarefa entre agentes precisa de capturar: alterações de estado da tarefa, cadeias de delegação, artefactos e mensagens entre agentes
• Monitorização Prometheus: Configuração e Melhores Práticas
• Desempenho de LLM: Benchmarks, Gargalos e Otimização
• Alojamento de LLM: Local, Auto-hospedado e Infraestrutura em Nuvem Comparados
• 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
• Nomenclatura de métricas do Prometheus
• Histogramas e resumos do Prometheus
• Regras de alerta do Prometheus
• Visão geral de alerta do Prometheus
• Configuração do Alertmanager
• Modelo JSON de painéis do Grafana
• Provisionamento do Grafana
• Métricas do NVIDIA Triton Inference Server
• API de métricas do TorchServe
• Exporter DCGM da NVIDIA
• Gráfico Helm kube-prometheus-stack
• Introdução ao Operador Prometheus
• Especificação do exporter Prometheus do OpenTelemetry
• Guia do Prometheus para receção de OTLP
• Rastreio LangSmith com OpenTelemetry