Avec la contribution de Dan Gomez Blanco (New Relic). Si vous développez un logiciel auto-hébergé ou un produit SaaS, vos utilisateurs finiront par vouloir envoyer leurs logs, traces et métriques vers leur propre pile d'observabilité. Les enfermer dans des tableaux de bord intégrés ou limiter les exportations à certains fournisseurs crée des frictions inutiles. Au contraire, prendre en charge l'export vers tout backend compatible avec Open Telemetry (OTel) est une pratique neutre vis-à-vis des fournisseurs et pérenne, qui laisse aux utilisateurs la liberté de choisir leur pile d'observabilité.
Cet article décrit comment concevoir votre produit pour que les utilisateurs puissent exporter logs, traces et métriques vers un backend OTel lorsqu'ils le souhaitent. Open Telemetry définit quatre types de signaux transmis via le protocole standard Open Telemetry Protocol (OTLP) : les logs (enregistrements d'événements, journaux de requêtes et d'accès, journaux applicatifs avec horodatage et métadonnées), les traces (traces distribuées et spans permettant de suivre le parcours des requêtes entre services et de les corréler aux logs), les métriques (compteurs, jauges et histogrammes, par exemple débits de requêtes, latence, taux d'erreur) et les profils (échantillons montrant où les applications consomment des ressources pendant l'exécution). La logique d'export est la même pour les trois signaux : permettre aux utilisateurs de configurer un point de terminaison OTLP et d'y transmettre leur télémétrie. Vous pouvez prendre en charge un, deux ou les trois signaux selon ce que génère votre produit. De nombreuses plateformes compatibles avec l'export OTel supportent au moins les traces et les logs, et de plus en plus proposent aussi les métriques. Concevoir pour les trois dès le départ évite d'avoir à tout reprendre plus tard.
Une bonne stratégie d'export repose sur quelques propriétés claires pour chaque signal pris en charge : neutralité vis-à-vis des fournisseurs, absence de développement sur mesure approfondi, préservation d'un contexte riche et prise en charge des conventions sémantiques. Deux contextes sont à considérer : où s'exécute votre produit ? Pour un logiciel auto-hébergé, instrumentez votre produit avec Open Telemetry et laissez les clients configurer un point de terminaison via des variables d'environnement ou un fichier de configuration. Pour les plateformes cloud, ajoutez une fonctionnalité de plateforme permettant de gérer les exports. Keycloak et Kuma en sont des exemples.
Source: Hacker News · Résumé par HeadlinesBriefing