MENU

Grafana Tempoとは|トレースID駆動の分散トレース基盤

Grafana Tempo アイキャッチ
Grafana Tempo

Grafana Tempo(グラファナ・テンポ)は、Grafana Labsが2020年に発表したオープンソースの分散トレーシングバックエンドで、トレースIDを用いた検索に特化することで運用コストを最小化したのが特徴です。OpenTelemetry、Jaeger、Zipkin、OpenCensusといった主要なトレースプロトコルを受け入れ、保存先にはS3やGCSなど安価なオブジェクトストレージを採用します。LokiやMimirとともにGrafana LGTMスタックを構成し、メトリクス・ログ・トレースを横断する可観測性体験を低コストで実現するための要となるコンポーネントです。

目次

この記事の目次

  1. Tempoの設計思想と特徴
  2. アーキテクチャと取り込みプロトコル
  3. TraceQLによるトレース探索
  4. Tempo導入時のチェックポイント
  5. まとめ

Tempoの設計思想と特徴

Tempoの設計思想と特徴

Tempoの設計上の最大の特徴は、複雑な属性検索インデックスを最初から持たず、トレースIDで引くことを基本としている点にあります。これにより、トレース1本ごとに高コストな転置インデックスを維持する必要がなくなり、ストレージはオブジェクトストレージのみで完結します。属性検索は新しいバージョンでTempoSearchやTraceQLとして強化されてきましたが、基本思想は「ログやメトリクスからトレースIDを得て、そのIDでトレースに飛び込む」という連携前提です。

この思想は、JaegerやZipkinのように属性検索インデックスを保持する設計と比べてランニングコストを大幅に下げる反面、トレースを起点とした自由探索にはやや弱いという特性を生みます。そこでGrafana Labsは、Lokiのログから自動的にトレースIDを抽出してTempoにジャンプできる仕掛けや、Mimirのエグゼンプラから直接トレースに飛ぶ仕組みを提供し、メトリクス・ログ・トレース間の往復を滑らかに繋ぐ体験を作り込んでいます。

アーキテクチャと取り込みプロトコル

アーキテクチャと取り込みプロトコル

Tempoは、Distributor、Ingester、Compactor、Querierなどのコンポーネントから成り、Lokiと同様にマイクロサービス的にスケールできます。受け入れプロトコルとしてはOpenTelemetry Protocol(OTLP)が中心で、加えてJaegerのthrift/gRPC、Zipkin v1/v2、OpenCensusも対応するため、既存のトレース計装を大きく変えずに導入できる柔軟性を持ちます。アプリケーション側はOpenTelemetry SDKでスパンを送信し、OpenTelemetry Collectorを経由してTempoへ流すのが一般的な構成です。

ストレージはバックエンドオブジェクトストアに依存しており、S3、GCS、Azure Blob、ローカルファイルが選べます。ブロックは時間単位で分割され、Compactorが古いブロックをまとめて最適化することでクエリ性能を維持します。保持期間はバケットライフサイクルで制御でき、コールドストレージとの組み合わせによりトレースの長期保管を低コストで実現できます。

TraceQLによるトレース探索

TraceQLによるトレース探索

Tempoの近年の大きな進化が「TraceQL」と呼ばれるクエリ言語の導入です。これはPromQLやLogQLと並ぶGrafanaスタックの第三のクエリ言語で、サービス名・スパン名・属性・継続時間などの条件を組み合わせ、特定のパターンを持つトレースを抽出できます。たとえば「特定エンドポイントで500ms以上かかったリクエスト」や「DB呼び出しでエラーになったトレース」など、運用で頻出する条件を明示的に書けるようになり、Tempoの実用性は大きく広がりました。

TraceQLの結果はGrafanaダッシュボードのトレースビューと直結し、抽出したトレースをそのままウォーターフォール表示で確認できます。ServiceGraph機能と組み合わせれば、サービス間の依存関係やエラー率を視覚化することも可能で、マイクロサービス環境のトラブル分析やSLO違反原因の特定に活用されています。

Tempo導入時のチェックポイント

Tempo導入時のチェックポイント

Tempoは「全トレースを安く保管」する設計のため、サンプリング戦略をどう取るかが運用設計の中心になります。すべてのリクエストを保存するヘッドベースサンプリング、エラーや遅延を優先するテールベースサンプリングのいずれを採用するかで、ストレージ費用と分析の有用性が大きく変わります。OpenTelemetry CollectorのテールサンプリングプロセッサとTempoを組み合わせ、価値の高いトレースに優先的にリソースを投じる構成が一般的です。

もうひとつの重要ポイントは、アプリケーション側の計装をOpenTelemetryに統一しておくことです。トレースの価値は、アプリ・ライブラリ・DB呼び出しなどが一貫したコンテキスト伝搬で繋がっているかで決まります。Tempo自体は受信側でしかないため、計装の整備とサービス命名規約の統一が、TraceQLや依存関係グラフの精度に直結します。

まとめ

Grafana Tempoは、トレースIDを軸とした安価で大規模な分散トレース保管基盤として、Loki/Mimirと組み合わせたフルOSSの可観測性スタックを支える存在です。TraceQLの登場により、従来弱点とされた属性検索も実用的なレベルに到達しつつあり、マイクロサービスやサーバーレスを含む現代的なアーキテクチャの問題分析に有力な選択肢となっています。サンプリング設計と計装の整備が成功の鍵となるでしょう。

※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

コメント

コメントする

目次