OpenTelemetry pour Symfony v2.0 : logs, métriques et traces enfin unifiés
L'observabilité en production est souvent le parent pauvre des projets PHP. On déploie, on croise les doigts, et quand ça plante, on fouille les logs à la main. La sortie de la v2.0 du bundle traceway/opentelemetry-symfony change concrètement cette réalité pour les applications Symfony.
Voici pourquoi cette release mérite votre attention.
Les trois piliers de l'observabilité, enfin dans un seul bundle
L'observabilité moderne repose sur trois signaux complémentaires :
- Les traces : le chemin complet d'une requête à travers vos services
- Les métriques : les données agrégées sur la santé de votre système
- Les logs : les événements discrets horodatés
Jusqu'ici, ces trois dimensions coexistaient difficilement dans l'écosystème PHP/Symfony. Ce bundle, entièrement écrit en PHP pur (aucune extension C requise), les réunit sous une interface unifiée conforme à la spécification OpenTelemetry.
Depuis la v1.0 lancée il y a deux mois avec le tracing HTTP, Messenger et HttpClient, neuf releases stables ont enrichi le périmètre de façon méthodique.
Ce que les versions 1.x ont progressivement apporté
Traces : une couverture exhaustive de l'infrastructure Symfony
La v1.5 a introduit le support de Doctrine DBAL 3 et 4 dans le même package, ainsi que NamespacedPoolInterface pour le cache. Concrètement, chaque requête SQL devient une span tracée avec ses attributs de durée et d'erreur.
La v1.9 a complété le tableau avec l'instrumentation du Mailer (séparation des spans PRODUCER et CLIENT, attributs email.* alignés ECS) et du Scheduler (span CONSUMER par tâche planifiée, déduplication automatique des enveloppes portant un ScheduledStamp).
Logs : export natif OTel avec Monolog
La v1.6 a introduit un handler Monolog avec :
- Une portée d'instrumentation par canal
- Une précision à la microseconde sur les timestamps
- Les attributs d'exception OTel
- Un garde contre la récursion lors de l'export des logs
La v1.8 a ajouté les attributs code.* de la sémantique OTel via IntrospectionProcessor de Monolog, permettant de relier automatiquement un log à son fichier source et son numéro de ligne.
Métriques : du Messenger à Doctrine en passant par HTTP
La fondation métriques posée en v1.7 avec MeterRegistry a rapidement évolué. La v1.8 a généralisé les métriques à l'ensemble du stack :
| Composant |
Métrique exposée |
| Doctrine |
db.client.operation.duration |
| HTTP Client |
http.client.request.duration |
| Messenger |
messaging.process.duration, messaging.client.consumed.messages |
| HTTP Server |
http.server.request.duration |
| Mailer |
métriques de transport |
Toutes ces métriques suivent les conventions sémantiques stables d'OpenTelemetry, ce qui garantit leur compatibilité avec Prometheus, Grafana, Datadog ou tout autre backend OTLP.
La v2.0 : une configuration unifiée avec rétrocompatibilité
La nouveauté structurante de cette version majeure est la configuration groupée par signal. Plutôt que de disséminer les options de traces, métriques et logs dans des blocs séparés et hétérogènes, la v2.0 propose une hiérarchie de configuration claire et cohérente.
Une couche de compatibilité ascendante (BC layer) est incluse pour les projets qui migrent depuis une v1.x : pas de réécriture brutale de votre config/packages/open_telemetry.yaml.
Ce qui distingue l'ensemble de la démarche :
- Aucune release bêta : chaque version est sortie directement en stable
- PHPStan niveau 10 sans baseline, sur l'intégralité du code
- PHPUnit 13 intégré dans la matrice de tests dès la v1.9
Ce niveau d'exigence qualité est rare dans l'écosystème des bundles communautaires.
Pourquoi c'est un changement concret pour le debugging en production
Corréler un log d'erreur avec la trace distribuée correspondante et la métrique de latence associée n'est plus un luxe réservé aux équipes avec des outils commerciaux onéreux. Avec ce bundle :
- Un
trace_id commun relie vos logs Monolog à la span OpenTelemetry active — vous passez du log à la trace en un clic dans votre outil d'observabilité.
- Les métriques sémantiques vous alertent sur une dégradation (
db.client.operation.duration en hausse) avant que les utilisateurs ne remontent le problème.
- L'instrumentation automatique de Messenger, Doctrine, HttpClient et Mailer couvre les points d'intégration les plus critiques sans écrire une ligne de code d'instrumentation manuelle.
Le tout s'exporte vers n'importe quel backend compatible OTLP : OpenTelemetry Collector, Jaeger, Tempo, Honeycomb, etc.
Conclusion
La v2.0 de traceway/opentelemetry-symfony marque une étape de maturité : les trois piliers de l'observabilité sont couverts, la configuration est rationalisée, et la qualité du code est au niveau des standards les plus exigeants.
Si votre application Symfony tourne en production et que vous naviguez encore à l'aveugle lors des incidents, c'est le bon moment pour intégrer ce bundle. L'investissement de configuration est minimal, le gain en visibilité est immédiat.
📖 Article source : OpenTelemetry for Symfony: v2.0 is out par Jovan Stojiljkovic sur DEV Community.
