OpenTelemetry et hébergement web : mesurer ce que votre serveur ralentit vraiment en 2026

Un hébergeur peut afficher une excellente disponibilité tout en ralentissant votre boutique. OpenTelemetry permet de relier chaque requête lente aux ressources du serveur, au code applicatif, à la base de données ou à un prestataire tiers, afin de déterminer sur mesures si l’hébergement est réellement en cause.

Cette observabilité côté serveur complète le RUM, qui mesure l’expérience dans le navigateur. Le RUM constate le ralentissement subi par le visiteur ; OpenTelemetry aide à en expliquer la cause technique.

Pourquoi l’uptime ne suffit pas

Un contrôle de disponibilité vérifie qu’une page répond, souvent depuis quelques emplacements et à intervalles réguliers. Il ne montre pas qu’une requête de paiement attend une connexion MySQL, qu’un processus PHP sature ou qu’un appel à un outil d’avis clients bloque le rendu.

Les graphiques CPU, RAM et disque restent utiles, mais ils sont agrégés au niveau d’une machine ou d’un conteneur. Ils n’indiquent pas quelle route, quel déploiement ou quelle dépendance explique un pic de latence.

Pour une boutique, vérifiez donc que les parcours qui génèrent du chiffre d’affaires — fiche produit, panier, connexion et paiement — restent rapides à une charge réaliste. Ce contrôle complète les mesures décrites dans notre guide sur le RUM appliqué à l’hébergement.

Collecter les signaux utiles

OpenTelemetry normalise la production et l’export de traces, métriques et logs. Il n’est ni un outil de visualisation ni un stockage : il alimente la solution retenue, comme Grafana, Datadog, New Relic ou un backend compatible avec le protocole OTLP.

Les traces découpent une requête en segments, ou spans : réception HTTP, exécution PHP ou Node.js, requêtes SQL, cache, génération du HTML et appel externe. La propagation de contexte définie par W3C Trace Context permet de suivre la même trace entre services lorsque ceux-ci transmettent les en-têtes nécessaires.

Collectez aussi le débit, la durée, les codes HTTP et les erreurs, regroupés par route normalisée plutôt que par URL complète. Ajoutez les signaux de saturation accessibles : CPU, mémoire, réseau, système de fichiers, workers, files d’attente et connexions à la base de données.

Le OpenTelemetry Collector peut centraliser les données avant leur export. Son hostmetrics receiver recueille des métriques de l’hôte, mais un hébergement mutualisé ou managé peut ne pas y donner accès : cette limite doit entrer dans l’évaluation de l’offre.

Reliez les logs applicatifs et d’accès à un identifiant de trace ou de requête. Une erreur de paiement peut alors être consultée depuis la trace, avec son message, son horodatage et son environnement.

Ne placez jamais de mots de passe, cookies de session, jetons d’accès, coordonnées bancaires ou données personnelles dans les attributs, traces et logs. Limitez aussi les paramètres d’URL collectés : leur cardinalité augmente les coûts et peut exposer des données inutiles.

Attribuer la lenteur et fixer des SLO

Comparez les traces lentes aux traces normales de la même route, puis recherchez une corrélation avec les métriques de la plateforme. Une requête lente isolée ne suffit pas à incriminer un hébergeur ; un motif répété pendant une période représentative est plus exploitable.

• Hébergement ou infrastructure : le délai avant le traitement applicatif augmente, les temps d’attente des workers ou les métriques de saturation montent, et plusieurs routes sont touchées simultanément.
• Code ou base de données : un span applicatif ou SQL domine régulièrement la trace, souvent sur une route, une extension, une version ou une requête précise.
• Service tiers : un span HTTP sortant vers un prestataire concentre l’essentiel du délai ou des erreurs. Si le tiers ne propage pas le contexte, mesurez au minimum l’URL cible, le statut et la durée, sans collecter de données sensibles.

Par exemple, si /checkout passe plusieurs secondes dans un appel HTTP sortant, changer de serveur ne résoudra probablement pas le problème principal. Si le délai avant l’exécution du code augmente lors des pics, avec des workers saturés, la capacité allouée ou l’architecture d’hébergement devient une piste prioritaire.

Définissez peu de SLO sur les parcours critiques : disponibilité et taux d’erreur du panier, de la connexion et de la validation de commande ; latence côté serveur en percentile élevé ; durée et échecs des dépendances indispensables ; saturation durable des ressources accessibles. Commencez avec une application, quelques routes et les dépendances les plus importantes.

Échantillonnez les traces si le volume devient important, tout en conservant les erreurs et les requêtes lentes selon les capacités de votre outil. Avant une migration, comparez les mêmes routes, le même trafic et les mêmes versions applicatives ; cette méthode aide à évaluer un hébergement premium avec les bonnes métriques.