Observability

L’osservabilità è la capacità di capire cosa accade all’interno di un sistema software partendo dai dati telemetrici che genera, principalmente log, metriche e tracce, in misura sufficiente per rispondere a nuove domande sul suo comportamento senza distribuire nuovo codice. Il termine deriva dalla teoria del controllo, dove nel 1960 Rudolf Kálmán definì osservabile un sistema se il suo stato interno può essere determinato dai suoi output. I team software hanno adottato il termine negli anni 2010, quando i sistemi si sono suddivisi in molti servizi e i guasti hanno smesso di corrispondere ai dashboard predisposti. Nei sistemi di apprendimento automatico, l’osservabilità comprende anche i dati e le previsioni: quali input riceve un modello, cosa restituisce, quanto è sicuro e come entrambi cambiano nel tempo.

Log, metriche e tracce#

Tre tipi di dati telemetrici, spesso chiamati pilastri dell’osservabilità, rispondono a domande diverse:

• Metriche: Serie temporali numeriche come frequenza delle richieste, tasso di errore, percentili di latenza, memoria e utilizzo della GPU; sono economiche da archiviare e adatte a dashboard e avvisi. Il libro di Google sull’ingegneria dell’affidabilità dei siti indica quattro segnali fondamentali da misurare per ogni servizio: latenza, traffico, errori e saturazione.
• Log: Registrazioni con timestamp di singoli eventi, più utili se strutturate in JSON con campi come ID della richiesta, versione del modello e dimensioni dell’input, così da poterle filtrare e conteggiare.
• Tracce: Il percorso di una richiesta attraverso tutti i servizi che attraversa, registrato come albero di span, ciascuno con un nome, un’ora di inizio, una durata e attributi; mostra dove è stato impiegato il tempo della richiesta.

OpenTelemetry, nato nel 2019 dalla fusione dei progetti OpenTracing e OpenCensus, fornisce API, SDK e un protocollo di comunicazione indipendenti dal fornitore (OTLP) per tutti e tre i segnali; backend come Prometheus, Grafana e Jaeger li archiviano e li visualizzano. Questo esempio traccia una richiesta di classificazione di immagini con l’SDK Python di OpenTelemetry, registrando uno span padre per la richiesta e uno span figlio per ogni fase:

import torch
import torchvision
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import SimpleSpanProcessor
from opentelemetry.sdk.trace.export.in_memory_span_exporter import InMemorySpanExporter

# Keep finished spans in memory; a production service exports them over OTLP instead
exporter = InMemorySpanExporter()
provider = TracerProvider()
provider.add_span_processor(SimpleSpanProcessor(exporter))
tracer = provider.get_tracer("classifier")
model = torchvision.models.resnet18().eval()
frame = torch.rand(3, 1080, 1920)

# Trace one request as a parent span with a child span for each stage
with tracer.start_as_current_span("predict", attributes={"model.name": "resnet18", "image.height": 1080}):
    with tracer.start_as_current_span("preprocess"):
        batch = torchvision.transforms.functional.resize(frame, [224, 224]).unsqueeze(0)
    with tracer.start_as_current_span("inference"), torch.inference_mode():
        logits = model(batch)

spans = exporter.get_finished_spans()
names = {span.context.span_id: span.name for span in spans}
for span in spans:
    parent = names[span.parent.span_id] if span.parent else "-"
    print(f"{span.name:<11} {(span.end_time - span.start_time) / 1e6:5.1f} ms  parent: {parent}")

Su una CPU Apple M5 Pro, stampa uno span preprocess da 1,0 a 1,4 ms e uno span inference da 7 a 9 ms, entrambi con predict come span padre, e uno span predict da 8 a 10 ms; la traccia attribuisce così al modello la maggior parte del tempo della richiesta. Quando gli span vengono esportati tramite OTLP, ogni servizio che gestisce una richiesta aggiunge span con lo stesso ID di traccia e un backend come Jaeger li rappresenta in un’unica cronologia.

Osservabilità vs. monitoraggio#

Il monitoraggio dei modelli rileva modalità di guasto note con metriche, dashboard e soglie di avviso predefinite, per esempio un tasso di errore superiore all’1% o una latenza di inferenza oltre il valore obiettivo. L’osservabilità è la proprietà più ampia che permette di indagare guasti imprevisti, filtrando a posteriori i dati telemetrici dettagliati per cliente, versione del modello, telecamera o qualsiasi altro attributo. Il libro SRE di Google richiede al monitoraggio di rispondere a due domande: cosa non funziona e perché; un’indagine passa dalla prima risposta alla seconda esaminando tutti e tre i segnali:

L’IA spiegabile è un campo distinto che spiega perché un modello ha prodotto un determinato output a partire dalle sue caratteristiche di input o dalle attivazioni interne; le attribuzioni ottenute possono essere registrate come un ulteriore segnale.

Osservabilità per l’apprendimento automatico#

I sistemi di apprendimento automatico spesso si guastano senza segnalarlo: un modello di visione artificiale può rispondere a ogni richiesta con HTTP 200 mentre le sue previsioni peggiorano perché la telecamera è stata spostata, l’illuminazione è cambiata o è apparso un nuovo prodotto. L’osservabilità ML aggiunge quindi ai consueti segnali del servizio dati telemetrici relativi ai dati e alle previsioni. I team registrano statistiche di input come dimensioni e luminosità delle immagini per rilevare la deriva dei dati, monitorano distribuzioni delle previsioni come conteggi delle classi, risultati vuoti e confidenza media e calcolano l’accuratezza per segmento quando arrivano le etichette di ground truth, spesso giorni dopo. Durante l’addestramento, i callback inviano curve di perdita, metriche e utilizzo del sistema per ogni esecuzione agli strumenti di tracciamento degli esperimenti, come TensorBoard e MLflow. Per le applicazioni di agenti IA e modelli linguistici di grandi dimensioni, le tracce registrano ogni prompt, fase di recupero, chiamata a uno strumento e risposta; le convenzioni semantiche GenAI di OpenTelemetry standardizzano attributi come gen_ai.usage.input_tokens, così che il conteggio dei token e i costi siano coerenti tra gli strumenti.

Ogni endpoint dedicato della Ultralytics Platform integra il monitoraggio del deployment: schede con il numero di richieste, il tasso di errore e la latenza p95; una scheda Logs con i livelli di gravità e un filtro Errors per le voci di errore e di avviso; e statistiche sulle predizioni che mostrano nei grafici le classi più frequenti, la confidenza media nel tempo, le predizioni per immagine e il tempo di inferenza del modello, separato dalla latenza delle richieste. Una curva di confidenza in calo o un cambiamento nelle classi più frequenti si nota in questi grafici anche se tutte le richieste vanno a buon fine.