KOR IT LAB / 04
Observability Lab
L'Observability Lab traite la conception de la télémétrie comme un problème d'ingénierie de premier ordre. Sa question centrale est celle-ci : que doit émettre un système pour qu'un exploitant ou un analyste puisse reconstituer ce qui s'est passé, et combien cela coûte de l'émettre.
- Télémétrie d'infrastructure
- Télémétrie IA
- Télémétrie des agents
- Télémétrie réseau
- Télémétrie de sécurité
- Pile
- Prometheus · Grafana · Loki · Tempo
- Périmètre
- Machine, inférence, runtime d'agent et événements de sécurité dans un seul patrimoine
Un seul patrimoine de télémétrie pour la performance et la sécurité
Question
La même instrumentation peut-elle répondre aux questions d'exploitation et de sécurité sur un système agentique, ou les deux exigent-elles des pipelines distincts ?
Méthode
Le laboratoire émet métriques machine, performance d'inférence, événements du runtime d'agent, décisions de politique et événements de sécurité vers une seule pile d'observabilité, puis pose les deux types de questions : pourquoi était-ce lent, et qu'est-ce qui a influencé cette décision.
- Règles d'alerte
- 55
- Groupes d'alertes
- 18
- Tableaux de bord
- 6
Mesure relevée sur une configuration testée dans un environnement expérimental. Ce n'est pas un benchmark, et elle n'est transposable ni à un autre matériel, ni à un autre modèle, ni à une autre charge de travail.
Constats
Ces chiffres décrivent la configuration de supervision propre au laboratoire — la pile Prometheus, Grafana, Loki et Tempo bâtie pour observer le comportement des agents dans cet environnement. Ce n'est ni un déploiement client, ni un benchmark. Ils disent quelle quantité d'instrumentation existe, non la qualité de fonctionnement de quoi que ce soit.
- Les questions de performance et de sécurité veulent les mêmes événements à des granularités différentes : l'appel d'outil qui explique un pic de latence est le même que celui qui explique une action.
- Le contexte de trace est ce qui rend l'activité d'un agent reconstituable. Sans identifiant partagé entre récupération, inférence et invocation d'outils, les événements existent mais ne peuvent pas être joints.
- La panne silencieuse est la préoccupation principale dans cet environnement. Un agent qui cesse de récupérer, ou un contrôle qui cesse de s'exécuter, ne produit aucun signal — sauf si l'absence est elle-même instrumentée.
Limites
Prochaines expériences
Écrites avant d'être menées, pour que les résultats soient jugés à l'aune de ce que nous cherchions et non de ce que nous avons remarqué en chemin.
Mesurer la cardinalité et le coût de rétention du tracing au niveau agent à des volumes de sessions réalistes.
Instrumenter l'absence explicitement — construire des détections pour la récupération qui s'est arrêtée, les contrôles qui ne s'exécutent plus et les agents devenus silencieux.
Tester si un identifiant de trace unique survit à la frontière entre le runtime d'agent et les systèmes d'outils en aval.