Traceway

Plateforme Go qui reçoit l'OTLP sans Collector

Traceway est une plateforme d'observabilité en Go qui reçoit traces, logs et métriques en OTLP/HTTP, directement depuis un SDK OpenTelemetry, sans Collector. La même interface gère les exceptions, le session replay, les appels LLM et les astreintes. Le README l'oppose à une pile Prometheus, Loki et Tempo à assembler soi-même.

En mode serveur, la télémétrie va dans ClickHouse, comme chez SigNoz. Superlog ingère aussi l'OTLP sur Postgres et ClickHouse, mais confie l'enquête sur les incidents à des agents IA.

Le comparatif des plateformes d'observabilité open source met en regard la base de stockage de Traceway et celle des autres outils, et le volume à partir duquel chacun se justifie.

Stack traces symbolisées dès l'arrivée, iOS et Flutter compris

• Exceptions symbolisées à l'arrivée : chaque stack trace reçoit une empreinte SHA-256 et rejoint une issue classée. Le symbolicateur, en Go, lit source maps, dSYM iOS, mappings R8 et maps d'obfuscation Flutter. Il existe aussi en processeur pour l'OpenTelemetry Collector, compatible avec le source_map_symbolicator de Honeycomb.
• Endpoints classés par impact : latence P50/P95/P99, débit et taux d'erreur par route, triés par Apdex.
• Front et mobile couverts : SDK Traceway pour React, Vue, Svelte, Flutter, Android, iOS et React Native. Le session replay couvre le web et Flutter.
• Appels LLM suivis : coût, tokens, latence et conversations complètes, depuis OpenRouter ou une passerelle IA compatible OTel.
• Astreintes sans produit à part : rotations, politiques d'escalade et relances jusqu'à l'acquittement, par email, Slack, Pushover, Telegram ou SMS.
• SSO inclus : Google, GitHub ou tout fournisseur OIDC, avec les rôles lus dans un claim du jeton.

Dépôt de moins d'un an, tenu par un développeur principal

Le mode de déploiement fixe le plafond. Le docker compose up -d du README lance Traceway avec ClickHouse 24.8 et PostgreSQL 17. L'image SQLite tient dans un conteneur, mais sa documentation la réserve à l'essai ou à une petite instance. L'image DuckDB, recommandée pour un conteneur unique, garde selon la même documentation un tableau de bord réactif avec 10 à 100 fois plus de lignes qu'avec SQLite. Les deux sont mono-instance : plusieurs backends exigent PostgreSQL et ClickHouse.

La mémoire de DuckDB se plafonne à la main. DuckDB vise environ 80 % de la RAM qu'il croit disponible. Sans DUCKDB_MEMORY_LIMIT dans un conteneur limité, la documentation prévient que le backend finit tué par manque de mémoire pendant l'ingestion.

Le compose du dépôt ne monte aucun volume pour Traceway. Source maps, enregistrements de sessions et contenus des traces IA sont écrits sous /app/storage, et disparaissent quand le conteneur est recréé. La documentation ajoute que la symbolication cesse alors de retrouver le code d'origine, sans le signaler. Un volume ou un bucket S3 évite la perte.

La 2.0 est une mise à jour cassante. Publiée sur GitHub le 21 septembre 2026, elle change les tables de traces et une partie de l'API, et l'annonce prévient d'une base plus lourde et de lectures et écritures parfois plus lentes. L'historique se recopie après sauvegarde, avec V2_MOVE_OVER=true. Quatre versions correctives ont suivi, jusqu'à la 2.0.4 du 5 octobre. Le profiling en flame graphs reste marqué expérimental.

Le dépôt a moins d'un an et un développeur principal. Créé en décembre 2025, il a publié 89 versions du backend sur GitHub entre mai et octobre 2026. Sur les 1 056 commits de la branche principale, 823 viennent du même développeur ; le deuxième contributeur humain en signe 40.

Rien n'est réservé au cloud, selon le projet. Le README revendique une licence MIT sans BSL ni open core, et le site annonce la parité fonctionnelle avec Traceway Cloud. Le cloud facture l'hébergement : offre gratuite à 1 Go d'ingestion par mois, Premium à 24,99 $ par mois pour 150 Go.