最近、イベントコレクター(イベントログ収集ツール)のFluentdが話題になっているようです。
今回実案件でFluentdとMongoDBを使ってみたところ、ログの集約化・データマイニングなどに思いのほか使えそうなのでメモ。FluetdのインストールからMongoDBに保存してMongoDBからデータを引っ張ってくるところまで。
Fluentdのインストール
Ruby1.9.2以降がインストールされている場合、RubyGemsを使ってインストール可能。RubyGems自体はRuby1.9以降であれば標準で入っているはず。サーバ構成は以下のようになっています。CentOS5.5です。
Webサーバがフロント側に数台、裏側のDBサーバにPostgreSQLとMongoDB(セッションストレージ)という構成で既に構築済みの状態。Webサーバにはアプリケーションが吐くログやバッチ処理のログが日々出力されていきます。 新規のスモールスタートな案件のためPostgreSQL、MongoDBの冗長化はなし。 ただその分、若干リスクもある新技術(Fluentd)を導入し易い環境だったためターゲットになりました。
Webサーバ
gem install fluent
gem list
*** LOCAL GEMS ***
bigdecimal (1.1.0)
cool.io (1.0.0)
fluent (0.9.21)
http_parser.rb (0.5.3)
io-console (0.3)
iobuffer (1.0.0)
json (1.5.4)
minitest (2.5.1)
msgpack (0.4.6)
rake (0.9.2.2)
rdoc (3.9.4)
yajl-ruby (1.0.0)
Fluentd・Mongo DBサーバ
gem install fluent
gem install fluent-plugin-mongo
gem list
bigdecimal (1.1.0)
bson (1.3.1)
cool.io (1.0.0)
fluent (0.9.21)
fluent-plugin-mongo (0.4.0)
fluentd (0.10.3)
http_parser.rb (0.5.3)
io-console (0.3)
iobuffer (1.0.0)
json (1.5.4)
minitest (2.5.1)
mongo (1.3.1)
msgpack (0.4.6)
rake (0.9.2.2)
rdoc (3.9.4)
yajl-ruby (1.0.0)
設定ファイルの雛形を作成
fluentd –setup /etc/fluent
MongoDBとfluent-plugin-mongoのインストール
今回はセッションストレージとして既にMongoDBがインストール済み。インストールする場合は以下のような手順。
yum install mongodb
service mongod restart
chkconfig mongod on
chkconfig –list mongod
Fluentdによるログ収集の開始
ところでFluentd経由でMongoDBに保存ではなくログに出力した場合、JSON形式なようでJSONじゃない微妙なフォーマットなのはなんで?
Apacheのログの場合頭に日付がついてその後に{“hoge” : “fuga”}
のようなフォーマットになっていますが、どうせなら{“date” : “2011:10:29 10:11:15”, “hoge”: “fuga”}
のようになって欲しいななんて思ったり。
設定がおかしいのかな。
ログ解析用にプログラム組んだりRのRjson使ったりしてパースしたい場合に、JSONパーサで上手いことパースするのがちょっと手間かもしれぬ…
Fluentd経由でログに出力するならMongoDBに保存する方が後々楽なんじゃないかと。
ログローテーション的なところ
今回はアプリケーションログを対象にしているため、Apacheのアクセスログなどに比べると保存するデータは少ないですが、それでも全てのログを保存し続けるわけにはいきません。 ファイルとして出力されるログの場合あればログローテーションをかけてn日より古いログを破棄するように、バッチ処理で1日1回古いデータの破棄を行っています。
まとめ
インフラエンジニアに限らずアプリケーションエンジニアにとってもログは開発段階・トラブル発生時などに日常的に目にするものだと思います。 ・Apacheが吐くログ(アクセスログ、エラーログ) ・RailsなどのWebアプリケーションフレームワークが標準で出力するログ ・運用・トラブル発生時に参照するために意図的に出力しているログ ・バッチ処理のログ ・ECサイトであれば外部の決済サービスとの通信ログ などはよく見られます。 でもそこからログを有効活用しているかと言われると正直微妙…という会社は多いんじゃないかなあと。
最近だとDevOpsなんていう概念(言葉)が使われているように運用(Ops)のし易さを考慮した開発(Dev)も求められていたりしますよね。
今までログの集計は都度UNIX・Linuxのコマンド(grep、sed)やawkなどを使って解析することが多かったのですが、ログサイズが巨大になると難しく、ログはローテーションが掛かっているため過去のデータの解析などには問題が発生することもありました。
Fluentdはアプリケーション側の改修が不要ですし、MongoDBもスキーマレスという特徴もあって構築のコストがあまりかからないのでログ収集サーバ立てる敷居が下がりそう…
収集対象のサーバが増えてきた場合にFluentdサーバを冗長化していないとログ収集がストップしてしまう点は今後検証していきたいところ。
データ量にもよりますが、RのMongoDBプラグインを使ってMongoDBサーバに接続→高度な解析なんかにも使えるかなと思っています。
おしまい。