【2026年】Tempo 分散トレーシング構築ガイド2026｜自宅で学ぶOTel連携

読み込み中…

ソフトウェア品質知識体系ガイド(第3版): SQuBOK Guide V3

Docker Compose によるローカル環境の構築手順

自宅学習や小規模テスト環境では、Docker Compose を利用した構成が最も効率的です。2026 年時点の標準的な設定として、Tempo 2.7 と Grafana 11.5 のコンテナイメージを同時に起動し、OpenTelemetry Collector も含めた構成を作成します。まず、プロジェクトディレクトリに docker-compose.yml を作成します。このファイルでは、各サービスのリンクとボリュームマウントを設定し、永続化されたストレージの確保を行います。

version: '3.8'

services:
  otel-collector:
    image: grafana/otel-collector:latest
    container_name: otel-collector
    ports:
      - "4317:4317" # OTLP gRPC
      - "55680:55680" # OTLP HTTP
      - "9411:9411" # Zipkin
    command: ["--config=/etc/otel-collector-config.yaml"]
    volumes:
      - ./otel-config.yaml:/etc/otel-collector-config.yaml

  tempo:
    image: grafana/tempo:2.7
    container_name: tempo
    ports:
      - "3200:3200" # Tempo API
      - "9095:9095" # gRPC receiver for Jaeger/Zipkin
    volumes:
      - ./data:/tmp/tempo
    command: ["-config.file=/etc/tempo.yaml"]

  grafana:
    image: grafana/grafana:11.5
    container_name: grafana
    ports:
      - "3000:3000"
    environment:
      - GF_INSTALL_PLUGINS=grafana-tempo-app,grafana-loki-logs-datasource

  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - "9090:9090"

この設定では、Tempo のデータはコンテナ内部の /tmp/tempo ディレクトリに保存されます。ローカル環境であれば問題ありませんが、永続性は考慮していないため、本番环境ではストレージクラスの変更が必要です。また、OpenTelemetry Collector は OTLP/gRPC（ポート 4317）と HTTP（55680）、そして Zipkin 互換モード（9411）を有効化しています。これにより、多様なプロトコルをサポートするアプリケーションからのデータ収集が可能な状態になります。

Kubernetes と Helm を用いた本番環境へのデプロイ

本番環境や大規模なマイクロサービスシステムでは、Kubernetes 上での運用が必須となります。Helm Chart を利用することで、複雑な設定を一元管理し、バージョン制御も容易になります。2026 年時点の Grafana Helm Charts は、Tempo のサポートが強化されており、ストレージバックエンドの設定も柔軟に行えます。特に重要なのは、永続ボリューム（Persistent Volume）の設定です。ディスク容量や IOPS を考慮した StorageClass の選択が必要です。

まず、Helm リポジトリにアクセスします。helm repo add grafana https://grafana.github.io/helm-charts としてから、値の定義を行う必要があります。values.yaml ファイルでは、Storage Backend に S3 や MinIO を指定することが推奨されます。ローカルディスクよりもスケーラビリティが高く、コスト効率が良いからです。また、Tempo はシャーディング機能を提供しており、大量のデータを受け取る際にも負荷分散が可能です。

# Helm values 抜粋例
tempo:
  enabled: true
  deploymentMode: Distributed # または Monolithic
  storageType: s3
  config:
    overrides:
      spec.containers[0].env:
        - name: AWS_ACCESS_KEY_ID
          valueFrom:
            secretKeyRef:
              name: tempo-s3-creds
              key: ACCESS_KEY
        - name: AWS_SECRET_ACCESS_KEY
          valueFrom:
            secretKeyRef:
              name: tempo-s3-creds
              key: SECRET_KEY

  resources:
    limits:
      cpu: "2"
      memory: "4Gi"
    requests:
      cpu: "500m"
      memory: "1Gi"

この設定では、Tempo コンテナのリソース制限を明示的に定義しています。CPU とメモリは、収集するトレースの量によって調整が必要です。特に 2026 年においては、データ圧縮アルゴリズムの進化により、より少ないリソースで大量データを扱えるようになっていますが、安定稼働のためには十分なバッファを持たせることが推奨されます。また、Kubernetes の HPA（Horizontal Pod Autoscaler）と連携させ、トラフィックに応じて自動スケールさせる構成も可能です。

OpenTelemetry Collector 設定の徹底解説

OpenTelemetry Collector は、分散トレーシングの心臓部です。アプリケーションからデータを受け取り、Tempo に送るまでのパスを制御します。otel-collector-config.yaml の作成は、プロジェクトの要件に応じて行います。ここでは標準的な OTLP Receiver と Tempo Exporter を設定した例を示します。

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:55680
  
processors:
  batch:
    timeout: 1s
    send_batch_size: 1024
  memory_limiter:
    check_interval: 1s
    limit_mib: 2048

exporters:
  otlp:
    endpoint: tempo:3200
    tls:
      insecure: true
  
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, memory_limiter]
      exporters: [otlp]

この設定では、batch プロセッサが重要な役割を果たします。データを一括で送信することで、ネットワークのオーバーヘッドを削減し、Tempo への負荷を均一化します。また、memory_limiter は Collector 自体のメモリ不足を防ぐ安全装置です。2026 年時点では、CPU の性能向上により、サンプリングロジックをより細かく制御することが可能になっており、重要度の高いトレースだけを優先的に保存する機能も標準装備されています。

さらに、特定の Span Attribute をフィルタリングしたり、ユーザー ID などの機密情報をマスキングする Processor を追加することも可能です。セキュリティとパフォーマンスのバランスを取るためにも、Collector の設定は慎重に行う必要があります。例えば、attributes.action=drop を使用して機密データを除外することで、コンプライアンス要件を満たしつつトレーシングを継続できます。

アプリケーション計装の実践手法

アプリケーションにトレース機能を実装する際、OpenTelemetry Auto-Instrumentation（自動計装）が最も推奨されます。2026 年現在では、主要な言語に対してネイティブなサポートが提供されています。Java では Java Agent を起動時に指定し、Go や Python にはパッケージをインストールして初期化するだけで済みます。

• Java: -javaagent:/path/to/opentelemetry-javaagent.jar オプションを JVM に渡すことで、Spring Boot や Jakarta EE のフレームワークが自動的にトラケシングされます。設定ファイル opentelemetry-javaagent.properties でサンプリング率（例：OTEL_TRACES_SAMPLER=always_on）を指定可能です。
• Python: pip install opentelemetry-api opentelemetry-sdk 後、tracer = tracer_provider.get_tracer("my-app") を用いて初期化します。Django や Flask のプラグインを使用すれば、フレームワークレベルの計装も自動で行われます。
• Node.js: @opentelemetry/auto-instrumentations-node パッケージをインストールし、NODE_OPTIONS=--require @opentelemetry/instrumentation で起動します。AWS Lambda 環境でもスムーズに動作します。

手動計装が必要なケースもあります。特定のロジック部分のみを追跡したい場合や、外部ライブラリが未対応の場合です。その際は startActiveSpan メソッドを呼び出し、開始と終了を明示的に記述します。ただし、手動計装はコードの保守性を下げるリスクがあるため、Auto-Instrumentation の使用を優先し、例外処理の一部のみを手動で行うのがベストプラクティスです。

ストレージバックエンドの選定とコスト比較

分散トレーシングシステムにおいて、ストレージの選択はコストパフォーマンスに直結します。Tempo は複数のストレージバックエンドをサポートしており、プロジェクトの規模や予算に応じて選定できます。2026 年時点での主要なオプションには、Filesystem（ローカルディスク）、S3（AWS S3 互換オブジェクトストレージ）、MinIO（オンプレミス S3 クラウド）、GCS（Google Cloud Storage）、Azure Blob Storage があります。

各ストレージの特性を比較すると、Filesystem は設定が最も簡単でパフォーマンスが高いですが、スケーラビリティに欠けます。一度に処理するデータ量が膨大になるとディスク容量不足や I/O ボトルネックが発生します。一方、S3 や GCS などのオブジェクトストレージは、ほぼ無限に近い容量を提供し、データ転送コストこそ発生しますが、長期保存には最適です。MinIO はオンプレミス環境で S3 と同等の機能を提供するため、クラウドベンダーロックインを避けたい場合に人気があります。

以下の表は、主要なストレージバックエンドの比較と 2026 年時点の概算コストを示しています。

コスト計算においては、ストレージ容量だけでなく、データ取得（Get）や転送（Egress）の料金も考慮する必要があります。例えば、頻繁にトレースデータを検索する場合、S3 の Get 回数が膨大になると予想外のコストが発生することがあります。その場合は、Tempo のキャッシュ機能や、Prometheus などのメトリクスシステムとの連携を検討し、頻度の低いデータはアーカイブストレージへ移すなどの戦略も有効です。

TraceQL によるクエリと分析の実践

Grafana Tempo の特徴である TraceQL は、分散トレースデータを検索・分析するための専用クエリ言語です。PromQL（Prometheus）や LogQL（Loki）とは構文が異なりますが、直感的に理解しやすい設計になっています。TraceQL を使うことで、特定のサービス名を持つ Span や、一定時間以上のレイテンシを持つリクエストを抽出できます。

基本的なクエリの構文は service.name="order-service" && trace.state="error" のようになります。また、duration > 5s で遅延しているトレースを絞り込みます。TraceQL は属性（Attributes）やリソース（Resources）に基づくフィルタリングも強力です。例えば、特定のユーザー ID や地域に基づいてデータを集計することも可能です。

service.name="payment-service" && duration > 10s { http.status_code = "500" } | sum(rate(duration)) by (http.status_code)

このクエリは、「支払いサービスで 10 秒以上かかったトレースのうち、HTTP ステータスコードが 500 のもののレイテンシを合計する」ものです。これにより、エラー発生時のパフォーマンス影響度を数値化できます。また、Grafana 11.5 では、TraceQL エディタにインテリジェント補完機能が実装されており、属性の自動補完やスニペットの挿入が可能になっています。

さらに、メトリクス生成機能も備わっています。TraceQL で集計した結果をメトリクスとして Grafana に送ることで、トレースデータを時系列グラフとして可視化できます。例えば、エラー率の変動を追跡したり、平均レスポンスタイムのトレンド分析を行ったりすることが可能です。これにより、単なるログの検索ではなく、システム全体の健康状態を把握するダッシュボード作成が容易になります。

Grafana ダッシュボードと連携機能

Grafana 11.5 は、Tempo との統合機能をさらに強化しています。特に「Service Graph（サービスグラフ）」機能は、サービス間の依存関係や通信パターンをビジュアル化します。これにより、どのサービスが他社に依存しすぎているか、またはボトルネックとなっているかを目視で確認できます。

また、「Trace Timeline」ビューでは、トレース内の Span の順序と時間軸を詳細に表示します。タイムライン上で特定の Span をクリックすると、その処理の詳細情報やスタックトレースを確認できます。2026 年版では、この表示がよりインタラクティブになっており、マウスオーバーでリアルタイムにメトリクス値を表示する機能も追加されています。

Exemplars（例示）機能は、ログやメトリクスとトレーシングデータの連携において重要です。例えば、Prometheus のエラーレートグラフ上で特定の異常点をクリックすると、対応するトレースが Tempo から自動展開されます。逆に、Tempo で特定のエラートレースを選択すると、関連する Loki のログエントリが表示されます。これにより、開発者は複数のツールを切り替えることなく、コンテキストの維持したまま調査を進めることが可能になります。

Jaeger や Zipkin からの移行戦略

多くの企業やプロジェクトで既存の分散トレーシングシステムとして運用されているのが、Jaeger や Zipkin です。Grafana Tempo へ移行する際は、データの互換性と運用コストを考慮した戦略が必要です。2026 年時点では、OTel の標準化により、新規システムでは Jaeger や Zipkin を採用しないケースが増えています。しかし、レガシーシステムからの移行は現実的な課題です。

Tempo は OTLP プロトコルをサポートしているため、OpenTelemetry Collector を経由してデータを収集すれば、Jaeger や Zipkin のクライアントライブラリを使用していたアプリケーションも容易に統合できます。具体的には、Collector 設定で Jaeger gRPC または HTTP Receiver を有効化し、Tempo Exporter と接続するだけです。これにより、既存のコードを変更することなくデータフローを Tempo に転送することが可能です。

移行プロセスでは、以下のステップが推奨されます。まず、並行運用モードで Collector を設定し、新旧両方のシステムへデータをエクスポートします。その後、一定期間（例：1 ヶ月）をかけて、Tempo のデータ信頼性を確認します。最後に、アプリケーションのトラフィックを完全に Tempo 側へ切り替え、Jaeger や Zipkin のインフラを段階的に廃止します。このアプローチにより、移行中のダウンタイムリスクを最小限に抑えることができます。

競合ツールとの機能比較と選定理由

分散トレーシング市場には複数の選択肢があります。Grafana Tempo を含む主なコンペティターとして、SigNoz、Honeycomb、Datadog APM が挙げられます。それぞれの特性を比較し、なぜ Tempo が自宅学習や中規模システムに適しているのかを分析します。特にコストと機能のバランスが重要な基準となります。

SigNoz は、OpenTelemetry 完全対応で Grafana のような UI を提供しますが、独自ストレージバックエンドを使用するため、特定のアーキテクチャに依存しやすい傾向があります。Honeycomb は、開発者体験（DX）において非常に優れた UX を提供しますが、高価であり小規模な学習環境には向きません。Datadog APM は、機能は豊富ですが、クラウドベースの SaaS でありデータ転送コストやライセンス費用が高騰します。

以下の表では、主要な分散トレーシングツールを比較しています。

Tempo の最大の利点は、Grafana とのネイティブな統合とストレージの柔軟性です。オンプレミス環境や自宅サーバーでも動作するため、クラウド依存を避けたい場合に最適です。また、Apache License 2.0 の OSS ライセンスであるため、商用利用も制限なく行えます。一方、Datadog APM はサポート体制が整っていますが、コストとデータロックインのリスクがあります。学習目的やコスト重視のプロジェクトでは Tempo が圧倒的に有利と言えます。

よくある質問（FAQ）

Q1. Grafana Tempo を自宅サーバーで動かす際、必要なリソースはどれくらいですか？ A1. 基本的には低スペックでも動作しますが、推奨構成は CPU 2 コア、メモリ 4GB です。データ量が増えるほどストレージと CPU が必要になります。学習用であれば 1 コア・2GB でも起動可能です。

Q2. OpenTelemetry Collector は必須ですか？ A2. アプリケーションから直接 Tempo に送信することも可能ですが、Collector を挟むことで処理の柔軟性やセキュリティ向上が図れるため、本番環境では使用を推奨します。

Q3. TraceQL と PromQL の違いは何ですか？ A3. PromQL は時系列メトリクス向け、TraceQL はトレースデータ（Span）向けのクエリ言語です。構文は似ていますが、検索対象や関数が異なります。

Q4. S3 をストレージに指定する場合の注意点は何ですか？ A4. AWS の場合、データ取得（Get）コストが発生します。頻繁な検索を想定する場合は、Tempo キャッシュ機能やローカルキャッシュ層の導入を検討してください。

Q5. Grafana 11.5 で TraceQL が使えない場合はどうすればいいですか？ A5. Grafana ダッシュボードの設定でデータソースとして Tempo を追加し、「Explore」機能から TraceQL エディタを使用します。プラグインが未インストールの場合は「Grafana Install Plugins」から該当プラグインを有効化してください。

Q6. Java アプリの自動計装に失敗する場合、どうすればいいですか？ A6. JVM オプション -javaagent が正しく指定されているか確認し、ログファイルでエラーメッセージを確認します。セキュリティマネージャーやカスタムクラスローダーがある場合は除外設定が必要です。

Q7. 移行中にデータが失われるリスクはありませんか？ A7. 並行運用モード（Dual Export）を設けることで、新旧両方にデータを流すためリスクは低減されます。十分なテスト期間を設けてから切り替えることが重要です。

Q8. Tempod のアーカイブ機能とは何ですか？ A8. 一定期間経過したトレースデータを低コストストレージへ移す機能です。データ保持ポリシーを設定することで、長期保存時のコストを削減できます。

Q9. Kubernetes 環境で Helm Chart を使うメリットは？ A9. 設定のバージョン管理や一括デプロイが容易になります。また、テンプレートシステムにより環境ごとの設定差異も効率的に管理可能です。

Q10. セキュリティ対策として何か注意すべき点はありますか？ A10. OTLP/gRPC の通信は暗号化（TLS）を推奨します。また、機密情報を含む Span Attribute は Collector でマスキングする設定を行うことで、情報漏洩を防げます。

まとめ

本ガイドでは、Grafana Tempo を用いた分散トレーシングシステムの構築方法を 2026 年の最新情報を基に解説しました。以下の要点をまとめます。

• アーキテクチャの理解: Tempo は OpenTelemetry と連携し、軽量かつ高スケーラブルな分散トレーシングを実現します。
• インストール方法: [Docker Compose で学習環境を構築し、Kubernetes Helm で本番環境を展開するのが標準的なアプローチです。
• ストレージ戦略: Filesystem、S3、MinIO などのバックエンド特性を理解し、コストとパフォーマンスのバランスを取ります。
• クエリ言語: TraceQL を活用した分析により、複雑な問題も特定可能です。Grafana 11.5 の機能強化を最大限に活かします。
• 移行戦略: Jaeger や Zipkin から Tempo への移行は、Collector を経由して段階的に行うことでリスクを最小化できます。

分散トレーシングの導入は初期設定が複雑に見えますが、正しい手順とツールの理解があれば、システム全体の可視化は実現可能です。2026 年時点では OTel の標準化により、ツール間の連携もスムーズになっています。自宅学習から本番運用まで、本ガイドを参考にして最適な Observability 環境を整えてください。