Webサーバのログ管理を改善したくてFluentdを勉強！収集・加工・転送の流れを理解してみた
Webアプリケーションやシステムの開発をしていると、エラーが発生したり、アクセスが急増したりする瞬間が必ずありますよね。そんなときに頼りになるのがログです。でも、複数のサーバやサービスがあると、それぞれのログを確認するのは面倒。もっと効率よく集めて、1つの場所で見たい！と思ったことはありませんか？
私もそんな悩みを抱え、いろいろ調べていく中でFluentdというログ収集ツールに出会いました。シンプルにログを集めるだけでなく、大量のデータにも対応でき、加工や転送も柔軟にできるという魅力に惹かれ、実際に試してみることに。
この記事では、Fluentdの基本から、実際に使ってみた感想、学んだことをまとめてみました。同じようにログ収集に悩んでいる方や、Fluentdに興味を持っている方と一緒に理解を深められたら嬉しいです。
Fluentdとは？簡単におさらい
Fluentdってどんなツール？
Fluentdは、ログやデータを収集・加工・転送するためのオープンソースツールです。公式サイトでは「すべてのログを統一的に扱う」と紹介されていて、データパイプラインのハブとして活躍します。
Fluentdができること
| 機能 | 説明 |
|---|---|
| 収集（Input） | さまざまなデータソースからログを集める。 |
| 加工（Filter） | データのフォーマット変換やフィルタリング。 |
| 転送（Output） | ElasticsearchやS3などにデータを送る。 |
これらの機能が、プラグインを通して拡張できるのがFluentdの強みです。
シンプルなFluentdの設定から始めてみた
まずは基本的な使い方として、NginxのアクセスログをElasticsearchに転送して、Kibanaで可視化する流れを試してみました。
ステップ1：Nginxでログを出力
Nginxがアクセスログを出力する設定は、こんな感じです。
access_log /var/log/nginx/access.log;
これでWebサーバへのアクセスが記録されます。
ステップ2：Fluentdの設定ファイルを作る
次に、FluentdでNginxのログを収集する設定です。/etc/td-agent/td-agent.confに以下を追加しました。
<source>
@type tail
path /var/log/nginx/access.log
pos_file /var/log/td-agent/nginx-access.pos
tag nginx.access
format nginx
</source>
<match nginx.access>
@type elasticsearch
host elasticsearch.example.com
port 9200
index_name fluentd-nginx
</match>
ポイント解説
-
@type tail：ファイルの末尾を監視し、ログが追記されるたびに収集するプラグイン。 -
path：監視するログファイルのパス。 -
pos_file：読み取った位置を記録するファイル。 -
tag：ログの種類を識別するタグ。 -
@type elasticsearch：Elasticsearchにログを転送するプラグイン。
ステップ3：ElasticsearchとKibanaでログを確認
Fluentdがログを収集してElasticsearchに送ったら、Kibanaでそのデータを確認。グラフやダッシュボードで可視化すると、ログの流れが一目瞭然です！
大規模なログ収集：Hub-Worker構成を試してみた
シンプルなログ収集に慣れたら、次は複数サーバのログを集める大規模な構成にチャレンジしました。
Hub-Worker構成とは？
| コンポーネント | 役割 |
|---|---|
| Hub（集約ノード） | 複数のサーバからログを集約する。 |
| Worker（処理ノード） | Hubからのログを加工・転送する。 |
Hubの設定例
Hubは各サーバからログを受け取ります。
<source>
@type forward
port 24224
</source>
Workerの設定例
WorkerはHubからのデータをElasticsearchに送ります。
<match **>
@type elasticsearch
host elasticsearch.example.com
port 9200
</match>
この構成にすると、Webサーバが増えても柔軟に対応でき、負荷分散が可能になります。
学んだポイント：パフォーマンスを維持する工夫
バッファリングで安定性を向上
転送先がダウンしてもデータを失わないよう、バッファを設定しました。
<buffer>
@type file
path /var/log/td-agent/buffer
flush_interval 5s
</buffer>
並列処理で速度アップ
処理を並列化してパフォーマンスを向上させます。
workers 4
リソース管理
- CPUやメモリの監視：Fluentdの負荷が高すぎないかチェック。
- ログの圧縮：転送データを圧縮してネットワーク帯域を節約。
まとめ：Fluentdは柔軟で学びがいのあるツール
Fluentdを使ってみて感じたのは、シンプルな使い方から大規模な構成まで対応できる柔軟性です。設定ファイルを少しずつカスタマイズしていくことで、自分のシステムに最適なログ収集パイプラインが作れるのが面白いと感じました。
もちろん、パフォーマンスの最適化やトラブルシューティングなど、まだまだ学ぶことはたくさんあります。でも、試行錯誤しながら理解していく過程そのものが楽しいですね。
これからもFluentdの知識を深め、さらに効率の良いログ管理を目指していきたいと思います。一緒に学びを深めていきましょう！
Discussion