Chef Infraの「収束」を可視化せよ：Prometheus × Grafanaで実現する運用自動化の真髄
Chefを単なる「設定管理ツール」として使っているなら、それは宝の持ち腐れだ。Chefの本質は、システムの「あるべき状態（Desired State）」をコードとして宣言し、それを継続的に維持するサイクルにある。
だが、現場のエンジニア諸君。「Chefの実行が遅延している」「いつの間にか収束が失敗し続けている」といった事象を、ダッシュボードで即座に把握できているか？ 実行ログを眺めて溜息をつく時代は終わりだ。今日は、Chef Infra ClientのメトリクスをPrometheusで吸い上げ、Grafanaで可視化する「攻めの運用」の極意を伝授する。
—
1. なぜChefに監視が必要なのか？
Chefの実行時間（Convergence Time）は、システムの健康状態を測る最強の先行指標だ。
- 実行時間の急増： 不要なリソース再起動や、複雑すぎるレシピによる計算コストの増大を示唆。
- 失敗率のスパイク： 新規ノードのブートストラップ設定のミス、またはChef Serverとの通信断を即座に検知。
これを監視するだけで、トラブルシューティングの時間は劇的に短縮される。
—
2. 実装の要：`chef-client-exporter` の導入
Chefの実行結果をPrometheusが解釈できる形式に変換するには、`chef-client-exporter` を利用するのが定石だ。
Prometheusへのメトリクス出力設定
各ノードで実行されるChef Clientの処理結果を、ローカルの `/var/lib/node_exporter/textfile_collector/chef.prom` に書き出す設定を行う。
/etc/chef/client.rb に追加すべきベストプラクティス
実行結果をPrometheusのTextfile Collector形式で保存するハンドラ
require ‘chef/handler/prometheus_exporter’ # カスタムハンドラを配置しておくこと
report_handlers << Chef::Handler::PrometheusExporter.new( path: '/var/lib/node_exporter/textfile_collector/chef.prom' )
Prometheusのスクレイピング設定（prometheus.yml）
scrape_configs:
- job_name: ‘chef_client’
file_sd_configs:
- files: [‘/etc/prometheus/sd_configs/chef_nodes.json’]
# Chefの実行は高頻度ではないため、スクレイプ間隔は60sで十分
scrape_interval: 60s
—
3. Grafanaでの可視化：鉄板のダッシュボード構成
Grafanaで見るべきは、以下の3つのパネルだ。
1. Convergence Duration (Heatmap): 実行時間の分布。中央値から外れたノードを瞬時に特定できる。
2. Failure Rate (Gauge/Graph): 過去1時間の失敗数をカウント。ここが閾値を超えたら即Slack通知。
3. Last Run Time (Table): 全ノードの最終実行時間を一覧表示。更新が止まっているノードは「ゾンビ化」の予兆だ。
—
4. 現場で「差が出る」プロのテクニック
【隠れた神プラグイン・設定】
- `chef-apply` との使い分け: 開発中のレシピテストには `chef-apply` を使うのが基本だが、`knife-zero` を導入せよ。Chef Serverを立てずにSSH経由でChefを実行でき、開発ループが3倍速くなる。
- `ohai` の活用: カスタムプラグインを `/etc/chef/ohai/plugins` に置くことで、監視対象に「自社独自のインフラ構成情報」を付与できる。これが監視の解像度を決定づける。
【チーム運用ルール：設定の共有化】
設定ファイル（YAML/JSON）を各ノードに直接書くのは禁止だ。
- Attributesの階層化: `default` → `role` → `environment` の順序を厳守せよ。
- `Policyfile` への完全移行: `Berkshelf` は過去の遺物だ。`Policyfile.lock.json` をコミットすることで、「どの環境で、どのバージョンのクックブックが、どのノードに適用されているか」を完全に固定し、冪等性を保証しろ。
【Slackアラート設計の極意】
単に「失敗しました」と送るな。必ず以下の情報を添えること。
- `Node Name`
- `Run List`
- `Error Message` (例外のスタックトレースの冒頭のみ)
- ダッシュボードへのDeep Link: 通知を受け取ったエンジニアが、即座に該当ノードのグラフに飛べるURLを埋め込むのが「プロの作法」だ。
—
5. 結論：Infrastructure as CodeからInfrastructure as Dataへ
Chefの実行を監視することは、単なる死活監視ではない。「システムがコードによって定義され、実行され、安定しているか」という信頼性の証明だ。
自動化の目的は「楽をすること」ではなく、「人間が介入しなくても正しい状態が担保される安心感」を設計することにある。今日から監視環境を構築し、Chefの実行結果を信じられるデータに変えてほしい。
何かあればいつでも聞け。君のインフラが、より堅牢なものになることを期待している。