Osservabilità per sistemi LLM: metriche, tracce, log e test in produzione

LLM systems falliscono in modi che la tradizionale monitorizzazione degli API non riesce a rilevare — le code si riempiono in silenzio, la memoria GPU si saturano molto prima che il CPU appaia occupata, e la latenza aumenta a livello di batching anziché a livello di applicazione. Questa guida copre una strategia end-to-end strategia di osservabilità per l’inferenza degli LLM e le applicazioni LLM: cosa misurare, come strumentarla con Prometheus, OpenTelemetry e Grafana, e come distribuire la pipeline di telemetria su larga scala.

TL;DR (Riassunto esecutivo)

I sistemi LLM degradano in modi che la classica “latenza HTTP + tasso di errori” non riesce a spiegare. L’osservabilità di produzione per i sistemi LLM deve rispondere rapidamente e in modo difendibile:

• Se l’esperienza utente sta degradando (latenza di coda, tempo per primo token, latenza tra token, errori e interruzioni).
• Dove viene speso il tempo (in coda vs batching vs esecuzione del modello; recupero/strumenti/filtri di sicurezza vs inferenza).
• Cosa si satura per primo (utilizzo GPU e pressione della memoria, pressione della cache KV/coda, tokenizzazione CPU).
• Come si muove il costo e la capacità (token per richiesta, token/sec per GPU, tasso di cache hit, generazioni sprecate).
• Se la telemetria è sicura da archiviare (i prompt possono contenere PII; prevenire perdite sensibili nei log/attributi).

La progettazione più resiliente è una pipeline multi-signal:

• Metriche per una rapida rilevazione e pianificazione della capacità (Prometheus + PromQL; archiviazione a lungo termine opzionale tramite Thanos/Cortex/Mimir/VictoriaMetrics).
• Tracce per la causalità a livello di richiesta (OpenTelemetry con OTLP; backend come Tempo/Jaeger/Zipkin/Elastic APM).
• Log per il contesto, correlati alle tracce (Loki/Elastic/OpenSearch), progettati per metadati a bassa cardinalità.
• Profilatura per i hotspot CPU/memoria e latenza di coda (Grafana Pyroscope).
• Test sintetici + test di carico per rilevare regressioni prima che gli utenti lo facciano (Grafana k6; probing nello stile blackbox).
• SLO per misurare i risultati degli utenti e guidare l’alerting azionabile (budget di errori; stile burn-rate).

Cosa rende l’osservabilità per i sistemi LLM diversa

Nota sull’ambito: il framework LLM di destinazione è non specificato. Gli esempi in questo articolo coprono i server/framework comuni (Triton, vLLM, TGI, LangChain/LangSmith) e rimangono applicabili ad altri stack sostituendo le metriche e le span equivalenti.

I modelli LLM introducono comportamenti operativi diversi da quelli dei servizi web tradizionali:

• Lavoro variabile per richiesta: i conteggi dei token (input/output) variano ampiamente, quindi “richieste al secondo” possono sembrare stabili mentre la throughput dei token si riduce. TGI e vLLM esportano esplicitamente metriche e latenza dei token per supportare questo tipo di monitoraggio.
• Coda + batching continuo: la throughput dipende dalle discipline di batching/coda; la dimensione della coda e la dimensione del batch diventano indicatori di primo piano (TGI espone entrambe).
• UX di streaming: gli utenti si preoccupano del TTFT e della latenza tra token almeno quanto del tempo di risposta completo; OpenTelemetry standardizza anche le metriche server TTFT/time-per-token sotto le convenzioni semantiche GenAI.
• La pressione GPU domina i modi di fallimento: l’utilizzo GPU e la memoria GPU (inclusa la memoria utilizzata) sono centrali per la affidabilità; l’esportatore NVIDIA DCGM esiste specificamente per esporre la telemetria GPU a un endpoint Prometheus /metrics.
• Pipeline a più passaggi: il recupero, le chiamate degli strumenti, i filtri di sicurezza e il post-processing significano che la latenza end-to-end è una composizione di più span/coda — rendendo essenziale la tracciatura distribuita e la progettazione attenta delle metriche.

Esempi concreti da popolari server di inferenza sottolineano questo:

• NVIDIA Triton Inference Server espone le metriche come testo semplice tramite /metrics (comunemente :8002/metrics) e fornisce flag per abilitare/disabilitare le metriche e selezionare una porta delle metriche.
• vLLM espone un ampio endpoint Prometheus /metrics con un prefisso vllm:; la sua documentazione include contatori per i token generati e istogrammi come time to first token.
• Hugging Face TGI documenta un endpoint /metrics con dimensione della coda, dimensione del batch, durata della richiesta end-to-end, token generati e durata della coda.

Compiti principali di osservabilità e telemetria necessaria per i modelli LLM

L’osservabilità per i sistemi LLM è più facile da implementare quando mappi compiti → segnali → strumenti, e quindi limiti la cardinalità e il campionamento fin dal primo giorno.

Metriche: Per i sistemi di servizio online, le linee guida di strumentazione di Prometheus sottolineano che il conteggio delle query, gli errori e la latenza sono metriche chiave; i modelli LLM espandono questo con TTFT, throughput/latenza per token, lunghezza della coda, dimensione del batch e utilizzo GPU.

Tracce: Le tracce sono il modo in cui attribuisci la latenza e i fallimenti attraverso le fasi di recupero/strumenti/sicurezza/inferenza; OpenTelemetry presenta le tracce/esportatori come un modo neutrale rispetto ai fornitori per emettere e inviare la telemetria ai raccoglitori o ai backend.

Log: I log forniscono un contesto leggibile dagli umani e “perché”, ma rimangono utilizzabili su larga scala solo se eviti di indicizzare valori non limitati (esempio: Loki indice solo le etichette e memorizza i frammenti di log compressi in archiviazione oggetti).

Profilatura: La profilatura continua cattura il comportamento CPU/memoria in produzione con un campionamento a basso overhead; Grafana Pyroscope è posizionato esplicitamente per questo.

Test sintetici e test di carico: Grafana k6 è uno strumento open-source per il test di carico, e Grafana nota che il Monitoraggio Sintetico è alimentato da k6 e va oltre i semplici controlli del protocollo.

SLO: Le linee guida di SRE di Google definiscono un SLO come un valore/intervallo obiettivo per un livello di servizio misurato da un SLI, e forniscono linee guida per l’alerting sugli SLO (compromessi tra precisione/ricerca/tempo di rilevamento).

Blue print delle metriche chiave per LLM

Convenzioni semantiche GenAI di OpenTelemetry per la standardizzazione

OpenTelemetry fornisce convenzioni semantiche GenAI (stato: “Sviluppo”) con nomi standard per metriche GenAI come:

• 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

Questa standardizzazione è un leva pratica per strategie portabili di “monitoraggio modelli LLM con OpenTelemetry”: emetti una volta e indirizza la stessa telemetria successivamente a backend OSS o vendor.

Progettare la pipeline di telemetria

Pull vs push

Prometheus è pull-first. I processi espongono le metriche in un formato di esposizione supportato, e Prometheus le raccoglie in base ai lavori di raccolta configurati.

Push è per eccezioni. La guida “When to use the Pushgateway” di Prometheus raccomanda esplicitamente il Pushgateway solo in casi limitati (non come sostituzione generale del push), e il README del Pushgateway sottolinea che non può “trasformare Prometheus in un sistema di monitoraggio basato su push”.

Pattern pratico specifico per LLM:

• Usa pull per i server di inferenza/esportatori (endpoint delle metriche di Triton/vLLM/TGI; esportatore DCGM; metriche del nodo).
• Usa OTLP push per tracce/log/metriche OTel (il protocollo OTLP definisce trasporto/encoding/delivery tra fonti, raccoglitori e backend).
• Usa remote write quando si scalano oltre un unico Prometheus (Prometheus fornisce linee guida per l’ottimizzazione di remote write; Mimir/Thanos/Cortex forniscono opzioni di archiviazione a lungo termine e/o HA).

Agenti vs sidecar vs gateway collectors

OpenTelemetry documenta un pattern di distribuzione dell’agente, dove la telemetria viene inviata a un Collector che esegue accanto all’applicazione o nello stesso host (sidecar/DaemonSet), quindi esportata.

Per Kubernetes, l’iniezione del sidecar è supportata tramite l’OpenTelemetry Operator (iniezione basata su annotazioni).

Regola pragmatica per stack LLM:

• Usa un DaemonSet agent per l’enrichimento a livello di host e pipeline condivise tra molti pod.
• Usa un sidecar quando necessiti di isolamento rigoroso per workload o filtraggio locale dedicato (comune quando i prompt possono contenere dati sensibili).
• Usa un gateway collector per il campionamento centrale, batching, retry e fan-out dell’esportazione.

Campionamento e controllo della cardinalità

OpenTelemetry chiarisce che il campionamento di coda permette decisioni di campionamento basate su criteri derivati da una traccia (non possibile con il solo campionamento di testa).

Le linee guida di strumentazione di Prometheus avvertono contro l’uso eccessivo di etichette, forniscono una regola d’incirca per mantenere bassa la cardinalità e consigliano di riprogettare le metriche se la cardinalità potenziale supera ~100.

“Trappole di cardinalità” specifiche per LLM da evitare fin dall’inizio:

• Testo del prompt, testo della risposta, ID della conversazione, ID della richiesta come etichette/attributi.
• Blocchi di argomenti degli strumenti come attributi delle span.
• “user_id” non limitati come etichette.

Preferisci dimensioni limitate: model, model_family, endpoint, region, status_code, deployment, tenant (solo se limitati).

Confronto degli strumenti per l’osservabilità LLM

Strumenti mappati ai compiti di osservabilità

Grafana vs alternative per la visualizzazione

• Le dashboard Grafana sono composte da pannelli che interrogano le fonti dati (inclusi Loki e Mimir) per produrre grafici e visualizzazioni.
• Kibana fornisce dashboard/visualizzazioni come strato UI all’interno del Elastic Stack.
• OpenSearch Dashboards fornisce strumenti per la visualizzazione dei dati per OpenSearch.
• La documentazione di InfluxData posiziona Chronograf come componente di visualizzazione all’interno dell’ecosistema Influx.

Prometheus vs alternative per backend delle metriche

• Le impostazioni di archiviazione locali di Prometheus: se non sono impostate le bandiere di conservazione, la conservazione predefinita è di 15d (pianifica conservazione/costo fin dall’inizio).
• Grafana Mimir è descritto come una soluzione scalabile orizzontalmente, HA, multi-tenant a lungo termine per metriche Prometheus e OpenTelemetry.
• Thanos è descritto come un setup Prometheus altamente disponibile con capacità di archiviazione a lungo termine.
• Cortex descrive se stesso come una soluzione scalabile orizzontalmente, HA, multi-tenant a lungo termine per metriche Prometheus e OpenTelemetry.
• VictoriaMetrics Cloud documenta l’integrazione di scrittura remota di Prometheus per archiviazione a lungo termine.
• Amazon Managed Service for Prometheus descrive un’offerta gestita che scala con le esigenze di ingestione/query e supporta PromQL e scrittura remota.

Cookbook pratico di implementazione

Nomina delle metriche e tipi da implementare oggi

Le convenzioni semantiche GenAI di OpenTelemetry (stato: Sviluppo) definiscono nomi di metriche su cui puoi standardizzare immediatamente:

• 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

Esempi di server che puoi raccogliere immediatamente:

• L’endpoint Prometheus di vLLM include contatori (es. totale token generati) e istogrammi (TTFT) e documenta una strategia di etichetta model_name.
• TGI documenta metriche che includono dimensione della coda, durata della richiesta, token generati e tempo medio per token.
• Triton documenta l’esposizione /metrics e le opzioni di attivazione/disattivazione delle metriche.

Esempi PromQL per dashboard di latenza e throughput LLM

# p95 latenza end-to-end per un istogramma dell'applicazione
histogram_quantile(
  0.95,
  sum(rate(llm_request_latency_seconds_bucket[5m])) by (le, model)
)

# Percentuale di tasso di errori (5xx)
100 *
(
  sum(rate(llm_requests_total{status_code=~"5.."}[5m]))
  /
  sum(rate(llm_requests_total[5m]))
)

# Token/sec (output) su tutti i modelli
sum(rate(llm_tokens_total{direction="out"}[5m]))

# Dimensione della coda TGI (gauge)
max(tgi_queue_size) by (istanza)

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

Le linee guida di Prometheus per gli istogrammi spiegano che i quantili degli istogrammi vengono calcolati sul lato server dalle bucket utilizzando histogram_quantile().

Note di strumentazione OpenTelemetry per sistemi LLM

• OTLP è il protocollo OpenTelemetry che specifica come la telemetria venga codificata/trasmessa tra fonti, raccoglitori e backend.
• Le linee guida di configurazione OpenTelemetry SDK documentano variabili di ambiente come OTEL_EXPORTER_OTLP_ENDPOINT (e opzioni di protocollo) per l’esportazione della telemetria.
• La documentazione OpenTelemetry Python contrib documenta il supporto di strumentazione automatica e manuale per FastAPI.
• Le convenzioni semantiche GenAI includono un meccanismo di stabilità opt-in tramite OTEL_SEMCONV_STABILITY_OPT_IN per la migrazione delle convenzioni GenAI.

Esempio breve in Python: metriche + tracce + log

Il frammento di codice seguente dimostra:

• Esposizione delle metriche Prometheus (/metrics) per “monitoraggio LLM inferenza con Prometheus”
• Tracce OpenTelemetry esportate tramite OTLP (neutro rispetto ai fornitori)
• Log strutturati correlati al contesto delle tracce, con un default sicuro per la privacy (non registrare i prompt grezzi)

import logging
import time

from fastapi import FastAPI, Request
from pydantic import BaseModel

# Prometheus (metriche basate su pull)
from prometheus_client import Counter, Histogram, generate_latest, CONTENT_TYPE_LATEST
from starlette.responses import Response

# OpenTelemetry (tracce 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 (default sicuro per la privacy) ---
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 ""

# --- Metriche Prometheus ---
LLM_REQUESTS = Counter(
    "llm_requests_total",
    "Totale richieste LLM",
    ["route", "status_code", "model"],
)
LLM_LATENCY = Histogram(
    "llm_request_latency_seconds",
    "Latenza end-to-end LLM (secondi)",
    ["route", "model"],
    buckets=(0.1, 0.2, 0.35, 0.5, 0.75, 1, 1.5, 2, 3, 5, 8, 13),
)

# --- Fornitore OpenTelemetry tracer ---
resource = Resource.create({"service.name": "llm-inference-api"})
trace.set_tracer_provider(TracerProvider(resource=resource))
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter())  # configurare tramite variabili d'ambiente OTEL_EXPORTER_OTLP_*
)
tracer = trace.get_tracer(__name__)

class GenerateRequest(BaseModel):
    prompt: str
    model: str = "non specificato"
    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:
        # Evita di registrare il prompt completo; emetti metadati sicuri
        span.set_attribute("gen_ai.request.model", req.model)
        span.set_attribute("gen_ai.request.max_tokens", req.max_tokens)

        # Sostituisci con la chiamata effettiva LLM (client Triton/vLLM/TGI)
        time.sleep(0.15)
        output = "Ciao dal modello."

        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),
                # Non includere prompt/output grezzi a meno che la politica non lo permetta.
            }
        )

        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)

Deployment, scalabilità, sicurezza e risoluzione dei problemi

Opzioni di deployment

Scalabilità e conservazione: vincoli pratici

• Archiviazione locale di Prometheus: senza flag espliciti di dimensione/tempo, il tempo di conservazione predefinito è di 15 giorni.
• Scrittura remota di Prometheus: Prometheus documenta l’ottimizzazione della scrittura remota per scalare oltre i “valori predefiniti”.
• Grafana Tempo: posizionato come backend di tracciatura ad alta scala e può generare metriche da span utilizzando il metrics-generator (scrittura remota a una fonte dati Prometheus).
• Archiviazione Loki: le documentazioni di Loki sottolineano l’indicizzazione solo delle etichette e l’archiviazione di frammenti compressi (archiviazione oggetti), rendendo la strategia delle etichette centrale per scalabilità e costo.

Sicurezza e privacy: i prompt possono contenere PII

Le linee guida di sicurezza di OpenTelemetry sottolineano che la raccolta di telemetria può accidentalmente catturare informazioni sensibili/personali; sei responsabile del gestirle correttamente.

Le linee guida di sicurezza di Prometheus avvertono che gli endpoint Prometheus non dovrebbero essere esposti a reti pubbliche accessibili (come internet) perché forniscono informazioni sui sistemi monitorati.

Controlli operativi sulla privacy che mantengono “osservabilità per i sistemi LLM” sicuri:

• Default a non registrare prompt/responsi grezzi; registrare invece conteggi token, nome modello, latenza e ID traccia.
• Redattare/drop attributi sensibili nei raccoglitori/pipeline (il filtraggio a livello di raccoglitore è un approccio comune in tutti gli ecosistemi).
• Applicare RBAC e politiche di conservazione per log/tracce; considerare scanner per dati sensibili dove appropriato (es. fornitori documentano scanner per telemetria).

Checklist per la risoluzione dei problemi

Se il tuo dashboard Grafana per la latenza LLM sembra sbagliato, debugga in questo ordine:

• Salute dell’ingestione
  • Prometheus: convalida il successo della raccolta e la semantica della configurazione (la configurazione di Prometheus definisce i lavori di raccolta/istanze).
  • OTLP: conferma la configurazione dell’endpoint dell’esportatore (SDK utilizzano OTEL_EXPORTER_OTLP_ENDPOINT, impostazioni del protocollo).
• Mancanza di schema
  • La dashboard aspetta model, ma il tuo server emette model_name (vLLM documenta esplicitamente le etichette model_name).
• Esplosione di cardinalità
  • Qualcuno ha etichettato con ID richiesta/cripto di prompt; Prometheus avverte che gli insiemi di etichette aumentano i costi di RAM/CPU/disk/network e fornisce linee guida per la cardinalità.
• Abuso di istogrammi
  • Assicurati di calcolare i quantili da serie _bucket con rate() e le; Prometheus spiega i compromessi del calcolo quantile sugli istogrammi.
• Gap nel campionamento delle tracce
  • Se campioni troppo aggressivamente il testa, le tracce lente/errori rari scompaiono; il campionamento di coda mantiene “tracce importanti” basandosi su criteri completi delle tracce.
• Problemi di span-metriche in Tempo
  • Se utilizzi metrics-generator e span-metriche di Tempo, conferma che siano abilitati e ottimizzati (Tempo documenta metrics-generator e span-metriche processor; esiste un troubleshooting per i problemi del generatore).
• Metriche GPU assenti
  • Conferma che l’esportatore DCGM sia distribuito e che /metrics sia accessibile (l’esportatore DCGM espone le metriche GPU via HTTP per Prometheus).

Link utili

• Osservabilità: Guida a monitoraggio, metriche, Prometheus & Grafana
• Monitoraggio con Prometheus: Setup & Best Practices
• Ottimizzazione delle prestazioni LLM: Benchmark, Bottlenecks & Optimization
• Ospitare LLM: Confronto tra locale, auto-ospitato e infrastruttura cloud
• Tutorial RAG Step-by-Step
• Documenti di configurazione Prometheus
• Formati di esposizione Prometheus
• Linee guida per l’implementazione Prometheus
• Nomenclatura delle metriche Prometheus
• Istogrammi e sommari Prometheus
• Regole di alerting Prometheus
• Panoramica di alerting Prometheus
• Configurazione di Alertmanager
• Modello JSON delle dashboard Grafana
• Provisioning Grafana
• Metriche del server di inferenza NVIDIA Triton
• API di metriche TorchServe
• Esportatore NVIDIA DCGM
• Chart Helm kube-prometheus-stack
• Getting started con Prometheus Operator
• Specifica dell’esportatore Prometheus di OpenTelemetry
• Guida Prometheus per ricevere OTLP
• Tracciatura con OpenTelemetry in LangSmith