fluentdの効果的な活用例と安定運用のポイント：今さら聞けないfluentd〜クラウド時代のログ管理入門（3）（2/3 ページ）

効率良く、意味のあるログ管理を実現するツールとして注目されている「fluentd」。最終回では、実際の利用シーンを想定し、より効果的なfluentdの利用法を紹介します。

[池田大輔（TIS株式会社），＠IT]

2. タグデータを効果的に活用し、ログデータのフィルタリング管理を行う

　次に、ログの出力内容に応じて適切に処理を振り分けて管理する例について紹介します。大量のログを適切にフィルタリングして管理することで、効率良い管理に近付きます。

　ここでは具体例として、Rubyのアプリケーションログのログレベルに応じて処理を振り分けるケースを考えます。活用するプラグインは以下の3つです。

• in_tail（第2回で紹介した組み込みプラグイン）
• out_rewrite_tag_filter（タグを書き換えるプラグイン）
• out_copy（第2回で紹介した組み込みプラグイン）

　Rubyのアプリケーションログとして、以下のような形式でログが出力されることを想定します。

E, [2014-01-08T14:45:35.517217 #13032] ERROR -- : This is error log
W, [2014-01-08T14:45:35.523190 #13032]  WARN -- : This is warning log
I, [2014-01-08T14:45:35.527218 #13032]  INFO -- : This is information log
F, [2014-01-08T14:45:37.786036 #13032] FATAL -- : This is fatal log

　このログのレベルの部分（「ERROR」や「WARN」など）を、in_tailのformatで抽出できるよう設定を行い、「app.log」というタグを付けて取り込みます。この「app.log」にマッチした処理についてはout_copyプラグインにより、共通のアウトプット処理実行と、タグを書き換えて再取り込みする処理に分離します。

　ログの書き換えはapp.logの末尾にin_tailで抽出したログのレベルを追加で付与しています。さらに、書き換え後のタグ（app.log.ERROR）にマッチした場合の処理を追加で実行できるよう定義しています。

・設定例

<source>
  type tail
  format /^[^ ]*\s*\[.*\]\s*(?<level>[^ ]*).*:\s*(?<message>.*)$/
  path /var/log/ruby_app.log
  tag app.log
</source>
## 全ログ共通の出力処理＆タグの書き換え処理設定 ##
<match app.log>
  type copy
  <store>
    type rewrite_tag_filter
    rewriterule1 level ^(.*)$ ${tag}.$1  # 「level」の値の内正規表現「^(.*)$」にマッチしたもののタグを「オリジナルのタグ(${tag}).マッチした文字列($1)」で置き換える設定
  </store>
  <store>
    ファイルへの書き込みなど全ログ共通のアウトプット処理設定
  </store>
</match>
## ERRORレベルのログだけ追加で別処理 ##
<match app.log.ERROR>
    監視ツールへの連携などエラーログのみに対するアウトプット処理設定
</match>

　このように、フィルタリングをした上で処理を記述することが可能であるため、「いったんログデータを全て保存しておき、特定のログが発生した場合にのみ別の出力先で管理する」といったことも容易に実施できます。

---

　ここまで、具体的な例を2つ紹介しました。このようにfluentdを活用すれば、多くの情報を含んで出力されてくるログのデータにプログラミング処理を加え、柔軟に活用可能な形で管理できます。