Prometheusを骨の髄まで掌握する：ローカル環境におけるオブザーバビリティの最適解
エンジニア諸君。計測できないものは改善できない。これは単なる格言ではなく、システムの本質だ。
多くの開発者が「Prometheusをとりあえず動かした」段階で満足するが、真のアーキテクトはそこからがスタートラインだと知っている。今回は、Docker Composeを用いて「単に動く」レベルを脱却し、実戦で即座に武器として機能する監視アーキテクチャを構築する。
—
1. 構築するアーキテクチャ：疎結合・高密度の監視網
今回構築するのは、ただのメトリクス収集基盤ではない。「サービスディスカバリーの自動化」を前提とした、拡張可能な監視アーキテクチャだ。
- Prometheus Server: TSDBのバッファとストレージを分離設計。
- Target: `docker-compose`のラベルを用いた自動検出（静的設定を排除する）。
- Exporters: ノードとコンテナのメトリクスを透過的に取得。
アーキテクチャの核心
設定ファイルを頻繁に書き換える運用は、スケーラビリティの敵だ。Dockerラベルをメタデータとして活用し、Prometheusがコンテナの生存確認と同時にメトリクス・エンドポイントを自動的に登録する「プッシュ型に近いプル型」の動的構成を実現する。
—
2. 実装：コンフィグの極致
`docker-compose.yml` と `prometheus.yml` を提示する。これらは単なる設定ではなく、インフラのコード化（IaC）の縮図である。
docker-compose.yml
version: ‘3.8’
services:
prometheus:
image: prom/prometheus:latest
container_name: prometheus
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
- prometheus_data:/prometheus
command:
# メモリ最適化のためのフラグ群
- ‘–storage.tsdb.retention.time=15d’
- ‘–storage.tsdb.path=/prometheus’
- ‘–web.console.libraries=/usr/share/prometheus/console_libraries’
- ‘–web.console.templates=/usr/share/prometheus/consoles’
ports:
- “9090:9090”
networks:
- monitoring
volumes:
prometheus_data:
networks:
monitoring:
driver: bridge
prometheus.yml
ここで重要なのは `dns_sd_configs` ではなく、Dockerのネットワークトポロジーを活かした設定だ。
global:
scrape_interval: 15s # 高密度環境では30s以上を推奨するが、ローカルは15sで解析せよ
scrape_configs:
- job_name: ‘docker-containers’
# Docker DaemonのAPIを叩く代わりに、DNSベースでコンテナ名を解決する
# 接続性を最大化するため、同一ネットワーク内の全コンテナを監視対象とする
dns_sd_configs:
- names:
- ‘tasks.my-app’ # SwarmやカスタムDNS利用時の実戦設定
type: ‘A’
port: 8080
—
3. 起動と深層へのアクセス
`docker-compose up -d` を叩けば、Prometheusが立ち上がる。しかし、真のエンジニアは起動直後に以下のコマンドを叩く。
TSDBの内部状態をAPI経由で確認する
curl -s http://localhost:9090/api/v1/status/tsdb | jq .data.headStats
ここで`headStats`を確認し、メモリ消費量とアクティブなシリーズ数を監視する。「なぜ今、このメトリクスが食われているのか？」を即座に特定できる能力こそが、アーキテクトの矜持だ。
—
4. トラブルシューティング：神の視点でのチェックポイント
接続エラーが発生した場合、マニュアルを読むのは時間の無駄だ。以下の3点を確認せよ。
1. ネットワーク分離の罠: `prometheus`コンテナと監視対象コンテナが、同一のDockerネットワークに接続されているか？（`docker inspect`で確認せよ）
2. ターゲットの生存確認: PrometheusのWeb UI (`/targets`) で `UP/DOWN` を確認。`DOWN` の場合、ターゲット側で `curl` を叩き、PrometheusのIPから到達可能かを確認せよ。
3. TSDBのロック: コンテナを強制終了させると `lock` ファイルが残る。起動しない場合は `/prometheus/lock` を削除する勇気を持て。
—
最後に：なぜ「5分」で終わらせるのか
この構築に時間をかけてはならない。監視はあくまで「システムが健常であるかを証明する手段」に過ぎない。
真の目的は、Prometheusに溜まったデータをどう解釈するかにある。PromQLの計算量を減らすためのレコーディングルール（Recording Rules）の設計、Grafanaのダッシュボードにおけるクエリの最適化……これこそが、君たちが次に目指すべき高みだ。
もしPrometheusのメモリ使用量が激増したら、それは監視の設計ミスか、アプリケーションが異常なカーディナリティを生成している証拠だ。その時、君は初めてオブザーバビリティの真髄に触れることになる。
さあ、コードを書け。計測し、理解し、システムを完全支配せよ。