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

I sistemi LLM falliscono in modi che il monitoraggio tradizionale delle API non riesce a rilevare: le code si riempiono in silenzio, la memoria GPU si satura molto prima che la CPU appaia occupata e la latenza esplode a livello di batching anziché a livello dell’applicazione.

Questa guida illustra una strategia di osservabilità per l’inferenza LLM e le applicazioni LLM: cosa misurare, come strumentarla con Prometheus, OpenTelemetry e Grafana, e come distribuire la pipeline di telemetria su larga scala.

I stack completi degli assistenti aggiungono retrieval, chiamate a strumenti e routing sull’inferenza grezza; Architettura degli Assistenti AI mostra dove l’osservabilità si inserisce tra questi livelli.

TL;DR (Sintesi esecutiva)

I sistemi LLM degradano in modi che il monitoraggio classico di “latenza HTTP + tasso di errore” non riesce a spiegare. L’Osservabilità per i sistemi LLM di livello produzione deve rispondere, rapidamente e in modo difendibile:

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

Il design più resiliente è una pipeline multi-segnale:

• Metriche per il rilevamento rapido e la pianificazione della capacità (Prometheus + PromQL; opzionale archiviazione a lungo termine 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à.
• Profiling per hotspot CPU/memoria e latenza di coda (Grafana Pyroscope).
• Test sintetici e di carico per rilevare regressioni prima degli utenti (Grafana k6; probing stile blackbox).
• SLO per misurare gli esiti utente e guidare allarmi azionabili (budget di errore; stile burn-rate).

Cosa rende diversa l’osservabilità per i sistemi LLM

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

Gli LLM introducono comportamenti operativi che differiscono dai servizi web convenzionali:

• Lavoro variabile per richiesta: i conteggi dei token (input/output) variano ampiamente, quindi le “richieste al secondo” possono apparire stabili mentre il throughput dei token crolla. TGI e vLLM esportano esplicitamente telemetrie relative ai token e alla latenza dei token per supportare questo stile di monitoraggio.
• Code + batching continuo: il throughput dipende dalle discipline di batching/code; la dimensione della coda e della batch diventano indicatori di prima classe (TGI espone entrambi).
• UX di streaming: agli utenti interessa TTFT (Time To First Token) e la latenza inter-token almeno quanto il tempo di risposta completo; OpenTelemetry standardizza persino le metriche server TTFT/tempo-per-token nelle convenzioni semantiche GenAI.
• La pressione GPU domina le modalità di fallimento: l’utilizzo GPU e la memoria GPU (inclusa la memoria utilizzata) sono centrali per l’affidabilità; l’exporter DCGM di NVIDIA esiste specificamente per esporre la telemetria GPU su un endpoint Prometheus /metrics.
• Pipeline multi-step: retrieval, chiamate a strumenti, filtri di sicurezza e post-elaborazione significano che la latenza end-to-end è una composizione di più span/code—rendendo essenziale il distributed tracing e un’attenta progettazione delle metriche.

Esempi concreti dai server di inferenza popolari lo evidenziano:

• NVIDIA Triton Inference Server espone 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 esteso endpoint Prometheus /metrics con un prefisso vllm:; la sua documentazione include contatori per i token di generazione e istogrammi come time to first token.
• Hugging Face TGI documenta un endpoint /metrics con dimensione della coda, dimensione della batch, durata della richiesta end-to-end, token generati e durata della coda.

Attività di osservabilità chiave e telemetria LLM richiesta

L’osservabilità per i sistemi LLM è più semplice da implementare quando si mappano attività → segnali → strumenti, e poi si vincola la cardinalità e il campionamento fin dal primo giorno.

Metriche: Per i sistemi di serving online, la guida alla strumentazione di Prometheus evidenzia conteggio query, errori e latenza come metriche chiave; gli LLM ampliano questo con TTFT, throughput/latenza per token, lunghezza della coda, dimensione della batch e utilizzo GPU.

Tracce: Le tracce sono il modo per attribuire latenza e fallimenti attraverso le fasi retrieval/strumenti/sicurezza/inferenza; OpenTelemetry inquadra le tracce/exporter come un modo vendor-neutral per emettere e inviare telemetria a collettori o backend.

Log: I log forniscono contesto leggibile dall’uomo e il “perché”, ma rimangono utilizzabili su larga scala solo se si evita di indicizzare valori illimitati (esempio: Loki indicizza solo i label e archivia chunk di log compressi in object storage).

Profiling: Il profiling continuo cattura il comportamento CPU/memoria di produzione con campionamento a basso overhead; Grafana Pyroscope è esplicitamente posizionato per questo.

Test sintetici e di carico: Grafana k6 è uno strumento di load testing open-source, e Grafana nota che il Synthetic Monitoring è alimentato da k6 e va oltre i semplici controlli di protocollo.

SLO: La guida SRE di Google definisce uno SLO come un valore/intervallo target per un livello di servizio misurato da un SLI, e fornisce indicazioni per gli allarmi sugli SLO (compromessi precisione/richiamo/tempo di rilevamento).

Blueprint delle metriche LLM chiave

Convenzioni semantiche OpenTelemetry GenAI per la standardizzazione

OpenTelemetry fornisce convenzioni semantiche GenAI (stato: “Sviluppo”) con denominazione 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 è una leva pratica per strategie portabili di “monitoraggio modelli LLM con OpenTelemetry”: emetti una volta e instrada la stessa telemetria verso backend OSS o vendor in seguito.

Progettazione della pipeline di telemetria

Pull vs Push

Prometheus è pull-first. I processi espongono metriche in un formato di esposizione supportato e Prometheus le scrape secondo i job di scrape configurati.

Il Push è per le eccezioni. La guida “Quando usare il Pushgateway” di Prometheus raccomanda esplicitamente il Pushgateway solo in casi limitati (non come sostituto generale del push), e il README del Pushgateway enfatizza che non può “trasformare Prometheus in un sistema di monitoraggio basato su push”.

Pattern pratico specifico per LLM:

• Usa pull per server di inferenza/exporter (endpoint metriche Triton/vLLM/TGI; exporter DCGM; metriche nodo).
• Usa push OTLP per tracce/log/metriche OTel (OpenTelemetry Protocol definisce trasporto/codifica/consegna tra sorgenti, collettori e backend).
• Usa remote write quando si scala oltre un singolo Prometheus (Prometheus fornisce indicazioni per l’ottimizzazione del remote write; Mimir/Thanos/Cortex forniscono opzioni di archiviazione a lungo termine e/o HA).

Agent vs sidecar vs gateway collectors

OpenTelemetry documenta un pattern di deployment dell’agent, dove la telemetria viene inviata a un Collector in esecuzione accanto all’applicazione o sullo stesso host (sidecar/DaemonSet), quindi esportata.

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

Regola pratica per stack LLM:

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

Controllo del campionamento e della cardinalità

OpenTelemetry chiarisce che il tail sampling consente decisioni di campionamento utilizzando criteri derivati da una traccia (non possibile con il solo head sampling).

La guida alla strumentazione di Prometheus avverte contro l’eccessivo uso di label, fornisce una regola pratica per mantenere bassa la cardinalità e consiglia di riprogettare le metriche se la cardinalità potenziale supera ~100.

“Trappole della cardinalità” specifiche per LLM da bandire precocemente:

• Testo dei prompt, testo delle risposte, ID conversazione, ID richiesta come label/attributi.
• Blob degli argomenti degli strumenti come attributi degli span.
• Label “user_id” illimitate.

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

Confronto strumenti di osservabilità LLM

Strumenti mappati alle attività di osservabilità

Grafana vs alternative per la visualizzazione

• Le dashboard Grafana sono composte da pannelli che interrogano sorgenti dati (inclusi Loki e Mimir) per produrre grafici e visualizzazioni.
• Kibana fornisce dashboard/visualizzazioni come strato UI all’interno di Elastic Stack.
• OpenSearch Dashboards fornisce strumenti di visualizzazione 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

• Archiviazione locale Prometheus: se i flag di retention non sono impostati, la retention di default è 15d (pianifica retention/costo precocemente).
• Grafana Mimir è descritto come archiviazione a lungo termine orizzontalmente scalabile, HA, multi-tenant per metriche Prometheus e OpenTelemetry.
• Thanos è descritto come una configurazione Prometheus ad alta disponibilità con capacità di archiviazione a lungo termine.
• Cortex si descrive come una soluzione di archiviazione a lungo termine orizzontalmente scalabile, HA, multi-tenant per metriche Prometheus e OpenTelemetry.
• VictoriaMetrics Cloud documenta l’integrazione remote write Prometheus per l’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 remote write.

Cookbook di implementazione pratica

Nomi e tipi di metriche da implementare oggi

Le convenzioni semantiche OpenTelemetry GenAI (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 lato server che puoi scrape subito:

• L’endpoint Prometheus di vLLM include contatori (es. totale token di generazione) e istogrammi (TTFT) e documenta una strategia di label model_name.
• TGI documenta metriche incluse dimensione della coda, durata della richiesta, token generati e tempo medio per token.
• Triton documenta l’esposizione /metrics e interruttori di metrica.

Esempi PromQL per dashboard di latenza e throughput LLM

# Latenza end-to-end p95 per un istogramma applicativo
histogram_quantile(
  0.95,
  sum(rate(llm_request_latency_seconds_bucket[5m])) by (le, model)
)

# Percentuale tasso di errore (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 coda TGI (gauge)
max(tgi_queue_size) by (instance)

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

La guida agli istogrammi di Prometheus spiega che i quantili degli istogrammi sono calcolati lato server dai bucket usando histogram_quantile().

Note sulla strumentazione OpenTelemetry per sistemi LLM

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

Breve esempio Python: metriche + tracce + log

Lo snippet sottostante dimostra:

• Esposizione metriche Prometheus (/metrics) per “monitoraggio inferenza LLM con Prometheus”
• Tracce OpenTelemetry esportate via OTLP (vendor-neutral)
• Log strutturati correlati al contesto della traccia, con default privacy-safe (non loggare prompt grezzi)

import logging
import time

from fastapi import FastAPI, Request
from pydantic import BaseModel

# Prometheus (metriche pull-based)
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 privacy-safe) ---
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 richiesta LLM end-to-end (secondi)",
    ["route", "model"],
    buckets=(0.1, 0.2, 0.35, 0.5, 0.75, 1, 1.5, 2, 3, 5, 8, 13),
)

# --- Provider tracer 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())  # configura tramite variabili env 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 loggare il prompt completo; emetti metadata sicuri
        span.set_attribute("gen_ai.request.model", req.model)
        span.set_attribute("gen_ai.request.max_tokens", req.max_tokens)

        # Sostituisci con chiamata LLM reale (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 policy non lo consenta.
            }
        )

        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, scaling, sicurezza e troubleshooting

Opzioni di deployment

Scaling e retention: vincoli pratici

• Archiviazione locale Prometheus: senza flag espliciti di dimensione/tempo, il tempo di retention di default è 15d.
• Remote write Prometheus: Prometheus documenta l’ottimizzazione del remote write per lo scaling oltre i “valori di default sani”.
• Grafana Tempo: posizionato come backend di tracing ad alta scala e può generare metriche dagli span usando il metrics-generator (remote write a una sorgente dati Prometheus).
• Archiviazione Loki: i docs di Loki enfatizzano l’indicizzazione solo label e l’archiviazione chunk compressa (object storage), rendendo la strategia delle label centrale per scala e costo.

Sicurezza e privacy: i prompt possono contenere PII

La guida alla sicurezza di OpenTelemetry sottolinea che la raccolta della telemetria può catturare involontariamente informazioni sensibili/personali; sei responsabile della gestione appropriata.

Il modello di sicurezza di Prometheus avverte che gli endpoint Prometheus non dovrebbero essere esposti a reti pubblicamente accessibili (come internet) perché servono informazioni sui sistemi monitorati.

Controlli operativi di privacy che mantengono sicura l’“osservabilità per sistemi LLM”:

• Default a non loggare prompt/risposte grezzi; logga conteggi token, nome modello, latenza e ID traccia invece.
• Redigi/elimina attributi sensibili nei collettori/pipeline (il filtraggio a livello di Collector è un approccio comune negli ecosistemi).
• Impone RBAC e policy di retention per log/tracce; considera scanner di dati sensibili dove appropriato (es. i vendor documentano scanner per la telemetria).

Checklist di troubleshooting

Se la tua dashboard Grafana per la latenza LLM sembra errata, debugga in questo ordine:

• Salute ingestione
  • Prometheus: valida successo dello scrape e semantica della configurazione (la configurazione Prometheus definisce job/istanze di scrape).
  • OTLP: conferma configurazione endpoint exporter (gli SDK usano OTEL_EXPORTER_OTLP_ENDPOINT, impostazioni protocollo).
• Disallineamento schema
  • La dashboard si aspetta model, ma il tuo server emette model_name (vLLM documenta esplicitamente label model_name).
• Esplosione della cardinalità
  • Qualcuno ha etichettato per ID richiesta/hash prompt; Prometheus avverte che i labelset aumentano i costi RAM/CPU/disco/rete e fornisce indicazioni sulla cardinalità.
• Uso improprio degli istogrammi
  • Assicurati di calcolare i quantili dalle serie _bucket con rate() e le; Prometheus spiega i compromessi del calcolo dei quantili degli istogrammi.
• Lacune nel campionamento delle tracce
  • Se fai head-sample troppo aggressivamente, le tracce lente/errore rare scompaiono; il tail sampling conserva le tracce “importanti” basandosi su criteri traccia completa.
• Problemi span-metrics Tempo
  • Se usi metrics-generator di Tempo e span-metrics, conferma che è abilitato e ottimizzato (Tempo documenta processore metrics-generator e span-metrics; esiste troubleshooting per problemi del generatore).
• Metriche GPU assenti
  • Conferma che l’exporter DCGM è distribuito e /metrics è raggiungibile (DCGM exporter espone metriche GPU su HTTP per Prometheus).

Link utili

• Agenti Polling negli Assistenti AI: 11 Pattern di Implementazione — la sezione checklist di osservabilità copre esattamente quali metriche degli agenti in background, campi log e viste admin strumentare per sistemi di polling di produzione
• Osservabilità: Guida al Monitoraggio, Metriche, Prometheus & Grafana
• A2A vs MCP: Gli Agenti AI Hanno Realmente Bisogno di Entrambi i Protocolli? — le sezioni di osservabilità e sicurezza lì coprono cosa tracciare in sistemi multi-agente che combinano entrambi i protocolli
• Pattern di Orchestrazione Multi-Agente — la sezione di osservabilità copre i requisiti di distributed tracing specifici per ogni pattern: replay blackboard per swarm, attribuzione costi per agente, e monitoraggio convergenza per mesh
• Protocollo A2A di Google nel 2026: Adozione, Hype e Realtà — le sezioni di sicurezza ed errori comuni coprono esattamente quale osservabilità ti serve quando distribuisce agenti attraverso confini A2A
• Cos’è il Protocollo A2A? Agent Cards e Task Spiegati — la sezione di osservabilità spiega cosa deve catturare una traccia di task cross-agente: cambiamenti di stato del task, catene di delega, artefatti e messaggi agent-to-agent
• Monitoraggio Prometheus: Setup & Best Practices
• Prestazioni LLM: Benchmark, Colli di Bottiglia & Ottimizzazione
• Hosting LLM: Locale, Self-Hosted & Cloud Infrastructure Confrontati
• Tutorial RAG Passo-Passo
• Documentazione configurazione Prometheus
• Formati di esposizione Prometheus
• Best practice strumentazione Prometheus
• Nomenclatura metriche Prometheus
• Istogrammi e riepiloghi Prometheus
• Regole di allarme Prometheus
• Panoramica allarmi Prometheus
• Configurazione Alertmanager
• Modello JSON dashboard Grafana
• Provisioning Grafana
• Metriche NVIDIA Triton Inference Server
• API metriche TorchServe
• Exporters DCGM NVIDIA
• Chart Helm kube-prometheus-stack
• Guida iniziale Prometheus Operator
• Spec exporter Prometheus OpenTelemetry
• Guida Prometheus per ricevere OTLP
• Tracing LangSmith con OpenTelemetry