Prometheusの限界を超えろ：Thanosによる「無限」のオブザーバビリティ設計と実戦的最適化
Prometheusは最高だ。しかし、君がその真の力を引き出そうとする時、必ず「ディスクの壁」と「単一障害点の呪縛」にぶつかるはずだ。
「Prometheusのストレージを増やすか？」「それとも古いデータを捨てるか？」──そんな二元論で悩む時代は終わった。今日は、Thanosを用いてPrometheusを「ステートレスなクエリエンジン」へと進化させ、データ寿命を数ヶ月、数年へと引き延ばすためのアーキテクチャの真髄を伝授する。
—
1. Thanosアーキテクチャ：分散の「美学」を理解する
Thanosは単なる長期保存ツールではない。「クエリの連合」と「データの永続化」を分離する革命だ。
- Sidecar: Prometheusの隣で呼吸する。データをS3/GCSへリアルタイムにアップロードし、Prometheusを「長期保存の責任」から解放する。
- Store Gateway: オブジェクトストレージへの「窓口」。必要なデータだけをインデックス検索し、クエリを高速化する。
- Compactor: データの塊（Block）をマージ・ダウンサンプリングする「掃除屋」。これがないとクエリはゴミ屋敷になる。
2. 【実践】オブジェクトストレージ連携のベストプラクティス
実装で最も重要なのは「いかにしてSidecarに負担をかけず、かつセキュアにデータを流し込むか」だ。
Prometheusの定義ファイル（Sidecar設定）
Sidecarは`thanos sidecar`コマンドで起動する。`–tsdb.path`はPrometheusのデータディレクトリと一致させること。
sidecarの起動引数例
- name: thanos-sidecar
image: quay.io/thanos/thanos:v0.32.0
args:
- “sidecar”
- “–tsdb.path=/prometheus/data” # Prometheusのデータディレクトリ
- “–prometheus.url=http://localhost:9090”
- “–objstore.config-file=/etc/secret/bucket_config.yaml” # S3/GCS接続情報
bucket_config.yaml (S3の例)
権限管理はIAM Roleを使うのが定石だ。直書きは絶対に避けろ。
type: S3
config:
bucket: “my-production-metrics-bucket”
endpoint: “s3.amazonaws.com”
# 必要に応じてregionを指定
# 認証はAWS_ACCESS_KEY_ID等の環境変数から読み取らせるのが最も安全
—
3. 現場で震えるほど役立つ「プロの運用テクニック」
① クエリ高速化のための「ダウンサンプリング」
Compactorを動かす際、`–downsampling.resolution`を適切に設定せよ。これがないと、1年分のデータをクエリした瞬間にUIがクラッシュする。
- 5m: 直近の精度重視
- 1h: 長期トレンド分析用
- 1d: 経営層向けの月次レポート用
② チーム開発で役立つ「クエリの共有化ルール」
PromQLのクエリが属人化してはならない。Grafanaの変数設定や、`recording rules`をコード管理（GitOps）せよ。
- 鉄則: `alerting.rules`と`recording.rules`は同一のリポジトリで管理し、`promtool check rules`をCIのパイプラインに必ず組み込むこと。
③ 開発スピードを上げる「神ショートカットとプラグイン」
- PromQL Lens (Chrome Extension): ブラウザ上でクエリの構文チェックができる。これを入れるだけでタイポによる修正時間がゼロになる。
- Grafanaの `Ctrl + Enter`: ダッシュボード編集時に即座に保存・リロード。これを知らないエンジニアは1日10回マウスを触っている計算になる。
—
4. 設定ファイルのベストプラクティス（YAML構成の神髄）
最後に、大規模環境でトラブルを未然に防ぐためのPrometheus設定の要諦を公開する。
prometheus.yaml
global:
scrape_interval: 15s # 運用負荷と解像度のバランス点
external_labels:
cluster: “prod-tokyo-01” # Thanosでデータを識別するための必須ラベル
remote_write:
# Thanosへ直接書き込むことは推奨しない。Sidecar連携が最も安定する。
# ネットワーク分断時のバッファを意識し、Queueの調整を怠るな。
queue_config:
max_samples_per_send: 10000
capacity: 20000
隠れたTips:
大規模環境では、scrape_intervalをデフォルト15sから30sに変えるだけで
CPU負荷が3割減る。解像度とのトレードオフをビジネスレベルで合意せよ。
5. 最後に：オブザーバビリティの本質へ
Thanosを導入しただけでは、システムは「監視」された状態に過ぎない。君たちが目指すべきは、「なぜそのアラートが鳴ったのか」をコンテキスト（ログ、トレース、メトリクス）のクロス検索で即座に特定できる状態だ。
Thanosが生成する長期保存データは、その「コンテキストの宝庫」である。過去の障害の波形を分析し、未来の障害を予知する。それが、我々アーキテクトが目指すべき地平だ。
さあ、今すぐ設定ファイルを開け。君たちのPrometheusを、「ただの監視ツール」から「システムの真実を語る記録装置」へと変貌させる時だ。
—
何か詰まったら、遠慮なく質問してくれ。現場の泥臭いトラブルシューティングこそ、俺の得意分野だ。