Zipkin a aidé de nombreuses équipes à faire leurs premiers pas dans le traçage distribué. C'est une solution simple, open source, et qui fait bien l'essentiel. Mais au fur et à mesure que les systèmes deviennent plus complexes, cette simplicité peut commencer à être limitée. Plus de services, plus d'environnements, plus de bruit - et soudain le traçage ne se limite plus à voir le chemin d'une requête.
De nombreuses équipes souhaitent aujourd'hui un traçage qui s'intègre naturellement dans la manière dont elles construisent et livrent des logiciels. Moins de paramétrage manuel, moins de pièces mobiles à maintenir, et un meilleur contexte entre les logs, les métriques et l'infrastructure. C'est là que les alternatives de Zipkin entrent en jeu. Certaines se concentrent sur l'observabilité, d'autres sur la facilité d'utilisation ou l'intégration dans le cloud. Le bon choix dépend généralement de la rapidité avec laquelle votre équipe évolue et de la charge de travail que vous êtes prêt à supporter pour voir ce qui se passe à l'intérieur de votre système.
1. AppFirst
AppFirst aborde la question du traçage sous un angle inhabituel. Ils n'essaient pas de remplacer Zipkin fonctionnalité par fonctionnalité. Au contraire, ils considèrent l'observabilité comme quelque chose qui devrait déjà être présent lors de l'exécution d'une application, et non pas comme quelque chose que les équipes ajoutent plus tard. Le traçage, les logs et les métriques s'inscrivent dans un cadre plus large où les développeurs définissent les besoins de leur application et où la plateforme gère l'infrastructure sous-jacente. En pratique, cela signifie que les données de traçage apparaissent dans le cadre du cycle de vie de l'application, et non comme un système séparé que quelqu'un doit assembler.
Ce qui ressort, c'est la façon dont AppFirst transfère les responsabilités. Les développeurs restent propriétaires de l'application de bout en bout, mais ils ne sont pas impliqués dans les fichiers Terraform, les politiques de cloud, ou les demandes de pull infra juste pour avoir de la visibilité. Pour les équipes habituées à ce que Zipkin fonctionne comme un service de plus à maintenir, cela peut ressembler à une remise à zéro. Le traçage est moins lié à la gestion des collecteurs et du stockage qu'à la visualisation du comportement dans son contexte - quel service, quel environnement, et ce qu'il coûte à faire fonctionner. Ce n'est pas un outil de traçage pur, mais pour certaines équipes, c'est exactement l'objectif.
Faits marquants :
- Approche de l'observabilité et de l'infrastructure axée sur l'application
- Traçage intégré ainsi que journalisation et surveillance
- Pistes d'audit centralisées pour les changements d'infrastructure
- Visibilité des coûts liés aux applications et aux environnements
- Fonctionne sur AWS, Azure et GCP
- Options de déploiement SaaS et auto-hébergées
Pour qui c'est le mieux :
- Les équipes produits qui ne souhaitent pas gérer l'infrastructure de traçage
- Des équipes qui expédient rapidement avec une bande passante DevOps limitée
- Les organisations normalisent la manière dont les applications sont déployées et observées
- Les développeurs qui veulent faire du traçage sans avoir à apprendre l'utilisation d'outils en nuage
Informations de contact :
- Site web : www.appfirst.dev
2. Jaeger
Jaeger est souvent la première alternative sérieuse de Zipkin, surtout lorsque les systèmes distribués commencent à devenir désordonnés. Ils se concentrent sur le traçage lui-même : suivre les requêtes à travers les services, comprendre la latence, et repérer les ralentissements ou les échecs. Jaeger apporte généralement plus de contrôle, plus d'options de configuration, et une meilleure visibilité sur les graphes de services complexes.
L'aspect communautaire est également très présent. Jaeger est open source, gouverné ouvertement et étroitement aligné sur OpenTelemetry. C'est important pour les équipes qui veulent éviter le verrouillage ou s'appuyer sur des normes largement adoptées. La contrepartie, c'est l'effort. Pour bien faire fonctionner Jaeger, il faut penser au stockage, à l'échantillonnage et à la mise à l'échelle. Il convient aux équipes qui sont à l'aise avec cette complexité et qui l'adaptent au fil du temps, plutôt que de s'attendre à ce que le traçage apparaisse par défaut.
Faits marquants :
- Plate-forme de traçage distribuée à source ouverte
- Conçu pour les microservices et les flux de travail complexes
- Intégration poussée avec OpenTelemetry
- Analyse de la dépendance des services et de la latence
- Communauté active et maturité des projets à long terme
Pour qui c'est le mieux :
- Des équipes d'ingénieurs qui exploitent déjà des microservices à grande échelle
- Organisations engagées dans l'utilisation d'outils à code source ouvert
- Les équipes qui souhaitent contrôler finement le comportement du traçage
Informations de contact :
- Site web : www.jaegertracing.io
- Twitter : x.com/JaegerTracing
3. Grafana Tempo
Grafana Tempo prend un chemin différent des systèmes classiques de type Zipkin. Au lieu d'indexer chaque trace, ils se concentrent sur le stockage de grands volumes de données de trace à faible coût et les relient aux métriques et aux journaux lorsque cela est nécessaire. Pour les équipes qui ont atteint les limites de la mise à l'échelle avec Zipkin, cette approche peut sembler plus pratique, en particulier lorsque le volume de traçage augmente plus rapidement que prévu.
Tempo est généralement utilisé avec d'autres outils Grafana, ce qui façonne la façon dont les équipes travaillent avec lui. Les traces ne sont pas toujours la première chose que vous interrogez d'elles-mêmes. Au lieu de cela, les ingénieurs passent d'un pic métrique ou d'une ligne de journal directement à une trace. Ce flux de travail rend Tempo moins axé sur la navigation dans les traces et plus sur la connexion des signaux. Il fonctionne bien si vous vivez déjà dans des tableaux de bord Grafana, mais il peut sembler peu familier si vous vous attendez à ce que le traçage soit une expérience autonome.
Faits marquants :
- Backend de traçage à grande échelle conçu pour le stockage d'objets
- Prise en charge des protocoles Zipkin, Jaeger et OpenTelemetry
- Intégration étroite avec Grafana, Loki et Prometheus
- Conçu pour traiter de très grands volumes de traces
- Open source avec options d'autogestion et d'informatique dématérialisée
Pour qui c'est le mieux :
- Systèmes générant de grandes quantités de données de traçage
- Organisations axées sur le stockage à long terme rentable
- Les ingénieurs qui mettent en corrélation les traces avec les journaux et les mesures plutôt que de parcourir les traces seules.
Informations de contact :
- Site web : grafana.com
- Facebook : www.facebook.com/grafana
- Twitter : x.com/grafana
- LinkedIn : www.linkedin.com/company/grafana-labs
4. SigNoz
SigNoz est généralement considéré comme une alternative à l'utilisation indépendante de Zipkin. Il traite le traçage comme une partie d'une approche plus large de l'observabilité, en l'intégrant aux journaux et aux métriques plutôt qu'en le gardant séparé. Pour les équipes qui ont initialement utilisé Zipkin et qui ont ensuite incorporé d'autres outils, SigNoz devient souvent pertinent lorsque leur ensemble d'outils semble décousu. Sa conception s'articule autour d'OpenTelemetry depuis le début, influençant la collecte de données et les différents signaux pendant le débogage.
Les équipes observent rapidement les avantages en termes de flux de travail. Plutôt que de basculer entre différents outils de traçage, de journalisation et de mesure, SigNoz maintient ces vues intégrées. Un point de terminaison lent peut mener directement à une trace, puis à des journaux connexes sans perdre le contexte. SigNoz n'est pas aussi léger que Zipkin, ce qui est un compromis. Vous gagnez plus de contexte mais vous avez aussi un système plus gros à gérer. Certaines équipes trouvent cela acceptable car leurs systèmes dépassent les besoins de traçage de base.
Faits marquants :
- Conception native d'OpenTelemetry pour les traces, les journaux et les mesures
- Utilise une base de données en colonnes pour traiter les données d'observabilité
- Peut être auto-hébergé ou utilisé en tant que service géré
- Mettre l'accent sur la corrélation des signaux pendant le débogage
Pour qui c'est le mieux :
- Équipes qui utilisent déjà OpenTelemetry dans tous les services
- Les ingénieurs fatigués de devoir assembler plusieurs outils d'observabilité
- Équipes à l'aise avec l'utilisation d'une pile d'observabilité plus large
Informations de contact :
- Site web : signoz.io
- Twitter : x.com/SigNozHQ
- LinkedIn : www.linkedin.com/company/signozio
5. OpenTelemetry
OpenTelemetry n'est pas un outil unique que vous déployez, il fournit un langage commun pour la création et le déplacement des traces, des métriques et des logs. De nombreuses équipes remplacent Zipkin en standardisant OpenTelemetry pour l'instrumentation, puis en choisissant un backend plus tard.
Cette approche modifie la manière dont les décisions en matière de traçage sont prises. Plutôt que de s'enfermer dans un système dès le départ, les équipes instrumentent une fois et gardent leurs options ouvertes. Un service peut commencer par envoyer des traces à un backend simple et passer ensuite à quelque chose de plus avancé sans toucher au code de l'application. Cette flexibilité est séduisante, mais elle s'accompagne de responsabilités. Quelqu'un doit toujours décider où vont les données et comment elles sont stockées. OpenTelemetry ne supprime pas ce travail, il évite simplement les dépendances.
Faits marquants :
- API et SDK neutres pour le traçage, les journaux et les mesures
- Prise en charge de nombreux langages et frameworks dès le départ
- Conçu pour fonctionner avec plusieurs backends, et non pour les remplacer
- Open source et développement communautaire
Pour qui c'est le mieux :
- Les équipes qui souhaitent s'affranchir de Zipkin sans s'enfermer dans un backend
- Organisations normalisant l'instrumentation entre les services
- Les groupes d'ingénieurs qui veulent de la flexibilité dans les outils d'observabilité
Informations de contact :
- Site web : opentelemetry.io
6. Trace ascendante
Uptrace est généralement envisagé lorsque les équipes veulent plus que Zipkin mais ne veulent pas assembler une pile d'observabilité complète elles-mêmes. Ils se concentrent fortement sur le traçage distribué, mais gardent les métriques et les logs suffisamment proches pour que le débogage reste pratique. Les traces sont stockées et interrogées d'une manière qui fonctionne bien même lorsque les requêtes individuelles deviennent volumineuses, ce qui est important lorsque les services commencent à se déployer à travers de nombreuses dépendances.
L'une des particularités d'Uptrace est de trouver un équilibre entre le contrôle et la commodité. Les équipes peuvent l'exécuter elles-mêmes ou utiliser une configuration gérée, mais l'expérience reste assez similaire. Les ingénieurs décrivent souvent le passage de Zipkin comme moins douloureux que prévu, principalement parce qu'OpenTelemetry gère l'instrumentation et qu'Uptrace se concentre sur ce qui se passe après l'arrivée des données. On se sent plus proche d'un système de traçage que d'une plateforme tout-en-un, ce que certaines équipes préfèrent.
Faits marquants :
- Traçage distribué basé sur OpenTelemetry
- Prise en charge de grandes traces avec de nombreuses travées
- Fonctionne à la fois comme une option auto-hébergée et gérée
- Traces, mesures et journaux disponibles en un seul endroit
Pour qui c'est le mieux :
- Systèmes avec des chemins de requête complexes et des traces importantes
- Les ingénieurs qui souhaitent disposer d'OpenTelemetry sans avoir à tout construire eux-mêmes
Informations de contact :
- Site web : uptrace.dev
- Courriel : support@uptrace.dev
7. Marche dans le ciel des Apaches
Apache SkyWalking est généralement envisagé lorsque Zipkin commence à se sentir trop étroit pour ce dont les équipes ont réellement besoin au quotidien. Ils considèrent le traçage comme une partie d'une image plus large de la performance de l'application, en particulier pour les microservices et les systèmes basés sur Kubernetes. Au lieu de se concentrer uniquement sur les chemins de requête, SkyWalking se penche sur la topologie des services, les vues de dépendances et la façon dont les services se comportent dans leur ensemble. En pratique, les équipes l'utilisent souvent pour répondre à des questions telles que la raison pour laquelle un service ralentit tous les autres, et pas seulement pour savoir où une trace unique a échoué.
Ce qui rend SkyWalking différent, c'est tout ce qu'il essaie de couvrir en un seul endroit. Les traces, les métriques et les journaux peuvent tous passer par le même système, même s'ils proviennent de sources différentes comme Zipkin ou OpenTelemetry. Cette étendue peut être utile, mais cela signifie également que SkyWalking fonctionne mieux lorsque quelqu'un se l'approprie.
Faits marquants :
- Traçage distribué avec vues topologiques des services
- Conçu pour les microservices et les environnements à forte densité de conteneurs
- Prise en charge de plusieurs formats de télémétrie, y compris Zipkin et OpenTelemetry
- Agents disponibles pour un large éventail de langues
- Pipelines d'alerte et de télémétrie intégrés
- Option de base de données d'observabilité native
Pour qui c'est le mieux :
- Équipes exécutant des architectures de microservices complexes.
- Des environnements où les relations de service sont aussi importantes que les traces individuelles
- Les organisations qui veulent un système unique de traçage et d'APM
- Des équipes d'ingénieurs à l'aise avec la gestion d'une plateforme d'observabilité plus importante
Informations de contact :
- Site web : skywalking.apache.org
- Twitter : x.com/asfskywalking
- Adresse : 1000 N West Street, Suite 1200 Wilmington, DE 19801 USA
8. Datadog
Datadog aborde les alternatives de Zipkin sous l'angle de la plateforme. Le traçage distribué côtoie les logs, les métriques, le profilage et une longue liste d'autres signaux. Les équipes s'adressent généralement à Datadog lorsque Zipkin répond à certaines questions mais laisse trop de lacunes quant au contexte, en particulier lorsque les systèmes s'étendent sur plusieurs clouds ou équipes.
Dans la pratique, le traçage Datadog apparaît souvent lors des revues d'incidents. Quelqu'un commence par une action lente de l'utilisateur, suit la trace, puis passe aux journaux ou aux mesures d'infrastructure sans changer d'outil. Cette commodité vient du fait que tout est étroitement intégré, mais cela signifie également que Datadog est moins modulaire que les outils de traçage open source. Vous adoptez le traçage en tant qu'élément d'un écosystème plus large, et non en tant que service autonome.
Faits marquants :
- Traçage distribué intégré aux journaux et aux mesures
- Prise en charge de l'auto-instrumentation dans de nombreuses langues
- Exploration visuelle des traces avec des vues de services et de dépendances
- Corrélation entre les données relatives aux applications et à l'infrastructure
Pour qui c'est le mieux :
- Les équipes qui souhaitent que le traçage soit étroitement lié à d'autres données d'observabilité
- Organisations gérant des environnements en nuage de grande taille ou mixtes
- Les groupes d'ingénieurs qui préfèrent une plate-forme unique à plusieurs outils
Informations de contact :
- Site web : www.datadoghq.com
- Courriel : info@datadoghq.com
- Twitter : x.com/datadoghq
- LinkedIn : www.linkedin.com/company/datadog
- Instagram : www.instagram.com/datadoghq
- Adresse : 620 8th Ave 45th Floor New York, NY 10018 USA
- Téléphone : 866 329 4466
9. Nid d'abeille
Honeycomb se concentre fortement sur les données à haute cardinalité et sur la possibilité pour les ingénieurs de poser des questions a posteriori, et non de se contenter de consulter des tableaux de bord prédéfinis. Le traçage dans Honeycomb a tendance à être exploratoire. Les utilisateurs cliquent sur une trace, la découpent en champs personnalisés et suivent des modèles plutôt que des défaillances uniques.
L'expérience est plus investigatrice qu'opérationnelle. Les équipes décrivent parfois Honeycomb comme un outil qu'elles ouvrent lorsqu'un problème semble bizarre ou difficile à reproduire. Il s'agit donc d'un outil adapté au débogage de comportements inconnus, mais il peut s'avérer différent des outils de surveillance traditionnels. Vous ne vous contentez pas de regarder les traces défiler. Il faut les creuser.
Faits marquants :
- Traçage distribué basé sur des données à haute cardinalité
- Forte concentration sur les flux de travail de débogage exploratoire
- Intégration étroite avec l'instrumentation OpenTelemetry
- Des vues de traces conçues pour une investigation à l'échelle de l'équipe
Pour qui c'est le mieux :
- Équipes de débogage de systèmes complexes ou imprévisibles
- Des cultures d'ingénierie qui privilégient les enquêtes approfondies plutôt que les tableaux de bord
Informations de contact :
- Site web : www.honeycomb.io
- LinkedIn : www.linkedin.com/company/honeycomb.io
10. Sentinelle
Sentry a tendance à aborder la question du remplacement de Zipkin sous l'angle du débogage. Sentry se concentre sur la connexion des traces à des problèmes applicatifs réels tels que des points de terminaison lents, des tâches d'arrière-plan échouées ou des plantages que les utilisateurs rencontrent réellement. Le traçage n'est pas traité comme une carte autonome des services, mais comme un contexte autour des erreurs et des problèmes de performance. Un développeur qui suit un flux de paiement lent, par exemple, peut passer d'une action du frontend à des travées du backend et voir où le temps disparaît.
Ce qui différencie Sentry, c'est la façon dont le flux de travail est influencé par les opinions. Au lieu de parcourir les traces pour elles-mêmes, les équipes atterrissent généralement sur les traces par le biais de problèmes, d'alertes ou de régressions après un déploiement. Cela peut être rafraîchissant pour les équipes axées sur le produit, mais moins attrayant si vous souhaitez que le traçage soit une vue neutre de l'infrastructure. Sentry fonctionne mieux lorsque le traçage fait partie du débogage quotidien et qu'il n'est pas ouvert uniquement par les SRE.
Faits marquants :
- Traçage distribué étroitement lié aux erreurs et aux problèmes de performance
- Contexte de bout en bout, des actions du front-end aux services du back-end
- Mesures au niveau des travées pour le suivi de la latence et des défaillances
- Traces liées aux déploiements et aux changements de code
Pour qui c'est le mieux :
- Les équipes de produits déboguent les problèmes rencontrés par les utilisateurs.
- Les développeurs qui souhaitent que la traçabilité soit directement liée aux erreurs
- Les équipes qui se soucient davantage de résoudre les problèmes que d'explorer les cartes de services
Informations de contact :
- Site web : sentry.io
- Twitter : x.com/sentry
- LinkedIn : www.linkedin.com/company/getsentry
- Instagram : www.instagram.com/getsentry
11. Dash0
Dash0 positionne le traçage comme quelque chose qui doit être rapide pour en tirer de la valeur, et non comme quelque chose que l'on babysitte pendant des semaines. Ils construisent tout autour d'OpenTelemetry et supposent que les équipes veulent déjà une instrumentation standard plutôt que des agents spécifiques à un fournisseur. Les traces, les logs et les métriques sont présentés ensemble, mais les traces sont souvent la colonne vertébrale qui relie tous les autres éléments. Les ingénieurs commencent généralement par une requête suspecte et se déploient à partir de là.
L'expérience est intentionnellement rationalisée. Le filtrage des traces par attributs est plus proche de la recherche de code que de la configuration de tableaux de bord, et la configuration en tant que code apparaît très tôt dans le flux de travail. Dash0 est moins destiné à l'analyse historique à long terme qu'aux réponses rapides pendant le développement et les incidents. Cela le rend attrayant pour les équipes qui trouvent les outils d'observabilité traditionnels lourds ou lents à naviguer.
Faits marquants :
- OpenTelemetry-native à travers les traces, les logs et les métriques
- Filtrage des traces à haute cardinalité et recherche rapide
- Prise en charge de la configuration en tant que code pour les tableaux de bord et les alertes
- Corrélation étroite entre les signaux sans câblage manuel
Pour qui c'est le mieux :
- Équipes déjà standardisées sur OpenTelemetry
- Les ingénieurs qui privilégient la rapidité d'investigation aux tableaux de bord complexes
- Les équipes de la plate-forme qui veulent que l'observabilité soit traitée comme du code
Informations de contact :
- Site web : www.dash0.com
- Courriel : hi@dash0.com
- Twitter : x.com/dash0hq
- LinkedIn : www.linkedin.com/company/dash0hq
- Adresse : 169 Madison Ave STE 38218 New York, NY 10016 États-Unis
12. Elastic APM
Elastic APM remplace souvent Zipkin lorsque le traçage doit cohabiter avec les recherches, les logs, et les données système plus larges. Ils traitent le traçage distribué comme un signal dans une configuration d'observabilité plus large construite sur le modèle de données d'Elastic. Les traces peuvent être suivies à travers les services, puis corrélées avec les logs, les métriques, ou même les champs personnalisés que les équipes stockent déjà dans Elastic.
Ce qui ressort, c'est la flexibilité. Elastic APM fonctionne bien dans les environnements mixtes où certains services sont modernes et d'autres non. Le traçage n'oblige pas à faire table rase du passé. Les équipes peuvent instrumenter progressivement, apporter des données OpenTelemetry et analyser le tout via une interface familière. Ce n'est pas une solution minimale, mais elle s'adapte naturellement aux organisations qui utilisent déjà Elastic pour d'autres raisons.
Faits marquants :
- Traçage distribué intégré aux journaux et à la recherche
- Prise en charge de l'instrumentation basée sur OpenTelemetry
- Analyse de la dépendance des services et de la latence
- Fonctionne avec des applications modernes et anciennes
Pour qui c'est le mieux :
- Organisations dotées de systèmes diversifiés ou très anciens
- Les ingénieurs qui souhaitent que le traçage soit lié à la recherche et aux journaux.
Informations de contact :
- Site web : www.elastic.co
- Courriel : info@elastic.co
- Facebook : www.facebook.com/elastic.co
- Twitter : x.com/elastic
- LinkedIn : www.linkedin.com/company/elastic-co
- Adresse : 5 Southampton Street Londres WC2E 7HA
13. Kamon
Kamon s'efforce d'aider les développeurs à comprendre la latence et les défaillances sans avoir besoin d'une expertise approfondie en matière de surveillance. Le traçage est combiné avec des métriques et des journaux, mais l'interface utilisateur pousse les utilisateurs à se poser des questions pratiques telles que le point d'extrémité qui a ralenti ou l'appel à la base de données qui a provoqué un pic après un déploiement.
L'accent est également mis sur des écosystèmes spécifiques. Kamon s'intègre naturellement dans les piles construites avec Akka, Play ou les services basés sur la JVM, où l'instrumentation automatique réduit les frictions de configuration. Comparé à des plateformes plus larges, Kamon semble plus étroit, mais cela peut être un avantage. Les équipes l'adoptent souvent parce qu'il répond à leurs questions quotidiennes sans leur demander de revoir leur approche de la surveillance.
Faits marquants :
- Traçage distribué axé sur les services d'arrière-plan
- Forte prise en charge des piles basées sur la JVM et Scala
- Mesures et traces corrélées pour l'analyse de la latence
- Infrastructure et frais d'installation minimaux
Pour qui c'est le mieux :
- Équipes de développement à forte charge de travail
- Systèmes basés sur la JVM et Akka
- Développeurs souhaitant un traçage simple et pratique sans outil complexe
Informations de contact :
- Site web : kamon.io
- Twitter : x.com/kamonteam
Conclusion
Pour conclure, aller au-delà de Zipkin n'est pas tant une question de recherche de fonctionnalités qu'une question de décision quant à l'intégration du traçage dans le travail quotidien. Certaines équipes souhaitent que les traces soient étroitement liées aux erreurs et aux déploiements afin que le débogage reste proche du code. D'autres s'intéressent plus à la façon dont les services interagissent à l'échelle, ou à l'unification des traces avec les logs et les métriques sans avoir à jongler avec les outils.
Ce qui ressort de ces alternatives, c'est qu'il n'existe pas de voie de mise à niveau unique qui convienne à tout le monde. Le bon choix reflète généralement la manière dont une équipe construit, expédie et corrige un logiciel, et non l'aspect impressionnant d'une interface utilisateur de traçage.
