Chefの「収束」を可視化せよ：PrometheusとGrafanaで構築するインフラの健康診断
こんにちは。インフラエンジニアの皆さん、日々のChefの実行結果、どうやって確認していますか？
「Chef Infra Clientがいつ終わったのかわからない」「特定のノードで収束が遅延している気がするが、証拠がない」……そんな悩みを抱えているなら、今日はそれを終わらせる日です。
Chefは「冪等性（べきとうせい）」を担保する最強のツールですが、その「収束のプロセス」自体がブラックボックス化していることは大きなリスクです。今回は、Chefの実行メトリクスをPrometheusで収集し、Grafanaで美しく可視化する「インフラの健康診断」の実装方法を解説します。
—
1. なぜ「収束の可視化」が必要なのか？
Chef Infra Clientは、定義された状態（State）へシステムを導く（Converge）ツールです。しかし、大規模な環境では以下のような事象が頻発します。
- 収束遅延（Convergence Delay）: 重いリソース定義により、処理時間が数分から数十分へ劣化。
- 断続的な失敗: 再試行で成功しているが、実は不安定なノードが存在する。
これらを「なんとなく」で放置せず、メトリクスとして定量化することで、インフラの健全性を常に把握できます。
—
2. アーキテクチャの全体像
今回は、以下のシンプルな構成で実装します。
1. Chef Handler: Chefの実行終了時に情報をキャッチするフック。
2. Prometheus Node Exporter (Textfile Collector): Chefが吐き出した情報をPrometheusに渡す橋渡し。
3. Prometheus: 時系列データの収集。
4. Grafana: 実行時間や成功/失敗率のダッシュボード化。
—
3. 実装ステップ：Chefのメトリクスを抽出する
まずは、Chefが実行を終えるたびに、その結果をテキストファイルとして出力させます。
Step 1: カスタムハンドラーの配置
Chefの実行結果をファイルに書き出すためのシンプルなRubyスクリプトを作成します。
/etc/chef/handlers/prometheus_handler.rb
require ‘chef/handler’
class PrometheusHandler < Chef::Handler def report # 実行時間、成功/失敗のフラグをメトリクス形式で定義 success = success? ? 1 : 0 duration = run_status.elapsed_time # Prometheus Textfile Collector用のパスへ書き込み File.open('/var/lib/node_exporter/chef_metrics.prom', 'w') do |f| f.puts "chef_convergence_duration_seconds #{duration}" f.puts "chef_convergence_success #{success}" end end end
Step 2: Client設定への組み込み
`client.rb` にこのハンドラーを読み込ませる設定を追加します。
/etc/chef/client.rb
require ‘/etc/chef/handlers/prometheus_handler’
実行終了時に必ずハンドラーを起動する
report_handlers << PrometheusHandler.new
---
4. Prometheusでのスクレイピング
Node Exporterがインストールされている場合、`–collector.textfile.directory` オプションを有効にするだけで、先ほど出力したファイルを自動的に読み込みます。
Prometheus設定例:
scrape_configs:
- job_name: ‘chef_nodes’
static_configs:
- targets: [‘localhost:9100’]
これだけで、Prometheus上に `chef_convergence_duration_seconds` というメトリクスが爆誕します。
—
5. Grafanaによる可視化とアラート
Grafanaで以下のパネルを作ってみましょう。
- ゲージパネル: 直近のChef実行時間。
- 時系列グラフ: 過去24時間の収束時間の推移（劣化の予兆を捉える）。
- アラート: `chef_convergence_success == 0` をトリガーに、Slackへ通知。
アラート設定のポイント
「失敗」だけでなく、「収束時間が過去の平均から大幅に乖離している（例：標準偏差の2倍以上）」というルールをPrometheusの `predict_linear` や `stddev_over_time` を使って設定すると、深刻なトラブルが起きる前に「おや、最近処理が重いな？」と気づくことができます。
—
6. 最後に：エンジニアの美学
「自動化」は、構築して終わりではありません。「自動化されたものが、正しく動いていることを観測し続けること」までがセットです。
今回紹介した手法を導入すれば、朝起きてダッシュボードを見るだけで、全ノードの「健康」が一目でわかるようになります。この安心感こそが、SREとして極限まで効率化されたインフラを運用する醍醐味です。
まずは1台のノードから、ぜひ今日試してみてください。わからないことがあれば、いつでも聞いてくださいね。あなたのインフラ運用が、もっとスマートで快適なものになることを願っています！