Le traçage OpenTelemetry sans toucher à votre infrastructure

La plupart des guides « ajouter de l’observabilité à votre application Rails » commencent par monter un collecteur. La partie vraiment fastidieuse, ce n’est pas le collecteur — c’est de faire entrer les bonnes variables d’environnement dans chaque environnement de façon cohérente, à la main, sans fautes de frappe, à chaque fois qu’un nouveau service rejoint la famille.

Ce que la plateforme définit vraiment

Settings → General → OpenTelemetry prend un endpoint OTLP, un protocole (http/protobuf, http/json ou grpc), et des en-têtes optionnels — une clé API pour Honeycomb, par exemple. Les en-têtes sont stockés chiffrés. Au prochain déploiement, Railyard définit exactement ce que tout SDK OpenTelemetry s’attend déjà à lire :

• OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_PROTOCOL, OTEL_EXPORTER_OTLP_HEADERS
• OTEL_SERVICE_NAME — le nom de l’application elle-même, pas quelque chose à inventer
• OTEL_RESOURCE_ATTRIBUTES — porte le SHA du commit, l’environnement, l’application et l’équipe, pour qu’une trace soit attribuable à un déploiement précis sans avoir à câbler ça soi-même

Définissez l’une de ces variables vous-même et votre valeur l’emporte — c’est une valeur par défaut, pas un verrouillage.

Ce qui vient avec votre application, pas avec la plateforme

Les variables sont côté plateforme. L’instrumentation elle-même reste le SDK neutre vis-à-vis du fournisseur, que vous ajoutez comme n’importe quelle autre dépendance :

• Rails : opentelemetry-sdk, opentelemetry-exporter-otlp, opentelemetry-instrumentation-all avec c.use_all, sur http/protobuf.
• Node : @opentelemetry/auto-instrumentations-node/register.
• Python : opentelemetry-instrument.

Rien de tout ça n’est spécifique à Railyard — le même SDK fonctionne sans modification contre n’importe quel collecteur OTLP, ce qui est le vrai but du protocole. Le travail de la plateforme s’arrête à bien définir les variables à chaque fois, pas à remplacer la couche d’instrumentation.

Les propres métriques de la plateforme, sur le même tuyau

Cochez aussi envoyer le CPU, la mémoire et les métriques de requêtes de Railyard et la plateforme poste ses propres chiffres vers <endpoint>/v1/metrics chaque minute, en OTLP sur HTTP — pour que les métriques d’infrastructure et les traces applicatives arrivent dans le même backend au lieu de deux tableaux de bord séparés à corréler mentalement.

Où ça se situe par rapport aux logs et aux alertes

OpenTelemetry couvre les traces et les métriques; la recherche de logs au quotidien, les recherches sauvegardées avec alertes, et les drains de logs vers votre propre destination sont un chemin séparé et plus simple qui n’a besoin d’aucun SDK — utile quand une trace est excessive et que vous avez juste besoin de grep la sortie de production. Les alertes de métriques (temps de réponse p95, taux de 5xx, mémoire, CPU) fonctionnent indépendamment du fait qu’OTel soit configuré ou non.

Référence complète : Logs, métriques et alertes.