Prometheusのリソース消費が「悪夢」になるとき
システムのピーク時にPrometheusがOOM（Out of Memory）でダウンし、眠れない夜を過ごしたことがあるなら、その無力感はよくわかるはずです。Prometheusはモニタリングのゴールデンスタンダードですが、規模が拡大するにつれて、致命的な制限が露呈し始めます。
以前のプロジェクトで、200個のマイクロサービスを監視するクラスタを管理していました。アクティブなタイムシリーズ（time series）が100万件を超えるまでは順調でしたが、そこからGrafanaのレスポンスが遅くなり、ダッシュボードの読み込みに15秒以上かかるようになりました。最終的には、膨大なデータインデックスによるRAM負荷に耐えきれず、Prometheusが頻繁にOOM killされる事態に陥りました。
ストレージ（リテンション）の問題も同様に厄介です。1年分のデータを保存するには数テラバイトのハードディスクが必要になり、複雑なデータ構造ゆえにPrometheusのバックアップは一種のギャンブルのようでした。一度ディスク障害で3ヶ月分のデータを失ったことがありますが、それは本当に痛い教訓となりました。
なぜPrometheusはこれほどリソースを消費するのか？
最適化のためには、Prometheus TSDBের根本的な問題を理解する必要があります：
- 高カーディナリティ（High Cardinality）: これは「静かなる殺し屋」です。
user_idのように値が頻繁に変わるラベルを付与すると、タイムシリーズの数が爆発的に増加します。Prometheusはクエリ速度を確保するために、これらすべてのシリーズのインデックスをRAM上に保持せざるを得ません。 - データ書き込み構造: 古いデータブロックのマージと圧縮には、大量のCPUとI/Oを消費します。数千のターゲットがあるシステムでは、ディスクI/Oは常に「レッドゾーン」の状態になります。
- 水平スケーリングの難しさ: オリジナルのPrometheusは単一実行（スタンドアロン）向けに設計されています。より多くのデータを処理するには、サーバーをアップグレードする（垂直スケーリング）しかありません。128GBのRAMを搭載したサーバーのコストは決して安くありません。
VictoriaMetrics：完璧な代替案
ThanosやCortexを試したものの、複雑すぎて断念した後、私は**VictoriaMetrics (VM)**に切り替えました。その結果は期待を大きく上回るものでした：
- 圧倒的なデータ圧縮率: VMはディスク容量を約7〜10倍節約します。Prometheusで1TBあったデータクラスタが、VMに移行すると通常100GB程度に収まります。
- インテリジェントなRAM管理: すべてをRAMに詰め込むのではなく、効率的なキャッシュメカニズムを使用します。同じワークロードでも、RAM消費量はPrometheusの約5分の1で済むことが多いです。
- 超高速なデプロイ: システム全体が単一のバイナリファイルにまとめられています。大量の補助コンポーネントをインストールする必要はありません。
- 後方互換性: VMはPromQLとMetricsQLをサポートしています。GrafanaのURLを変更するだけで、ダッシュボードを修正することなく即座に動作します。
VictoriaMetrics（シングルノード）のインストール手順
以下は、Docker Composeを使用したシングルノード版のデプロイ方法です。この構成でも、毎秒数百万個のメトリクスを生成するシステムを十分に処理できます。
ステップ1：Docker Composeの設定
以下の最適化された設定で docker-compose.yml ファイルを作成します：
version: '3.8'
services:
victoriametrics:
container_name: victoriametrics
image: victoriametrics/victoria-metrics:v1.94.0
ports:
- "8428:8428"
volumes:
- vmdata:/storage
command:
- "--storageDataPath=/storage"
- "--retentionPeriod=12" # 12ヶ月間保存
restart: always
vmagent:
container_name: vmagent
image: victoriametrics/vmagent:v1.94.0
depends_on:
- victoriametrics
ports:
- "8429:8429"
volumes:
- vmagentdata:/vmagentdata
- ./prometheus.yml:/etc/prometheus/prometheus.yml
command:
- "--promscrape.config=/etc/prometheus/prometheus.yml"
- "--remoteWrite.url=http://victoriametrics:8428/api/v1/write"
restart: always
volumes:
vmdata:
vmagentdata:ステップ2：スクレイパー（Scraper）の設定
VMを使用する場合でも、ターゲットの定義には標準のPrometheus設定ファイルを使用します。prometheus.yml ファイルを作成します：
global:
scrape_interval: 15s
scrape_configs:
- job_name: 'vmagent'
static_configs:
- targets: ['localhost:8429']
- job_name: 'node-exporter'
static_configs:
- targets: ['192.168.1.10:9100']ステップ3：システムの起動
以下のコマンドを実行して、スタック全体を起動します：
docker-compose up -dこれにより、vmagent がデータを収集し、remote writeプロトコルを介して victoriametrics に送信します。スクレイピングの負荷は完全に分離されました。
Grafanaとの接続と最適化
移行は非常に簡単です。Grafanaで、データソースの種類として**Prometheus**を選択し、URLに http://<your-ip>:8428 を入力して「Save」を押すだけです。グラフの読み込み速度、特に長期間のクエリ（Range query）において、明らかに高速化されたことを実感できるでしょう。
現場からのアドバイス：いつ移行すべきか？
システムが順調に稼働しているなら、急いで作り直す必要はありません。Prometheusは、小規模なクラスタや30日未満の短期保存には依然として優れた選択肢です。
しかし、以下のような状況に陥っている場合は、VictoriaMetricsへの移行を検討してください：
- サーバーが常にRAM不足の警告を出している、またはOOM killが発生している。
- メトリクスの増大により、クラウドストレージ（EBS/S3）のコストが高騰している。
- コンプライアンスや監査レポートのために、数年分のデータを保存する必要がある。
ヒント： 両方を並行して運用することも可能です。アラート通知（Alerting）にはPrometheusを使い、長期保存用のストレージとしてVMにデータを転送するというハイブリッドなアプローチにより、両者の強みを活かすことができます。
結論として、VictoriaMetricsはモニタリングの課題に直面しているすべてのDevOpsエンジニアにとって、投資価値のあるアップグレードです。システムの最適化が成功することを願っています！
