なぜJenkinsを「放置」してはいけないのか？
ある時、私のチームは困った状況に陥りました。CI/CDパイプラインが突然遅くなったのです。通常10分で終わるビルドが、なんと45分もかかるようになりました。チーム全員で各ノードのログを調べ、コミットを一つずつチェックしましたが、異常は見当たりませんでした。その時、モニタリングのないJenkinsは、謎に満ちた「ブラックボックス」と同じであることに気づきました。
数十台のスレーブノードと数百のジョブが並行して走るほどシステムが肥大化すると、手動でのチェックは不可能になります。PrometheusとJenkins Prometheus Exporterの組み合わせは、まさに救世主となります。この最強コンビは、以下のような見えにくい部分を可視化してくれます：
- キューに溜まっているジョブの量（Queue time）はどれくらいか？
- どのノードがRAMを使い果たしてビルドが停止しているか？
- 過去24時間で異常に失敗率が高いプロジェクトはどれか？
早期に監視体制を整えることで、上司から指摘される前に先手を打って対処できます。特に、システムがボトルネックに陥った際に「泥縄式」の対応になるのを防ぐことができます。
Jenkins Prometheus Exporterのインストール
別途エージェントをインストールする代わりに、**Prometheus metrics**プラグインを使用します。このプラグインは非常に軽量で、Jenkinsの内部データをPrometheusが理解できる形式に自動的に変換してくれます。
ステップ1：プラグインのインストール
まず、**Manage Jenkins** > **Plugins**にアクセスします。**Available plugins**タブで「Prometheus metrics」と検索してください。インストール後は、プラグインが必要なクラスをすべて初期化できるように、Jenkinsを再起動することをお勧めします。
ステップ2：メトリクスエンドポイントの確認
インストールに成功すると、Jenkinsは http://<your-jenkins-url>:8080/prometheus/ でデータポートを開放します。このリンクにアクセスしてみてください。画面に jenkins_builds_duration_milliseconds_summary のようなテキストが大量に表示されれば、正しく設定されています。
セキュリティのヒント： もし403 Forbiddenエラーが発生した場合は、**Manage Jenkins** > **System**を確認してください。Prometheusの設定セクションで「**Path authentication disabled**」にチェックを入れることができます。ただし、本番環境（Production）では、Prometheusがデータを取得する際の認証にAPIトークンを使用するのがベストです。
Prometheusのデータ収集設定
次に、2つのシステムを接続します。prometheus.yml ファイルを開き、scrape_configs セクションに以下の設定を追加します。
scrape_configs:
- job_name: 'jenkins-ci'
metrics_path: '/prometheus/'
scrape_interval: 15s # 15秒ごとにデータを収集
static_configs:
- targets: ['192.168.1.50:8080']
basic_auth:
username: 'monitor-user'
password: 'your-api-token-here'サービスを再起動せずに設定を反映させるには、以下のコマンドを実行します：
curl -X POST http://localhost:9090/-/reload注意点として、Jenkins内にPrometheus専用の閲覧権限（View）のみを持つユーザーを作成してください。スクレイピング（データ収集）に管理者アカウントを使用することは、多くの人が陥りやすい重大なセキュリティホールになります。
ダッシュボードに表示すべき3つの「ゴールデン」メトリクス
データが届き始めても、グラフを大量に作りすぎてはいけません。以下の3つの主要な指標に集中しましょう：
1. ビルドエージェントの健全性
jenkins_node_online_status メトリクスを使用します。値が1なら安定、0なら接続断です。サーバーが「生存」していてもJenkinsのサービス自体が停止している状態を防ぐため、Systemdの監視も重要です。
2. キューの長さ (Queue Size)
jenkins_queue_size_value メトリクスを使用します。この数値が15分間連続して5を超えている場合、チームのExecutor（実行リソース）が深刻に不足しています。これはCPUのアップグレードやスレーブノードの追加を検討すべきタイミングです。
3. ビルド成功率
jenkins_builds_last_build_result_ordinal メトリクスは、コードの健全性を追跡するのに役立ちます。失敗率が継続的に高いプロジェクトは、ビルド環境が不安定か、ユニットテストが不十分である場合が多いです。
Grafanaを接続して可視化する
ゼロからデザインする代わりに、既存のダッシュボードを活用しましょう。Jenkinsだけでなく、LinuxサーバーをGrafanaで可視化する手法と組み合わせることで、インフラ全体の状況がより鮮明になります。GrafanaのImport機能でID **9964** を使用してください。このダッシュボードは、平均ビルド時間から現在のExecutorの状態まで、わずか数秒の設定ですべて提供してくれます。
「アラート疲れ」(Alert Fatigue) に対処するための経験則
始めたばかりの頃、ネットワークの瞬断でPrometheusが一時的に接続を失うたびに、一晩で100通ものTelegramメッセージを受け取ったことがありました。これは典型的な失敗です。こうした本番環境のアラートノイズを削減する仕組みを整えることは、運用者の精神衛生上欠かせません。
情報の「希薄化」を防ぎ、本番環境における精密アラートを構築するために、以下の対策を推奨します：
avg_over_time関数を使用して、一時的なデータスパイクを除外する.- 問題が一定期間継続した場合にのみアラートを飛ばす（例：キューが10分間連続で10を超えた場合など）。
- 通知の階層化：軽微なエラーはSlack、システム全停止のような重大なエラーは電話やSMSで通知する。
Jenkinsの監視は単にツールをインストールすることではなく、システムがどのように動作しているかを理解することです。将来的にアラート数が増えた場合は、Alertmanagerを集約して管理するツールの導入も検討してみてください。PromQLのクエリ作成で困ったことがあれば、下のコメント欄で教えてください。サポートします！
