Part 6-2. Prometheus 連携ツール（Loki, Tempo, Thanos, Cortex）
はじめに
Prometheus とGrafana の組み合わせで、メトリクス監視の基盤は構築できます。しかし実務では、それだけで事足りるケースは実は少ないのです。スケーラビリティの限界、長期データ保持の困難、ログやトレースとの相関分析の必要性など、Prometheus 単体では解決できない課題が出てきます。
このセクションでは、Prometheus を補完する4つの主要ツール―Loki、Tempo、Thanos、Cortex―について、それぞれの役割、ユースケース、統合方法を比較しながら解説します。
Loki: ログ統合
Loki とは
Loki は Grafana Labs が開発した、ログ管理の標準ツールです。Prometheus がメトリクスの管理に特化しているのに対し、Loki はテキストログの管理と検索に特化しています。
Loki の最大の特徴は、Prometheus と同じ「ラベルベース」の検索アプローチを採用していることです。例えば、ジョブ名（job）やサービス名（service）、環境（env）などのラベルで、ログを効率的にフィルタリングできます。これにより、Prometheus で習得したラベル設計の知識がそのまま Loki で活かせます。
Prometheus との違い
| 観点 | Prometheus | Loki |
|---|---|---|
| データ型 | 数値メトリクス | テキストログ |
| クエリ言語 | PromQL | LogQL |
| インデックス方式 | メトリクス名と全ラベルをインデックス | ラベルのみをインデックス（ログ本文は未インデックス） |
| ストレージ効率 | メトリクス数が増えるとメモリ効率が低下 | ログ本文を圧縮保存するため、効率的 |
| 適応シーン | 定期的な監視、トレンド分析 | イベントベースのログ検索、トラブルシューティング |
ユースケース: メトリクスとログを相関させたい
Prometheus で「CPU 使用率が 80% に上昇した」というアラートが検出された場合、その直後のログを確認したいというシーンがあります。Prometheus のアラートから Grafana を開き、同じ時間帯の Loki ログを表示できれば、「ジョブキューが溜まっていた」「デプロイが走った直後だった」といった背景をすぐに把握できます。
Prometheus と Loki を組み合わせることで、メトリクスの「What」（何が起こったのか）だけでなく、ログの「Why」（なぜそれが起こったのか）も一箇所で確認でき、トラブルシューティングの速度が格段に向上します。
Tempo: 分散トレーシング
Tempo とは
Tempo は Grafana Labs が開発した分散トレーシングバックエンドです。マイクロサービスアーキテクチャでは、単一のユーザーリクエストが複数のサービスを跨ります。Tempo は、このリクエスト全体の経路と各ステップでの処理時間（レイテンシ）を「スパン」という単位で記録し、可視化します。
Tempo の特徴は、Prometheus や Loki と統合できる設計になっていることです。Grafana 内で、メトリクス、ログ、トレースを シームレスに切り替えて分析できます。
メトリクス × トレースの連携
例えば、Prometheus で「API のレスポンスタイムが 2 秒に上昇した」というアラートが発生した場合、Grafana から Tempo を使って「その時間帯のトレース」を検索できます。トレース内で、「データベースクエリが 1.5 秒かかっていた」「外部 API 呼び出しが 0.8 秒かかっていた」といった詳細が見え、根本原因を素早く特定できます。
ユースケース: レイテンシ問題の根本原因を見つけたい
マイクロサービス環境でレイテンシの増加が検出された場合、影響を受けているサービスが複数ある可能性があります。Prometheus メトリクスだけでは「全体のレスポンスタイムが長い」しかわかりませんが、Tempo のトレースを確認すれば、「サービスC でクエリがタイムアウトしていた」「サービスB と C 間の通信が遅い」といった具体的な問題箇所が見えてきます。
Thanos: グローバルビュー
Thanos とは
Thanos は複数の Prometheus インスタンスを統合し、グローバルなビューで監視を実現するツールです。各データセンターやクラウドリージョンに Prometheus インスタンスがある場合、Thanos はそれらを「クエリフェデレーション」という技術で統合し、全インスタンスから一度のクエリで集計結果を取得できます。
Thanos はまた、「リモートストレージ連携」により、Prometheus のデータを S3 や GCS などのオブジェクトストレージに自動的に転送でき、長期データ保持を実現します。
長期保存戦略との組み合わせ
Prometheus のデフォルトリテンション（15 日）では、トレンド分析や容量計画に必要な中長期データが保持できません。Thanos を使えば、ホットデータ（最新 1～2 日）をローカルストレージに、コールドデータ（1 ヶ月以前）をクラウドストレージに、という階層化が可能になります。この二階層構成により、高速なリアルタイムクエリと、低コストな長期保存の両立が実現されます。
ユースケース: マルチサイト環境を一元監視したい
複数のデータセンターやリージョンに Prometheus が分散配置されている場合、従来は各 Prometheus を個別に確認する必要がありました。Thanos を導入すれば、Grafana の単一ダッシュボードから、全リージョンのメトリクスを統一された PromQL で取得でき、グローバルな容量計画やボトルネック分析が可能になります。
Cortex: マルチテナント化
Cortex とは
Cortex は Grafana Labs が開発した、スケーラブルで耐障害性の高いメトリクスストレージです。Prometheus のリモートストレージ API と互換性があり、既存の Prometheus 設定をほぼ変更なく統合できます。
Cortex の最大の特徴は「マルチテナント対応」です。複数の組織やチームが同一の Cortex クラスタを共有でき、テナント間のデータは完全に分離されます。また、水平スケーラビリティがあり、クエリ負荷の増加に応じてノードを追加して対応できます。
テナント分離と共有リソース
Cortex では、各テナントに専用の ID を割り当てることで、データを厳密に分離します。API リクエストに X-Scope-OrgID ヘッダーを含めることで、テナント識別が行われます。複数チームが同一のインフラを使いながら、データの安全性と運用効率を両立できるため、大規模な SaaS プラットフォームや複数部門を持つ企業に適しています。
ユースケース: 大規模環境で複数チームを支えたい
スタートアップが成長して複数の機能チームが存在するようになると、各チームが独立した監視基盤を必要とするかもしれません。Cortex を使えば、インフラ基盤は共有しつつ、各チームのデータを完全に分離でき、スケーラビリティと柔軟性が両立できます。
ツール選択マトリックス
以下の表は、主要な4つのツールを、Prometheus との連携の視点から比較したものです。
| ツール | 主要用途 | Prometheus との連携方法 | 適する規模 | 導入難度 |
|---|---|---|---|---|
| Loki | ログ管理・検索 | 別サービス（Prometheus + Grafana 経由で表示） | 小～中 | 低 |
| Tempo | 分散トレーシング | 別サービス（メトリクスとトレースを関連付け） | 中～大 | 中 |
| Thanos | マルチ Prometheus 統合・長期保存 | リモートストレージまたはサイドカー | 中～大 | 高 |
| Cortex | スケーラブル メトリクスバックエンド | リモートストレージ置き換え | 大規模 | 高 |
各ツールの選択基準は以下の通りです。
Loki はシンプルで導入コストが低いため、ログと メトリクスの相関分析が必要になった段階で導入するのに最適です。Prometheus の導入後、チームが成長して「ログも一緒に見たい」となれば、最初の統合の候補になります。
Tempo はマイクロサービスアーキテクチャで、レイテンシの詳細分析が必要な場合に有効です。ただし、スパン情報をアプリケーションから主動的に送信する必要があるため、アプリケーション側の対応が必須です。
Thanos は複数 Prometheus インスタンスの統合と長期保存が必要な、中～大規模環境向けです。HA 対応が必要な場合や、複数リージョンでの運用を検討している場合は、Thanos の導入を強く検討すべきです。
Cortex は、大規模環境での複数チーム運用や、SaaS 型の監視提供を考えている場合に最適です。ただし導入と運用の複雑度が高いため、Thanos だけで対応可能なら、そちらを優先すべきです。
統合アーキテクチャの例
実際の導入では、複数のツールを組み合わせることが一般的です。以下に、主要な3つの統合パターンを示します。
パターン1: シンプル統合（Prometheus + Grafana + Loki）
Applications → Prometheus ←→ Grafana
↓
Loki ← Promtail (ログ収集)最もシンプルな統合です。Prometheus がメトリクスを、Loki がログを管理し、Grafana がいずれも可視化します。Promtail は各サーバーで稼働するログ収集エージェントで、ログを Loki に送信します。小～中規模環境でメトリクス+ログの統合監視を実現する場合に最適です。
パターン2: 大規模環境向け（Prometheus (+ Thanos) + Grafana + Loki + Tempo）
Regional Prometheus → Thanos (Query Frontend)
↓
Applications ←→ Tempo ←→ Grafana ←→ Loki (Promtail)複数リージョンや複数クラスタ環境での構成です。各リージョンの Prometheus は Thanos に統合され、グローバルビューが実現されます。同時に Tempo でトレース情報も収集し、Grafana から メトリクス+トレース+ログの統一された分析ができます。
パターン3: マルチテナント対応（Cortex + Grafana + Loki）
Applications → Cortex (Mutable Metrics)
↓
Grafana ←→ Loki複数チームが同一インフラを使う場合の構成です。Cortex がマルチテナント対応のメトリクスバックエンドとなり、Prometheus のリモートストレージ機能で統合されます。各テナントのデータは完全に分離され、スケーラビリティと安全性が両立されます。
統合時の注意点
各ツールを統合する際には、以下の設定項目の確認が重要です。
リモートストレージ設定: Thanos や Cortex を使う場合、Prometheus 設定ファイル（prometheus.yml）に remote_write セクションを追加し、メトリクスの転送先を指定します。エンドポイント URL、タイムアウト、クエリバッチサイズなどの調整が必要です。
API 認証: Thanos や Cortex へのアクセスに認証が必要な場合、HTTP ヘッダーに API キーやベアラートークンを設定します。特にマルチテナント環境では、テナント ID の指定も欠かせません。
データ保持ポリシー: Thanos ではコンパクション間隔、Cortex ではホットデータ保持期間などを設定し、ストレージの効率とクエリパフォーマンスのバランスを取ります。
関連記事
- 前の記事: Part 6-1. Prometheus と Grafana 連携
- 次の記事: Part 6-3. Prometheus のベストプラクティス
- 関連: Part 5-2. Prometheus のハイアベイラビリティ・リテンション戦略（Thanos の背景理解）