#fluentd fluentd＋fluent-plugin-datacounterでログの可視化が便利すぎてもう死ぬしか無い
みんな大好きfluentdネタです。というか、fluentd＋fluent-plugin-datacounterが最強過ぎる。
便利すぎて生きているのが辛いどころか死ぬしか無いくらい。
※そもそもfluentdって何？って人は前のエントリとか読んでみて下さい。
まだ障害発生時の動きとか自分の環境での性能測定とか検証やっていなくてエンジニア的にあれですが。
でも、性能測定とかはhttp://d.hatena.ne.jp/tagomoris/を見ることで充分かなと、えへへ。
今までログの解析は日次で収集していた物をバッチ処理してMySQLにぶち込み、
それをゴニョゴニョして見ていたけど、これがストリーミングで可視化まで一気に出来る。
今の所着手したのはこんな感じ。
Apacheログ関連
とりあえず、ステータスコードとレスポンスタイムをCactiで可視化した。こんな感じ。
※datacounterの使用例で出ていたid:tagomorisさんのグラフまんまですけどね。
※なぜか整数値のcountでグラフ作っているのに、Cactiには小数点入りでデータが入っている謎現象も発生している。
僕のCacti力の低さですね。
で、これをやるにはなんですが、
Apacheログを読み込んで送る側のfluentd用configはとりあえずこんなの使っている。
aggregateするfluentd側で以下のconfigでやってます。
ステータスコードもレスポンスタイムも正規表現でグループ化して楽に集計ログとして吐き出せるし、
datacounterは集計する期間を秒単位で設定できるので、うちの場合Cactiは5分間隔で動かしているから
それに合わせた設定しておくことで別途Cacti側で計算集計スクリプトとか動かす必要無い。
簡単な整形スクリプトぐらいがあれば、じゃんじゃんグラフ化出来る。
前のエントリにも書いたけど、こんなのとか。
（タグとファイル指定したら最新の集計ログだけ読んでCacti用のフォーマットに直して出力します。）
https://github.com/oranie/fluentd-tools/blob/master/fluentd-tools/datacounter_cacti_graph.rb
結果はこんな感じ。
アプリログ
禁則事項なので書けません！！！！
ただ、fluentdでJSON化していればdatacounterに食わせることで、上に書いたApacheと一緒で
特定タグ・パラメータを正規表現でパターン化・グループ化することで、集計とかが凄く簡単に出来る。
取りこぼしが無いかとかの厳密なテストはまだしていないので、
誤差が許されない物はまだ厳しいかも知れないけど、誤差が許される様な物はとても助かっている。
というか、あまり言うことじゃないかも知れないけど、サービス計測レベルでは大半の数値は誤差許容出来る。
例えば、ある処理が時間辺り何回叩かれているとかを知る時に、仮に実際は10000回処理されたけど、
datacounterでは±10くらいずれた数値出ても僕的には別に大丈夫。経理上のお金の計算じゃないんだから。
なので、今までわざわざ
ログ読む→パースしてMySQL入れる→集計・計算をするバッチ実行→Excelに落としてグラフ化
とかしていた合計値や割合を算出していた物は、ストリーミング処理でグラフ化までが一気に
出来るのでそもそもバッチ処理が必要無くなりました。
ただ、fluentdを入れたから今までの仕組みを捨てるかというと全くの逆で、
MySQLのデータは詳細を確認したりグラフ化していない物を取ったりとかで今も動かしてはいますよ。
ログ自体は元のファイルをアーカイブ化して持っています。
むしろ今までのこの仕組も並行して残せるので本当に助かっています。
なんかやめようとしたり変えようとすると色々面倒臭い事とかあったりするじゃないですか。
なので、今まではある程度のデータ量を少しでもリアルタイムに近く可視化したい、の場合だと
scribe（使ったこと無いけど）とかで集めてHadoop投げて計算させて、結果をDBとかKVSとかに保存して、
結果をグラフに出来る管理画面作ってでグラフ書いて・・・
とかやらないといけなかったので、僕にはとても無理だったんですが、fluentdならin_tailプラグインによって
非破壊的に（今まで試したレベルではログファイル破壊される事象は発生してない）
既存ログファイル読んで、グラフ作ってという事を完結できるので、大変宜しいと思います。
というか、ログ出ていないと上に書いたこと何も実施出来無いので意味が無いので、アプリ側もちゃんとログを出そうね！
