Observabilité avec VictoriaTraces : monitoring vs tracing OpenTelemetry

Temps de lecture : 16 min

Monitoring vs Observabilité

« Le monitoring est une action passive. L’observabilité est une pratique active » — tiré de l’excellent livre Learning OpenTelemetry. Distinguons-les clairement.

Monitoring : vous savez à l’avance ce qui peut casser et vous configurez des alertes spécifiques : « CPU > 90 % => alerte », « Disque saturé à 85 % => alerte », « Erreurs 5xx sur l’ALB => alerte ». Cela répond à des questions que vous avez déjà formulées.

Observabilité : le système vous permet de répondre à des questions que vous n’aviez pas prévues. Quand quelque chose « d’étrange » survient, vous pouvez creuser pour en trouver la cause, même si vous ne l’avez jamais rencontrée. Le mot-clé est explorabilité : la capacité à investiguer les connexions et causes des problèmes.

Exemple concret : la latence d’une API Backend augmente. Le monitoring indique simplement « latence élevée » via une alerte. L’observabilité permet de descendre dans les détails : est-ce un point de terminaison spécifique ? Un locataire particulier ? Un Pod Kubernetes ? Une source amont lente ? On va du symptôme à la cause grâce aux données déjà présentes dans le système.

C’est pourquoi on parle des trois piliers de l’observabilité : métriques, logs, traces. Les traces distribuées sont ce qui distingue « simple monitoring » de l’observabilité réelle, car elles permettent d’investiguer un problème inconnu en suivant le chemin d’une requête à travers les services.

Exemple de débogage piloté par les traces

Reprenons l’exemple : une alerte Slack indique que la latence de l’API Backend sur le endpoint /coach a grimpé à 20 secondes.

L’alerte contient un lien vers un tableau de bord Grafana avec l’état de l’ALB AWS, un lien vers VictoriaLogs avec les logs de l’ALB et de l’API, et un lien vers le tableau de bord des Pods Kubernetes et de la base de données RDS.

Sans traces, on avance à tâtons : on examine le CPU/RAM des nœuds Kubernetes, la charge sur les Pods voisins, les métriques de PostgreSQL, en essayant de reconstituer l’image du problème.

Avec les traces, on ouvre les traces lentes pour ce endpoint, et on voit immédiatement : sur les 120 ms totales de la requête, 80 ms sont passées sur une seule requête SQL. On examine les attributs de cette span — db.statement : SELECT * FROM orders WHERE user_id=42, sans index utilisé. La cause racine est trouvée en une minute.

Qu’est-ce que OpenTelemetry ?

OpenTelemetry (OTel) est un ensemble de règles communes sur la façon dont les données doivent être collectées et les métadonnées présentes. Chaque action d’un service est un signal au sens OTel.

Le protocole OTLP (OpenTelemetry Protocol), défini dans la spécification 1.10.0, décrit comment transmettre les données (HTTP/gRPC) et les champs et en-têtes qu’elles doivent porter, unifiant métriques, logs et traces dans un format unique.

Avec OTel, on collecte ces signaux au niveau du code, depuis les Pods/Nœuds Kubernetes ou l’API AWS, on les transforme en ajoutant des attributs, on les fusionne dans un contexte partagé, puis on les transmet à une backend de stockage : métriques vers VictoriaMetrics, logs vers VictoriaLogs, traces vers VictoriaTraces.

OpenTelemetry vs Prometheus

Avec VictoriaMetrics ou Prometheus, l’approche classique pour les métriques consiste à exposer un endpoint /metrics, que VictoriaMetrics VMAgent interroge périodiquement (modèle PULL). Le format est simple : metric_name{label= »value »} 123.45.

OpenTelemetry fonctionne généralement en mode PUSH : le service envoie lui-même les données à l’instance Collector OTel, qui les achemine vers la backend adéquate. Néanmoins, les receveurs OTel Collector peuvent aussi interroger certaines API, comme k8s_cluster qui interroge /apis/apps/v1/deployments pour obtenir des informations supplémentaires sur les Pods Kubernetes.

Pourquoi OpenTelemetry si Prometheus existe déjà ?

Le format Prometheus est excellent pour les métriques, mais Prometheus ne gère ni les traces ni les logs structurés, et surtout ne lie pas une métrique, un log et une trace ensemble. Avec VictoriaLogs pour les logs et VictoriaMetrics pour les métriques, ce sont des systèmes séparés avec leurs propres formats, ce qui complique la corrélation : une métrique spécifique n’est pas automatiquement liée à un log ou une trace.

OTel résout ce problème : quand les métriques, logs et traces transitent par un seul SDK, ils obtiennent automatiquement un contexte partagé : trace_id, service.name, deployment.environment, kubernetes.pod.name. Ainsi, d’une alerte sur une métrique, on peut sauter à la trace d’une requête spécifique, et de la trace aux logs d’une span. Sans OTel, ces trois systèmes vivent isolés et il faut les relier manuellement.

Composants OpenTelemetry

OpenTelemetry se compose de trois parties principales :

• SDK OTel : intégré dans le code, il génère la télémétrie. Pour l’auto-instrumentation, il suffit de quelques lignes au démarrage du service pour obtenir des spans pour HTTP, gRPC, SQL.
• Collector OTel : un service séparé (DaemonSet ou Deployment dans Kubernetes) qui reçoit les données du SDK, les transforme et les envoie aux backends.
• OTLP (OpenTelemetry Protocol) : le format et protocole de transmission, fonctionnant sur gRPC ou HTTP, supporté par pratiquement toutes les backends modernes (VictoriaMetrics, Grafana Tempo, Jaeger, Datadog).

Instrumentation OpenTelemetry

Le terme instrumentation désigne l’ajout de code spécifique dans un service pour permettre l’observabilité. OpenTelemetry propose trois niveaux :

• Zéro-code instrumentation : on ne modifie pas le code du tout — le service est invoqué via un wrapper externe qui intercepte les appels et ajoute les données nécessaires. Rapide mais peu flexible.
• Auto-instrumentation : le SDK OTel crée automatiquement des spans pour les appels HTTP, les clients DB, les appels gRPC. On ajoute simplement des bibliothèques au code.
• Instrumentation manuelle : on ajoute nos propres spans et attributs pour la logique métier que l’auto-instrumentation ne peut pas voir — par exemple, une span pour le traitement d’un élément d’un batch, ou un attribut order.total_items sur un appel SQL.

En pratique, on commence souvent par l’auto-instrumentation pour obtenir une vision de base, puis on ajoute progressivement de l’instrumentation manuelle là où le contexte manque pour déboguer des problèmes spécifiques.

Qu’est-ce que VictoriaTraces ?

VictoriaTraces est basé sur VictoriaLogs : il reçoit les données du Collector OTel au format JSON via OTLP et les écrit dans son propre format en transformant les noms de champs. Le projet est encore en phase « work in progress », mais déjà parfaitement utilisable.

Comme VictoriaLogs, VictoriaTraces forme des champs flux (stream fields) qui optimisent le stockage et la recherche. Chaque span enregistrée appartient à un flux spécifique, de la même manière qu’un log appartient à un flux de logs. L’attribut service.name est utilisé comme champ flux.

VictoriaTraces dispose de sa propre interface VM UI pour rechercher des traces via LogsQL, mais pour visualiser l’arbre des traces, Grafana reste plus adapté. On peut aussi collecter des métriques sur VictoriaTraces lui-même, et il faut surveiller l’utilisation du disque pour la rétention.

Déploiement de VictoriaTraces dans Kubernetes

VictoriaTraces propose un mode instance unique et un mode cluster (haute disponibilité). Pour mon usage, l’instance unique suffit. Il existe des charts Helm dédiés : victoria-traces-single et victoria-traces-cluster.

Pour configurer, on écrit un fichier values.yaml où on définit le type de déploiement (Deployment plutôt que StatefulSet), un Ingress via AWS ALB, un disque persistant et une période de rétention (30 jours par exemple). Le service expose l’endpoint OTLP/HTTP sur /insert/opentelemetry/v1/traces.

On peut pousser une trace de test avec curl pour vérifier que tout fonctionne.

Et voilà, VictoriaTraces est opérationnel. Il ne reste plus qu’à ajouter l’instrumentation à notre code.

VMAlert et règles d’enregistrement avec VictoriaTraces

Une fonctionnalité intéressante : on peut utiliser des Recording Rules qui interrogent VictoriaTraces, via vmalert avec type= »vlogs ». La logique est la même que pour les métriques issues de logs. Si vous avez déjà une instance vmalert pour les logs, il faut en créer une seconde car le datasource.url est différent.

Exemple avec kind: VMAlert : on définit datasource.url pointant vers VictoriaTraces, remoteWrite pour écrire les métriques générées, et ruleSelector pour choisir les VMRules. On peut ainsi créer une métrique, par exemple le 95e percentile de la durée des spans pour un service donné.

Les métriques générées apparaissent dans VictoriaMetrics et peuvent être utilisées dans Grafana ou dans des alertes.

Intégration de VictoriaTraces avec Grafana

Pour utiliser Grafana avec VictoriaTraces, on ajoute une source de données de type Jaeger (l’intégration native arrivera plus tard). L’URL pointe vers le service VictoriaTraces avec le chemin /select/jaeger.

On peut activer Trace to Logs et Trace to Metrics : en explorant, un clic sur un trace_id génère des liens vers les logs et métriques associés. C’est un gain de temps énorme pour le débogage.

VictoriaLogs, Derived Fields et VictoriaTraces

Le plugin VictoriaLogs pour Grafana supporte les champs dérivés (derived fields) : on peut créer une règle regex qui extrait le trace_id du log et crée un lien vers la trace dans VictoriaTraces.

Après configuration, en ouvrant un log avec un champ trace_id, un bloc « Links » apparaît, et en cliquant on navigue directement vers la trace correspondante. C’est un pont très pratique entre les logs et les traces.

Dans le prochain article, on plongera dans l’instrumentation concrète avec OpenTelemetry et la création de traces depuis une application Python.