こんにちは！日々、Jenkinsのパイプラインと格闘しているエンジニアの皆さん、お疲れ様です。
「またJenkinsのディスク容量が圧迫されている……」
「過去のビルドログから、あのエラーがいつから発生しているのか探すのに何時間もかかる……」
そんな絶望的な状況に直面したことはありませんか？
大規模な開発現場になればなるほど、Jenkinsのビルドログは「ただのテキスト」としてローカルのディスクに溜まり、やがて検索不能のゴミの山と化します。
今回は、この「ログ爆発」の悪夢を断ち切り、ビルドログを最高の資産に変えるアーキテクチャについてお話しします。
これをマスターすれば、毎日のトラブルシューティングが劇的に楽になりますよ。初心者の方にもすんなり理解できるよう、基礎から優しく丁寧に解説していきますね！
—
なぜJenkinsのログは「爆発」するのか？
Jenkinsはデフォルトで、すべてのビルドの標準出力（stdout/stderr）をマスターノード（またはエージェントノード）のファイルシステム上に保存します。
- 並行ビルド数が数十〜数百を超える
- テストの冗長なログや、無駄なデバッグ出力（`DEBUG`レベルのログなど）が垂れ流されている
- 古いログの削除ポリシー（ビルドの破棄設定）が甘い
これらが重なると、あっという間に数百GB、下手をすればTB単位のストレージが喰いつぶされ、I/O性能の低下によってJenkins自体が重くなります。
解決の鍵：ログの「集中外部化」と「構造化」
この問題を根本から解決するのが、「Fluentd × Elasticsearch × Kibana（通称：FEKスタック）」の組み合わせです。
1. Jenkins：ログをローカルに溜め込まず、リアルタイムで外部へストリーミング送信する。
2. Fluentd：ログの収集・転送・構造化（パース）を行う。
3. Elasticsearch：大量のログを高速にインデックス化し、保存する。
4. Kibana：ブラウザからリッチなクエリでログを検索・視覚化する。
今回は、このエコシステムへの第一歩として、JenkinsのログをFluentd経由でElasticsearchに送り、Kibanaで分析する環境の作り方をマスターしましょう。
—
Step 1: アーキテクチャ全体のイメージをつかむ
まずは、ログがどのように流れるのか、全体のロードマップを頭に描きಮす。
[ Jenkins (Build Node) ]
│
▼ (ログ出力 / Fluentdプラグイン等を利用)
[ Fluentd ] ──(パース・構造化)──> [ Elasticsearch ] ──> [ Kibana (ダッシュボード) ]
今回はシンプルに、Jenkinsが動作しているサーバー上にFluentd（Td-agent）を同居させ、ローカルのJenkinsジョブのログファイルをFluentdに監視・収集させるアプローチをとります。
—
Step 2: 基礎セットアップ（Fluentd & Elasticsearch）
まずは、ログを受け止める土台を作ります。Docker環境があれば、ElasticsearchとKibanaは数分で立ち上がります。
1. Elasticsearch & Kibanaの起動 (`docker-compose.yml`)
以下の設定ファイルを適当なディレクトリ（例: `/opt/elk`）に作成し、コンテナを起動してください。
version: ‘3.8’
services:
elasticsearch:
image: docker.elastic.co/elasticsearch/elasticsearch:7.17.9
container_name: elasticsearch
environment:
- discovery.type=single-node
- “ES_JAVA_OPTS=-Xms512m -Xmx512m”
ports:
- “9200:9200”
networks:
- logging-net
kibana:
image: docker.elastic.co/kibana/kibana:7.17.9
container_name: kibana
ports:
- “5601:5601”
environment:
- ELASTICSEARCH_HOSTS=http://elasticsearch:9200
networks:
- logging-net
networks:
logging-net:
driver: bridge
ターミナルで `docker-compose up -d` を実行すれば、準備完了です。`http://localhost:5601` にアクセスできればKibanaの起動成功です！
2. Fluentd（td-agent）のインストールと設定
次に、Jenkinsのログを拾い上げるFluentdを設定します。今回はLinux環境（Ubuntu/CentOS等）を想定して解説します。
公式の手順に従い、Fluentdのモダンなディストリビューションである `td-agent` をインストールします。
インストール後、設定ファイル `/etc/td-agent/td-agent.conf` を編集します。これが今回の心臓部です。
Jenkinsのビルドログが格納されるデフォルトのパスを監視します
# Jenkinsのジョブごとのログファイル（build.log）を追跡
path /var/lib/jenkins/jobs//builds//build.log
pos_file /var/log/td-agent/jenkins_builds.pos
tag jenkins.build
読み込んだログにメタデータを付与し、Elasticsearchへ転送する
@type elasticsearch
host localhost
port 9200
index_name jenkins-logs
type_name _doc
# 負荷軽減のためのバッファ設定
@type memory
flush_interval 5s
> 先輩からのワンポイントアドバイス:
> `path` のワイルドカード（“）を使うことで、新しく作成されたジョブのログも自動的に追跡対象になります。ポジションファイル（`pos_file`）を設定しておけば、Fluentdが再起動してもログの読み込み位置を覚えていてくれるので安心です。
設定を変更したら、Fluentdを再起動します。
sudo systemctl restart td-agent
—
Step 3: 精度高い「Hello World」！動作確認のパイプライン
環境が整ったら、実際にJenkinsでジョブを動かして、ログがElasticsearchまで綺麗に流れるかテストしてみましょう。これが今回の「HelloWorld」です。
1. テスト用Jenkinsジョブの作成
Jenkinsの管理画面から、新規に「フリースタイル・プロジェクト」または「パイプライン」を作成します（今回はフリースタイルでOKです）。
ビルド手順（シェルスクリプトの実行）に、以下のような意図的に情報を散りばめたスクリプトを書き込みます。
!/bin/bash
echo “=== BUILD STARTED at $(date) ===”
echo “[INFO] Compiling source code…”
echo “[WARNING] Deprecated API usage detected in Module A.”
わざとエラーログを出力させる
echo “[ERROR] NullPointerException occurred at com.example.App.main(App.java:42)”
echo “=== BUILD FAILED ===”
exit 1
このジョブを「ビルドを実行」してみましょう。失敗して終了するはずです。
2. Kibanaでログを検索してみる
ログがElasticsearchに到達しているか、Kibanaを使って確認します。
1. ブラウザで `http://localhost:5601` を開く。
2. 左側メニューの 「Management」 > 「Stack Management」 > 「Kibana」 > 「Index Patterns」 に移動。
3. 「Create index pattern」をクリックし、Index patternに `jenkins-logs` と入力して次へ進む。
4. Time fieldとして `@timestamp` を選択して作成を完了する。
5. 左側メニューの 「Analytics」 > 「Discover」 を開き、インデックスに `jenkins-logs` を選択。
おめでとうございます！そこに、先ほどJenkinsのジョブが出力した `[ERROR] NullPointerException…` のログが、タイムスタンプ付きでリアルタイムに表示されているはずです。
—
Step 4: クエリを使った高度な分析・品質向上への活用
単にログを集めるだけではもったいない！ここからがDevOpsエンジニアの腕の見せ所です。KibanaのKQL（Kibana Query Language）を使って、パイプラインの品質を向上させる実践的なクエリテククニックを紹介します。
1. 特定のエラー頻度を可視化する
例えば、「今週、`NullPointerException` が何回発生したか」を瞬時に特定したい場合、KibanaのDiscoverの検索窓に以下のように入力します。
message : “NullPointerException”
さらに、Kibanaの「Lens」機能を使ってこれを棒グラフ（Y軸：カウント、X軸：時間ごとのヒストグラム）に変換すれば、「どの時間帯にテストが不安定になっているか（インフラの負荷が原因か？）」の傾向が一目でわかります。
2. ビルド時間の傾向を分析する
もしFluentdでログをパースする際に、ジョブ名やビルド時間をJSON形式等で構造化して送るように拡張すれば、以下のような高度な分析も可能です。
- 「過去1ヶ月で、最もビルド時間が長いジョブトップ5は何か？」
- 「特定のPRマージ後に、テスト実行時間が何秒長くなったか？」
これらをダッシュボードにまとめてチームメンバー全員が見られるようにしておくと、誰もがパイプラインの非効率さに気づけるようになり、自律的な改善スピードが劇的に上がります。
—
まとめ
今回は、大規模Jenkins環境における「ログ爆発」を抑制するための、FluentdとElasticsearchを活用したログ外部化アーキテクチャを解説しました。
- ローカルディスクの圧迫を防ぐため、ログはリアルタイムで外部へストリーミングする。
- Fluentdの `tail` プラグインと `elasticsearch` プラグインで堅牢なパイプラインを作る。
- Kibanaを使ってエラーやビルドの傾向を可視化し、開発プロセスの品質改善につなげる。
これを導入するだけで、あなたのチームは「ディスク容量の残量に怯える日々」から解放され、より本質的なコード品質の改善に集中できるようになります。
「これをマスターすれば、毎日の作業が劇的に楽になりますよ」。ぜひ、あなたの現場のJenkins環境でも試してみてくださいね！