Grafana Tempoとは？分散トレーシングの仕組み・TraceQL・導入判断を実装者向けに解説

Grafana Tempoは、マイクロサービスをまたぐリクエストの経路を記録する「分散トレーシング」のバックエンドです。トレースをオブジェクトストレージへそのまま貯め込む設計を採り、サンプリング前提の従来型バックエンドより保管コストを抑えられます。この記事で扱うのは、トレース・スパンといった基礎、インジェスターやコンパクターといった内部構成、TraceQLとmetrics-generatorの機能、そしてモノリシックモードとマイクロサービスモードのどちらを選ぶべきかまで。実際に構築・運用する技術者の目線で整理します。版番号は2026年7月時点の実測値です。

まとめ：Tempoはトレース保管の低コスト化に振り切ったバックエンド

Grafana Tempoは、Grafana Labsが開発するオープンソースの分散トレーシングバックエンドです。要点は3つ。第一に、トレースの保管先を専用データベースではなくAmazon S3などのオブジェクトストレージに置き、全件保存でも保管費を低く抑えます。第二に、TraceQLという専用クエリ言語でスパンの属性を条件にトレースを検索できます。第三に、metrics-generatorがトレースからサービスグラフやRED系メトリクスを生成し、Prometheus互換の書き込み先へ送れる点です。

導入判断の軸は、扱うトレース量と運用体制の2つ。単一バイナリで動くモノリシックモードは学習と小規模運用に向き、コンポーネントを個別スケールさせるマイクロサービスモードは高トラフィックのプロダクション向けです。ログはLoki、メトリクスはPrometheus、トレースはTempoという役割分担で、Grafana上の1画面から相互にたどれる構成が基本形になります。計装の入口となるOpenTelemetry（OTel）の考え方を先に押さえると、Tempoの位置づけが掴みやすくなります。

Grafana Tempoの定義と分散トレーシングにおける位置づけ

まず「トレースとは何か」を実装単位で確認します。ここが曖昧なままだと、Tempoが保存している中身とTraceQLの検索対象がずれて理解されがちです。

トレース・スパン・スパンコンテキストが支える基本データ構造の理解

1件のリクエストがサービスAからB、Cへと渡る一連の処理が「トレース」です。トレースは複数の「スパン」で構成され、各スパンは処理区間の開始・終了時刻、サービス名、HTTPステータスなどの属性を持ちます。スパン同士は親子関係でつながり、どの処理がどれを呼び出したかをたどれる仕組みです。この親子関係を運ぶのが「スパンコンテキスト」で、trace_idとspan_idを次のサービスへ伝搬させます。Tempoはこのスパン群をtrace_id単位でまとめて保存し、後からIDやTraceQL条件で引き出す役割を担います。

Loki（ログ）・Prometheus（メトリクス）と並ぶ一本柱としての役割

可観測性は、メトリクス・ログ・トレースの3種類のテレメトリーで対象を観測します。Tempoが担うのはトレースの一本柱です。メトリクスは異常の発生を数値で知らせ、ログは個々の事象を詳細に残し、トレースは「どのサービス間で遅延やエラーが起きたか」を経路として示す担当です。役割の違いはオブザーバビリティ（可観測性）と監視の違いを整理した記事に詳しく、ログ側の設計はGrafana LokiとLogQLの解説が対応します。3つを同じGrafanaで束ねると、メトリクスの異常からトレース、該当スパンのログへと一気にたどれる構成になります。

サンプリングを前提にしない保存設計思想と他バックエンドとの違い

従来のトレーシングバックエンドの一部は、全トレースを保存するとインデックス費用がかさむため、事前にサンプリングして一部だけ残す設計でした。この方式には、まれにしか起きないエラーや遅延のトレースを取りこぼす弱点があります。Tempoは、検索用の巨大なインデックスを持たず、trace_idとオブジェクトストレージ上のブロックだけで引ける構造を採りました。全件保存でも保管費を抑える方向に振った設計です。全部貯めてから必要な分だけ探す、という思想の違いが、他バックエンドとの一番の分かれ目になります。

Grafana Tempoのアーキテクチャと主要コンポーネントの分担

Tempoは複数のコンポーネントが役割分担する構成です。単一バイナリで全役割を同居させることも、役割ごとにプロセスを分けて個別にスケールさせることもできます。

ディストリビューター・インジェスター・コンパクター・クエリアの分担

受信から検索までの流れは、次の担当に分かれます。ディストリビューターがトレースデータを受け取って振り分け、インジェスターが一定時間バッファしてブロックにまとめオブジェクトストレージへ書き出します。コンパクターは細かいブロックを定期的に統合して読み取り効率を上げ、古いブロックを保持期間に従って削除する担当です。検索時はクエリフロントエンドがリクエストを分割し、クエリアが並列にブロックを走査します。マイクロサービスモードでは、書き込みが多い時はインジェスター、検索が重い時はクエリアだけを増やす、といった片側スケールが可能になります。

vParquetブロック形式とオブジェクトストレージ保存先の選択

Tempoはトレースを列指向のParquetベースのブロック形式（vParquet系）で保存します。現行の版ではvParquet4系が既定で、スパンの属性を列として持つためTraceQLでの絞り込みが効く形式です。保存先はオブジェクトストレージで、Amazon S3、Google Cloud Storage、Azure Blob Storage、ローカルファイルシステム、MinIOなどのS3互換に対応します。クラウド上で運用する場合、既に使っているストレージをそのまま保存先にできるため、専用の永続ボリュームを別途用意せずに済むのも利点です。ストレージ側のライフサイクル設定とTempoの保持期間設定を二重に効かせないよう、削除の主導権をどちらに持たせるかは設計時に決めておきます。

OTLP受信とOpenTelemetry Collector・Alloyのパイプライン

Tempo自体はOTLP（OpenTelemetry Protocol）をgRPC/HTTPでネイティブに受信し、Jaeger・Zipkin・OpenCensusの各プロトコルも受け付けます。ただし、アプリケーションからTempoへ直接送るより、間に収集・変換の層を挟むのが定石です。OpenTelemetryで計装を標準化し、OpenTelemetry CollectorやGrafana Alloyがトレースを受けてバッファ・整形し、Tempoへ転送します。この中間層があると、送信先の切り替えやサンプリング方針の変更を、アプリのコードに手を入れずに済ませられる利点があります。なお2.8系では既定のHTTP待受ポートが80から3200へ変わっており、既存構成を上げる際は受信ポートの指定を確認しておきましょう。

TraceQLとmetrics-generatorでできること

Tempoの価値は保存だけでなく、貯めたトレースをどう引き、どう指標化するかにあります。ここがJaegerなど他ツールとの機能差になる部分です。

TraceQLによる属性ベースのトレース検索とクエリ記述の基本

TraceQLは、スパンの属性を条件にトレースを絞り込む専用クエリ言語です。「レイテンシーが2秒を超えたスパンを含むトレース」「特定サービスで500エラーを返したトレース」といった条件をそのまま書けます。2.8系ではsum_over_timeやtopk/bottomkなどの集計関数、親スパンを指すspan:parentID、最新結果を優先するmost_recentといったヒントが加わりました。単なる検索から傾向分析へ踏み込める拡張です。trace_idを知らなくても、症状の条件から該当トレースへ到達できる点が、ID検索中心の運用との差になります。

metrics-generatorによるサービスグラフとスパンメトリクス

metrics-generatorは、流入するトレースからメトリクスを生成するコンポーネントです。主な出力は2つ。1つはサービスグラフで、どのサービスがどれを呼び、その間の遅延やエラー率がどうかを図として描きます。もう1つはスパンメトリクスで、リクエスト数・エラー数・処理時間（いわゆるRED系）を時系列メトリクスとして出す機能です。生成したメトリクスはPrometheus互換のリモート書き込み先へ送るため、既存のPrometheusやMimirへ集約できます。個別に計装しなくてもトレースから概況メトリクスが得られるため、計装が追いついていないサービスの可視化に効きます。

Grafanaデータソース設定とログ・メトリクスへの相関ジャンプ

GrafanaにはTempoのデータソースが組み込まれており、TraceQLでの検索やトレース詳細のウォーターフォール表示、ノードグラフ表示をそのまま行えます。可視化基盤の選択肢はAmazon Managed Grafanaの解説にまとめた通りで、自前運用かマネージドかを分けられる構成です。連携の要はtrace-to-logsとtrace-to-metricsで、トレースの1スパンからLokiの該当ログや、Prometheusの関連メトリクスへワンクリックで飛べます。3つのデータソースをtrace_idやラベルで結び付けておくと、障害調査の初動が「メトリクス異常→トレース→ログ」の一筆書きになります。

Grafana Tempo導入モードの選び分けと採用・見送りの判断

ここからは、実際に入れるかどうかの判断です。Tempoは無償で試せますが、運用にはストレージとコンピュートの継続費がかかります。規模と体制を見て、モードと採否を言い切ります。

モノリシックモードとマイクロサービスモードの損益分岐点の見極め

単一バイナリのモノリシックモードは、全役割を1プロセスで動かすため構成がシンプルで、学習環境や1日あたり数百万スパン程度までの小〜中規模に向きます。まずはこのモードで始めて問題ありません。一方、スパン量が増えて書き込みと検索の負荷がぶつかり始めたら、マイクロサービスモードへ移してインジェスターとクエリアを別々にスケールさせる判断になります。分岐の目安は、単一ノードのメモリやディスクI/Oが張り付き、検索が書き込みに引きずられて遅くなったタイミングです。最初からマイクロサービスモードを組むのは、Kubernetes運用の手間に見合うトラフィックがある場合に限ります。小規模で全部盛りにすると、コンポーネント間調整の負担だけが先に来る失敗パターンに陥ります。

Grafana Tempoを採用すべき要件と見送るべき場面の判断

採用が向くのは、複数サービスにまたがるリクエストで「どこが遅いか」を経路で特定したいケース、全トレースを残してまれな障害を追いたいケース、そしてGrafana・Loki・Prometheusを既に使っていてトレースだけ欠けているケースです。逆に、モノリシックな単一アプリで外部依存が少なく、ログとメトリクスで原因が十分たどれる段階なら、トレース基盤の導入は見送ってよい場面と言えます。分散トレーシングの効果はサービス間の呼び出しが多いほど大きく、呼び出しが浅い構成では計装とストレージのコストが先に立ちます。トレーシングを入れる前に、計装するサービス境界とサンプリング方針を決めていないと、貯めるだけで使われないデータが増えるだけです。基盤の構築や既存監視への組み込みで手が足りない場合は、システムの保守運用・内製化支援で設計から運用移管まで伴走できます。

Grafana Tempoのバージョン更新時の破壊的変更への備え

Tempoは2.8系・2.9系（2026年7月時点）と版が進んでおり、メジャー更新には破壊的変更が含まれます。2.8系では既定HTTPポートの80から3200への変更、サーバーレス機能の削除、属性サイズ上限の適用強化などが入りました。更新時はリリースノートのアップグレード項目を追い、ブロック形式の互換とポート・設定キーの変更を検証環境で確認してから本番へ上げます。ブロック形式はエンコードを切り替えても既存ブロックは旧形式のまま読めますが、新形式の恩恵を受けるには一定期間の書き込みか再圧縮が要ります。版番号と設定の対応は、公式ドキュメントの当該版を一次情報として確認してください。

Grafana Tempoの導入・運用に関するよくある質問と回答

導入検討でよく挙がる論点を、実装・運用の観点で簡潔にまとめます。

Grafana TempoとJaegerは何が違いますか？

両者とも分散トレーシングのバックエンドですが、保存設計が異なります。Jaegerは検索用にElasticsearchやCassandraといったインデックス付きストレージを併用する構成が一般的で、TempoはオブジェクトストレージとTraceQLだけで引ける設計です。Tempoは巨大なインデックスを持たないぶん保管費を抑えやすく、既にGrafana・Loki・Prometheusを使う環境と親和します。JaegerのUIやプロトコルに合わせたい場合は、TempoがJaegerプロトコルの受信に対応している点も補足しておきます。

Tempoの利用に費用はかかりますか？

オープンソース版のTempoはソフトウェア自体が無償で、自前のサーバーやKubernetes上で運用できます。実際の費用はオブジェクトストレージの保管量とデータ転送、Tempoを動かすコンピュートに対して発生する仕組みです。全件保存でも保管費が抑えやすい設計ですが、無料ではなくストレージ従量が積み上がる点は把握しておきましょう。運用込みで任せたい場合は、Grafana Cloudのマネージドサービスという選択肢もあります。

OpenTelemetryは必須ですか？

必須ではありませんが、実務ではOpenTelemetryでの計装が標準的な入口になります。TempoはOTLPに加えてJaeger・Zipkin・OpenCensusのプロトコルを受信できるため、既存の計装を活かして送ることも可能です。新規に計装するなら、ベンダー中立で切り替えしやすいOpenTelemetryを選ぶと、送信先をTempoから別バックエンドへ変える際もアプリ側の書き換えを避けられます。

小規模なチームでもTempoを運用できますか？

モノリシックモードなら単一バイナリで動くため、少人数でも運用できます。まずはこのモードでオブジェクトストレージを1つ用意して始めるのが現実的な進め方です。トラフィックが増えて単一ノードで捌けなくなった段階でマイクロサービスモードへ移せば、初期から複雑な構成を抱えずに済みます。Kubernetes運用の知見が薄い段階で分割構成を組むのは、得られる効果より運用負担が上回りやすい選択です。

ログやメトリクスの基盤と一緒に入れるべきですか？

可観測性はメトリクス・ログ・トレースの3つがそろって初めて障害の初動が速くなります。既にPrometheusでメトリクス、Lokiでログを運用しているなら、トレースをTempoで足すと欠けていた「サービス間の経路」が埋まります。3つを同じGrafanaに束ね、trace-to-logs・trace-to-metricsで相互に飛べるようにしておくと、調査の往復が減る構成です。ゼロから3つ同時に入れる場合は、まずメトリクスとログを整え、サービス境界が増えてきたタイミングでトレースを追加する順序が無理のない進め方になります。

関連記事

• OpenTelemetry（OTel）とは｜3つのシグナル・OTLP・Collectorを解説：Tempoへトレースを送る計装・パイプラインの上流。OTLP受信の前提を押さえられます。
• Grafana Lokiとは？Prometheus連携・LogQL・導入をわかりやすく解説：可観測性のログの一本柱。Tempoのトレースからログへたどる連携先です。
• Amazon Managed Grafanaとは？料金・データソース・使い方：Tempoを可視化するGrafana側の選択肢。マネージド運用の判断に使えます。
• オブザーバビリティ（可観測性）とは？監視との違い・3本柱・主要ツール：Tempoが担うトレースを含む、可観測性全体の位置づけを整理した概念ハブです。