Tracewayは、一言でいうとアプリの中で起きていることをまとめて見える化するためのツールです。
たとえば、あるWebサービスで「急に遅くなった」「エラーが増えた」「どの処理が悪いのかわからない」といったことが起きたとします。こういうときに欲しいのは、単なるエラーログだけではありません。
Tracewayは、こうした情報をバラバラではなく一つの流れとして扱うのが売りです。
この「つながって見える」というのはかなり重要で、実運用では本当に効きます。ログだけ見てもわからない、トレースだけ見ても足りない、という場面は多いので、ここを最初からまとめているのは素直に強いと思います。
Tracewayは OpenTelemetry-native observability を掲げています。
OpenTelemetry（OTel）は、ざっくり言うとアプリの状態や動作を共通形式で送るための標準規格です。
以前は、監視ツールごとに専用SDKや専用設定が必要で、サービスごとに話が噛み合わないことがよくありました。OpenTelemetryは、その面倒を減らそうという流れの中心にあります。
Tracewayの主張で面白いのは、「OTLP exporter を向けるだけでいい」 という点です。
OTLPはOpenTelemetryの送信プロトコルで、要するに「観測データの運び方」です。
元記事では、
とかなり割り切った言い方をしています。
これはつまり、OpenTelemetryで出しているデータを、そのまま受け取って使える という思想です。
ここはかなり気持ちいい設計思想だと思います。
監視まわりって、気づくと「Aの設定をこうして、Bのフォーマットを変換して、CのCollectorを立てて…」みたいに、道具をつなぐ作業が本体になりがちです。Tracewayはそこを減らしたいわけですね。
元記事の「What's in the box」では、Tracewayが扱う機能がかなり明快に列挙されています。
構造化ログを、trace と結びつけて検索できます。
構造化ログとは、ただ文字列を並べたログではなく、「user_id」「status」「request_id」みたいに項目を分けて保存するログのことです。検索や絞り込みがしやすいのが利点です。
しかも sub-second search とあり、かなり高速検索を意識しているのがわかります。
span waterfall を見られます。
trace は、1回のリクエストや処理の流れを追跡する仕組みで、span はその中の個別の処理単位です。
waterfall というのは、処理が時間軸上でどう重なったかを棒グラフのように見せる表示で、遅さの原因を探るのにかなり便利です。
host / runtime / custom metrics に対応。
metrics は、CPU使用率やメモリ、リクエスト数などの数値データです。グラフにして傾向を見るためのものですね。
「any dimension, any chart」とあるので、自由度をかなり重視していそうです。
例外は SHA-256 normalized stack traces でまとめて、ランキング化された issue にします。
要するに、同じ種類のエラーをまとめて「このエラーが今いちばん目立っている」と見せてくれるイメージです。
ソースマップ対応もあり、webpack / esbuild / Vite に対応しているようです。これはフロントエンド開発ではかなりありがたいです。難読化やビルド後のコードだけ見せられても困るので。
ユーザーがエラー直前に何をしたかを動画のように再現できます。
web向けだけでなく、Flutterにも対応しているのが少し珍しいです。
LLMのコスト、token数、latency、会話内容を追えるとしています。
AI機能を入れると、後から「どれだけ費用がかかったのか」「どこで遅いのか」が見えなくなりがちなので、ここを最初から別カテゴリとして扱っているのは今っぽいです。
元記事では、Tracewayの特徴を 「One system, one trace ID」 と表現しています。
これはすごく大事な発想です。
たとえば、あるユーザーの操作で
という流れが、ひとつの trace ID を軸に見えるなら、原因調査がかなり楽になります。
個人的には、ここがTracewayのいちばん面白いところだと思います。
監視ツールって、機能が増えるほど「結局それぞれ別画面で見ればいいだけでは？」となりがちです。でも、実際の障害対応では“つながっていること”が何より大事です。
Tracewayはそこを真正面から狙っているのが伝わります。
元記事には、Enterprise系の監視ツール（Datadog / New Relic）と、DIYな OSS スタック（Prometheus + Loki + Tempo + ...）との比較表があります。
ざっくり読むと、Tracewayはその中間で、
という立ち位置を目指しているようです。
Enterprise系は便利ですが、課金がイベント数・ホスト数・席数などで増えやすいです。
Tracewayは self-host free, fixed cloud tiers を掲げています。
この「固定料金っぽい安心感」は、予算を立てる側にはかなり魅力的だと思います。
Prometheus、Loki、Tempoなどを組み合わせる構成は自由度が高い反面、つなぎ込みが大変です。
運用の手間、設定の複雑さ、学習コストが重くなりやすい。
Tracewayはそこを「1つで済ませる」方向に振っています。
これ、理想としては最高ですが、裏を返せば1つの製品に機能を集約するぶん、品質の総合力が問われるとも言えます。ここは今後の成熟度が気になるところです。
元記事には、2つの使い方が紹介されています。
もっともわかりやすいのはこれです。
git clone https://github.com/tracewayapp/traceway
cd traceway && docker compose up -d
これで dashboard にアクセスできる、とされています。
そして OpenTelemetry SDK から、
/api/otel/v1/traces/metrics/logsへ送ればよいと書かれています。
要するに、アプリ側からは「送信先をTracewayにする」だけで始めやすいわけです。
このシンプルさは、試すハードルをかなり下げています。
さらに面白いのが embedded mode です。
TracewayをGoプロセスの中で動かせる、と説明されています。外部DB不要、SQLiteベースで動くとのことです。
これはかなり強いです。
小さなサービスや社内ツールなら、監視基盤を別に立てるのが面倒なことがあります。そこに「アプリの中に入れてしまう」というのは、発想としてかなり潔いです。
もちろん、大規模運用では standalone 構成のほうが向いていそうですが、まず試す・小さく始めるにはかなり良さそうです。
元記事では、Tracewayがかなり幅広い統合先を持つことも示されています。
ここでのポイントは、専用SDKに閉じていないことです。
OpenTelemetryベースなので、「その言語専用の魔法の道具を入れないと動かない」という方向ではなさそうです。
この姿勢はかなり好印象です。運用の世界では、独自拡張が増えるほど長期保守がつらくなるので、標準に寄せるのは賢いと思います。
元記事によると、Tracewayの技術スタックは以下のようです。
個人的には、Go + ClickHouse の組み合わせは「観測基盤らしいな」と感じます。
大量のイベントデータをさばく世界では、ClickHouse のような分析向けDBは相性が良いからです。
一方で embedded mode では SQLite を使えるので、軽量に動かす道も用意されている。
この二段構えはかなり実用的です。
Tracewayは、かなり野心的です。
単なるログビューアでもなければ、単なるトレーシング基盤でもなく、observability の主要要素をまとめて握ろうとしています。
ここは魅力的ですが、同時に難しい部分でもあります。
全部入り製品は便利な反面、どこか一部が弱いと「結局、得意分野の専用製品に負ける」ことがあるからです。
ただ、Tracewayは最初から OpenTelemetry を中心に据えているので、少なくとも思想はかなり筋が良いと思います。
「独自フォーマットで囲い込む」のではなく、「標準に乗ってもらう」方針だからです。
また、MITライセンスで self-host できるのも大きいです。
監視・観測系のツールは、あとから課金やライセンスの問題が見えやすい領域なので、最初から明快なのは安心感があります。
Tracewayは、OpenTelemetryを土台にして、logs・traces・metrics・session replay・exceptions・AI tracing をひとつにまとめた観測基盤です。
しかも、Dockerで始めやすく、Goアプリに埋め込む道まで用意されています。
「監視ツールを何個もつなぐのに疲れた」「障害調査をもっと一本化したい」という人には、かなり刺さるはずです。
個人的には、**“全部入り”なのに思想が散らかっていない**ところが好印象でした。
もちろん、実運用でどこまで安定して使えるかは別問題ですが、少なくとも方向性はかなり面白いです。
参考: GitHub - tracewayapp/traceway: The only tool you need to know what is happening and how to fix it.