Il existe un moment précis dans chaque incident d’infrastructure où l’on réalise qu’on navigue à l’aveugle. Un service est dégradé, des utilisateurs sont impactés, et le premier réflexe — ouvrir vCenter — affiche des graphes CPU, mémoire et réseau qui ne montrent rien d’anormal. Pendant ce temps, quelque chose au niveau applicatif échoue silencieusement.
C’est exactement ce que l’observabilité est conçue pour prévenir. Et pourtant, la majorité des plateformes VCF que je rencontre sont instrumentées uniquement pour la visibilité couche infrastructure. Les workloads Kubernetes qui tournent dessus génèrent une masse de données — events, logs, métriques, traces — que personne ne collecte de façon systématique.
Cet article pose le cadre conceptuel. Avant de déployer Prometheus ou de configurer Fluent Bit, il faut comprendre précisément ce que représente chaque signal d’observabilité, ce qu’il ne peut pas vous dire, et comment les trois signaux se composent en tableau de bord cohérent. Le projet OpenTelemetry a formalisé ces définitions. C’est la référence que nous utilisons.
La spécification OpenTelemetry : un vocabulaire commun
La spécification OpenTelemetry est l’effort CNCF pour standardiser comment les données d’observabilité sont générées, collectées et transmises. Sa valeur première n’est pas dans les outils — c’est dans le vocabulaire commun qu’elle fournit. Quand vous dites “span”, “trace”, “metric point” ou “log record” dans un contexte OTel, tout le monde dans la salle parle de la même chose.
La spécification distingue trois types de signaux, chacun avec un modèle de données et une sémantique distincts.
Métriques — Une mesure capturée à un instant donné, agrégée sur une série de points. Le modèle de données OTel définit six types d’instruments : Counter, UpDownCounter, Gauge, Histogram, ObservableCounter et ObservableGauge. Un point de métrique porte une valeur, un timestamp et un ensemble d’attributs. Les métriques sont le signal le plus compact : elles perdent le détail de chaque événement en échange d’une agrégation efficace et d’une rétention longue durée.
Logs — Un enregistrement d’un événement discret. Le modèle OTel définit un LogRecord avec un timestamp, un observed timestamp, un contexte de trace (traceId, spanId), un numéro de sévérité, un texte de sévérité, un corps et des attributs. Les logs portent le contexte le plus riche par événement, au prix du volume — un cluster actif produit des millions de lignes de logs par minute.
Traces — Un enregistrement du parcours d’une requête distribuée à travers les services. Une trace est un graphe acyclique orienté de spans. Chaque span a un nom, des timestamps de début/fin, un statut, des attributs, des événements et des liens. Le modèle de trace est ce qui rend le débogage distribué possible : on peut suivre une requête utilisateur unique depuis l’API gateway à travers cinq microservices et identifier exactement quel appel base de données a ajouté 400ms.
Les trois signaux ne sont pas des alternatives. Ils sont complémentaires. Une alerte sur une métrique vous dit que quelque chose ne va pas. Les logs vous disent ce qui s’est passé. Une trace vous dit où la latence ou l’erreur trouve son origine dans le graphe d’appels.
Pourquoi les environnements VCF ont besoin des trois couches
Une erreur fréquente chez les équipes plateforme est de confondre observabilité et monitoring. Le monitoring consiste à surveiller des modes de défaillance connus — poser des seuils sur des métriques déjà comprises. L’observabilité est la propriété d’un système qui permet de poser des questions arbitraires sur son état interne à partir de ses sorties externes.
Les plateformes VCF combinent plusieurs couches avec des caractéristiques opérationnelles très différentes. La couche hyperviseur (ESXi, vSAN, NSX) est gérée et émet des métriques structurées via l’API vSphere et Aria Operations. Le plan de contrôle Kubernetes (Supervisor, clusters VKS) expose des métriques via l’endpoint /metrics de ses composants. Les workloads applicatifs dans les pods sont largement opaques sans instrumentation.
Le gap que personne ne corrige
Aria Operations et vROps donnent une excellente visibilité infrastructure. Ils ne donnent pas de traces distribuées. Ils ne donnent pas de logs applicatifs structurés. La première fois qu’un développeur demande “pourquoi mon API est lente ?” et que vous n’avez pas de traces, vous comprendrez le gap.
Chaque couche nécessite un mécanisme de collecte différent :
- Métriques ESXi et vSAN disponibles via Aria Operations (vROps) ou via l’API vSphere interrogée par des exporters comme
vsphere-exporterpour Prometheus. - Métriques composants Kubernetes (kube-apiserver, etcd, kubelet, kube-scheduler) scrapées directement par Prometheus via des ressources ServiceMonitor.
- Métriques applicatives nécessitant soit de l’auto-instrumentation (agents OTel Java/Python/Go) soit des appels explicites au SDK depuis le code applicatif.
- Logs des pods écrits sur stdout/stderr et collectés par un DaemonSet (Fluent Bit, Fluentd ou Vector) vers un backend de centralisation.
- Traces nécessitant de l’instrumentation — via les SDKs OTel ou via le tracing au niveau service mesh (Istio, Linkerd) qui capture les spans au niveau proxy.
Architecture de référence pour VCF + VKS
L’architecture qui fonctionne en production pour une plateforme VCF combine deux couches de collecte.
La première couche est la couche infrastructure : Aria Operations collecte les métriques hôte, cluster, datastore et NSX. Ces métriques couvrent la contention de ressources, les performances vSAN, la saturation réseau et les événements plateforme. Aria Operations est la source de vérité pour la visibilité couche infra.
La deuxième couche est la couche cloud-native : une stack Prometheus (kube-prometheus-stack via Helm) dans chaque cluster VKS collecte les métriques composants Kubernetes, les métriques nœuds (via node-exporter) et les métriques applicatives. Grafana fournit les dashboards corrélant les deux couches via remote_write depuis Aria Operations.
Fluent Bit tourne en DaemonSet dans chaque cluster VKS, collectant les logs pods et les transmettant à Loki. L’OpenTelemetry Collector tourne en Deployment, recevant l’OTLP des applications instrumentées et transmettant les traces à Tempo ou Jaeger.
ESXi / vSAN / NSX
│
Aria Operations ──── remote_write ──── Prometheus
│ │
API vROps Grafana
│ │
Loki Tempo
│ │
Fluent Bit OTel Collector
│ │
Pods VKS ──┘Cette architecture évite le piège de déployer une plateforme d’observabilité monolithique pour tout l’estate VCF. Elle compose à la place des outils spécialisés : Aria Operations pour l’infrastructure, Prometheus pour les métriques Kubernetes, Loki pour les logs, Tempo pour les traces, unifiés sous Grafana comme couche unique de requête et de dashboard.
Choisir le bon outil pour chaque signal
La question du choix d’outils est souvent surcompliquée. Les principes sont simples.
Métriques : Prometheus vs Aria Operations vs InfluxDB
Logs : Loki vs Elasticsearch vs Splunk
Traces : Jaeger vs Tempo vs Zipkin
Collecte : OTel Collector vs agents par langage
Les quatre golden signals et leur application
Les quatre golden signals — latence, trafic, erreurs, saturation — ont été définis par le livre SRE de Google comme l’instrumentation minimum nécessaire à la production. Ils se mappent sur les trois piliers d’observabilité de façon prévisible.
La latence se mesure mieux avec les traces (P50/P95/P99 au niveau span) et les histogrammes (métriques Prometheus _bucket). Les logs peuvent enregistrer la latence par requête mais s’agrègent mal.
Le trafic est un signal métrique : requêtes par seconde, octets par seconde, événements par seconde. Les compteurs Prometheus sont l’outil naturel.
Les erreurs vivent à la fois dans les métriques (compteurs de taux d’erreur) et dans les logs (enregistrements de niveau erreur). Les traces portent un statut d’erreur sur les spans, permettant de corréler “cette trace contient une erreur” avec le service responsable.
La saturation est principalement un signal infra : CPU ready time, pression mémoire, profondeur de file disque, drops de buffers réseau. Ces données viennent de la couche infrastructure — Aria Operations ou node-exporter — pas de l’instrumentation applicative.
Démarrer sans tout instrumenter en même temps
Le mode d’échec le plus fréquent dans les projets d’observabilité est de tenter d’instrumenter tout simultanément. Le résultat est un déploiement de plusieurs mois qui ne délivre aucune valeur tant que tout n’est pas terminé.
L’approche pragmatique consiste à commencer par les deux signaux qui ont le meilleur ratio temps-à-valeur pour les opérations en production. Les métriques d’abord — déployer kube-prometheus-stack avec la configuration de scrape par défaut donne immédiatement la santé des composants Kubernetes, l’utilisation des ressources nœud et le nombre de redémarrages pods sans écrire une ligne de code applicatif. Les logs ensuite — un DaemonSet Fluent Bit avec le filtre de métadonnées Kubernetes donne des logs pods structurés avec namespace, nom de pod, nom de conteneur et labels nœud immédiatement interrogeables dans Loki.
Les traces arrivent en dernier, parce qu’elles nécessitent de l’instrumentation applicative. Les agents d’auto-instrumentation pour Java, Python, Go et Node.js peuvent réduire significativement la charge, mais ils requièrent quand même un changement de déploiement par application. Réservez le tracing distribué aux services où l’analyse de latence est un besoin de production documenté.
Les articles suivants de cette série couvrent chaque couche en détail : les patterns de déploiement Prometheus et Grafana pour VKS dans le prochain article, la configuration Loki et Fluent Bit dans le troisième, la conception du pipeline OTel Collector dans le quatrième, et l’intégration Aria Operations avec la stack open source dans le cinquième.
Références.
- Spécification OpenTelemetry — Signaux — définitions officielles des modèles de données métriques, logs et traces
- CNCF Observability Whitepaper — patterns d’observabilité vendor-neutral pour les plateformes cloud-native
- Google SRE Book — Monitoring Distributed Systems — les quatre golden signals et la philosophie d’alerte
- Modèle de données Prometheus — séries temporelles basées sur les labels, types de métriques et conventions de nommage
- Broadcom TechDocs — Aria Operations — référence officielle pour les métriques d’infrastructure vSphere
Reçois le prochain par email
Les nouveaux articles et séries, envoyés à leur publication. Aucun autre courrier.
