Observability

L’observabilité est la capacité à comprendre ce qui se passe à l’intérieur d’un système logiciel à partir des données de télémétrie qu’il émet, principalement les journaux, les métriques et les traces, afin de répondre à de nouvelles questions sur son comportement sans déployer de nouveau code. Le terme vient de la théorie du contrôle : en 1960, Rudolf Kálmán a défini un système comme observable si son état interne peut être déterminé à partir de ses sorties. Les équipes logicielles ont adopté ce terme dans les années 2010, lorsque les systèmes se sont répartis entre de nombreux services et que les pannes ne correspondaient plus aux tableaux de bord prévus. Pour les systèmes d’apprentissage automatique, l’observabilité couvre aussi les données et les prédictions : les entrées reçues par un modèle, ses sorties, son niveau de confiance et l’évolution de ces éléments dans le temps.

Journaux, métriques et traces#

Trois types de données de télémétrie, souvent appelés les piliers de l’observabilité, répondent à des questions différentes :

• Métriques : Séries temporelles numériques, comme le taux de requêtes, le taux d’erreurs, les centiles de latence, la mémoire et l’utilisation du GPU, peu coûteuses à stocker et adaptées aux tableaux de bord et aux alertes. Le livre de Google sur l’ingénierie de la fiabilité des sites définit quatre signaux clés à mesurer pour chaque service : la latence, le trafic, les erreurs et la saturation.
• Journaux : Enregistrements horodatés d’événements individuels, particulièrement utiles lorsqu’ils sont structurés en JSON avec des champs comme l’identifiant de requête, la version du modèle et la taille de l’entrée, afin de pouvoir les filtrer et les compter.
• Traces : Parcours d’une requête dans chaque service qu’elle traverse, enregistré sous forme d’arborescence de segments, chacun doté d’un nom, d’une heure de début, d’une durée et d’attributs, qui indique où la requête a passé son temps.

OpenTelemetry, créé en 2019 par la fusion des projets OpenTracing et OpenCensus, fournit des API, des SDK et un protocole de transmission (OTLP) indépendants des fournisseurs pour ces trois signaux. Des systèmes comme Prometheus, Grafana et Jaeger les stockent et les affichent. Cet exemple trace une requête de classification d’image avec le SDK Python OpenTelemetry, en enregistrant un segment parent pour la requête et un segment enfant pour chaque étape :

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}")

Sur un CPU Apple M5 Pro, l’exécution affiche un segment preprocess de 1,0 à 1,4 ms et un segment inference de 7 à 9 ms, tous deux ayant predict comme parent, ainsi qu’un segment predict de 8 à 10 ms. La trace attribue donc au modèle la majeure partie du temps de la requête. Lorsque les segments sont exportés via OTLP, chaque service qui traite une requête ajoute des segments sous le même identifiant de trace, et un système comme Jaeger les affiche sur une même chronologie.

Observabilité et surveillance#

La surveillance des modèles suit les modes de défaillance connus à l’aide de métriques, de tableaux de bord et de seuils d’alerte prédéfinis, par exemple un taux d’erreurs supérieur à 1 % ou une latence d’inférence qui dépasse la cible. L’observabilité est une propriété plus générale qui permet d’enquêter sur des défaillances imprévues en segmentant après coup les données de télémétrie détaillées par client, version de modèle, caméra ou tout autre attribut. Le livre de Google sur l’ingénierie de la fiabilité des sites (SRE) demande à la surveillance de répondre à deux questions — qu’est-ce qui ne fonctionne pas et pourquoi — et l’enquête passe de la première à la seconde en s’appuyant sur les trois signaux :

L’IA explicable est un domaine distinct qui explique pourquoi un modèle a produit une sortie particulière à partir de ses caractéristiques d’entrée ou de ses activations internes ; ses attributions peuvent être enregistrées comme un signal supplémentaire.

Observabilité pour l’apprentissage automatique#

Les systèmes d’apprentissage automatique échouent souvent sans bruit : un modèle de vision par ordinateur peut répondre à chaque requête avec le code HTTP 200 alors que ses prédictions se dégradent parce que la caméra a bougé, que l’éclairage a changé ou qu’un nouveau produit est apparu. L’observabilité du ML ajoute donc aux signaux habituels du service des données de télémétrie sur les données et les prédictions. Les équipes enregistrent des statistiques d’entrée, comme la taille et la luminosité des images, pour détecter la dérive des données, suivent la distribution des prédictions, notamment le nombre de classes, les résultats vides et la confiance moyenne, et calculent la précision par segment lorsque les étiquettes de vérité terrain arrivent, souvent plusieurs jours plus tard. Pendant l’entraînement, des rappels envoient les courbes de perte, les métriques et l’utilisation des ressources système de chaque exécution aux outils de suivi des expériences, comme TensorBoard et MLflow. Pour les applications d’agents d’IA et de grands modèles de langage, les traces enregistrent chaque invite, étape de récupération, appel d’outil et réponse. Les conventions sémantiques GenAI d’OpenTelemetry normalisent des attributs comme gen_ai.usage.input_tokens, afin que le décompte de jetons et les coûts soient cohérents entre les outils.

Chaque point de terminaison dédié sur l’Ultralytics Platform intègre la surveillance du déploiement : cartes du nombre de requêtes, du taux d’erreurs et de la latence p95, onglet Journaux avec niveaux de gravité et filtre Erreurs pour les entrées d’erreur et d’avertissement, et statistiques de prédiction présentant les principales classes, la confiance moyenne au fil du temps, le nombre de prédictions par image et le temps d’inférence du modèle, distinct de la latence des requêtes. Une baisse de la confiance ou une évolution des principales classes apparaît dans ces graphiques, même si toutes les requêtes aboutissent.