OpenTelemetry
Un point d’entrée OpenTelemetry pour les métriques et les traces de votre appli elle-même, qui rejoignent ce que while mesure déjà.
Mis à jour le 9 novembre 2026.
Vous, à votre agent : Branche OpenTelemetry pour suivre le temps des requêtes à la base.
Ce que reçoit votre appli
Votre appli reçoit ces variables d’environnement à chaque mise en ligne :
| Variable | Ce qu’elle contient |
|---|---|
OTEL_EXPORTER_OTLP_ENDPOINT | Le point d’entrée OTLP/HTTP, joignable sans ouvrir les sorties. |
OTEL_SERVICE_NAME | Le nom sous lequel le service apparaît. |
Quand vous en servir
Servez-vous-en pour les métriques et les traces de l’appli elle-même, avec un SDK OpenTelemetry.
Comment ça marche
Un point d’entrée OTLP/HTTP (OTEL_EXPORTER_OTLP_ENDPOINT, joignable sans ouvrir les sorties) reçoit les journaux et les métriques de l’appli, qui rejoignent ceux de while dans l’espace de l’organisation (outils get_logs et observe_app). Ses traces sont gardées 30 jours et se lisent avec observe_app { view: "traces" }.
Ce qu’il faut savoir
Les traces se lisent par service (OTEL_SERVICE_NAME, le nom du projet par défaut) ou par identifiant. D’une trace qui traverse plusieurs projets, seule la part de l’environnement est rendue.
Seul OTLP/HTTP est accepté, pas gRPC, avec 4 Mio par envoi. Les métriques arrivent en protobuf (gzip, deflate ou zstd). Une métrique au nom réservé à la plateforme (cnpg_, kube_, container_, while_, node_, envoy_, vm_…, et up), ou un attribut name, est rangée sous appli_…, et la réponse le dit (renommees).
Les outils MCP de votre agent
Votre agent s’en occupe avec les outils get_logs et observe_app.