fluentd Casual Talks

自己紹介

id:oranie@oranie

• サイバーエージェント グループ子会社で、グループ内でも余り知られていないシステムでなんか色々やる簡単なお仕事しています。

• 緑色のみんながよく知っているサービスの裏側とかは全く知らないです！聞かないで下さい！

• カジュアル枠として参戦でございます。優しくしてね！

今回のテーマ

「fluentdはじめました」

言いたいこと

fluentdを使ってみているという話が中心です。

詳細な話は結構割愛。

今日発売のSofftwareDesignがスピーカー殺しすぎる。

なんでこんな事をやる？

●apacheログからレスポンスタイム、ステータスコードの可視化とかやっている人いる？

●アプリが出している情報の可視化とかも。

fluentd＋ fluent-plugin-datacounter＋Cactiを使って

Webサーバのレスポンスタイムを可視化したり

他に

Webサーバのレスポンスステータスの状況とか

更にアプリログで

なんのかは説明できないけど、

サービス的に意味のある統計情報がリアルタイムで見れる。

今まで日次＋Excel手作業だった。担当者（僕）がサボるともっと時間掛かっていたけど！

なんでこんな事やるの？

●apacheログからの状況可視化→運用面でのメリット

●appログからのサービス状況可視化→ビジネス的な解析

●システム運用面でのメリット＋ビジネス的な解析も運用側だけ

で出来そう。

●サービス用DB参照するのとかは色々とね。

●MySQLならレプリすぐ作れるけど、Oracleなのでサーバ作るのに・・・・。

旧構成（と言っても今も動いている）

Webサーバ

集約サーバ

日次処理によるログ退避

DBサーバ

各Webサーバの生Apacheログをパー

ス、追加情報を付与して整形する 各log_data{yyyymm}テーブルを元に

解析用のテーブルとか分割したテーブ

ル作る

DBにINSERTする

必要な元ネタテーブルが作成完了した

ら、各集計用スクリプトを実行し、それぞ

れのテーブルを更新して行く

日次、月次での各テー

ブル作成、及び集計処

理を実行

この方式の欠点

・ログが大量だと全部DBに入れるのに糞重い

・ログが大量だと日次処理、月次処理が糞重い

・基本処理が日次なので、昨日の状況を見たい時でもDBに格納されてからバッチ実行を待って、それからデータをCSVで落としてExcelでグラフ・・・・ヽ(`Д´)ﾉﾑｷｰ

・「ログは日次で退避させる」という仕様は変えられない。

そこに！

なぜfluentdか？

rsyslog

syslog-ng

cron（rsync、scp、ftp）で取得との違い

思いつくままに

●設定が面倒くさい。

● syslog-ngはオワコンくさい。（2年前くらいから経路機器のログ集約で使ってますよ。ちくしょう！）

●デフォだから逆に使いたくない。

（設定問題でkernelが出すmessageログとかに支障を出したくない）

●今の仕組み変えなきゃいけない。

● cronのタイムラグ。サイズが大きくなると差分だけ欲しい。差分と言えばrsync？●今の需要なら受信した側も差分だけで良いパターンがほと

んどだけど、そこまで考慮したプログラム組むの面倒くさ

い・・・。

これらの問題を踏まえてfluentdの良い所

●設定が柔軟

●プラグインが豊富

（out系は主要なデータストア向けがほぼ出揃った。）

●既存のログシステムに影響を与えずに新たなログ収集・解析が出来る

（主にin_tailを使えばね）

●大規模で使われている安心感（cookpadさん,NHNさん）

●開発が活発（本体＆プラグイン共に）

●運用サーバはRHEL系がメインなのでtd-agent使うと構築も捗る

●必要なプラグインを作るのが容易らしい（僕はまだ作っていないですが・・・・）

設定例

もしローカル上のログを読んで、別ディレクトリに吐き出す場合。

LogFormat "%{X-Forwarded-For}i %h %l %u %t ¥"%r¥" %>s %b ¥"%{Referer}i¥" ¥"%{User-Agent}i¥" %D" combined

のapacheログを読んで、それをfluentdで構造化して別のディレクトリに吐いてみる。

設定例

#読み込む設定<source>type tailformat /^(?<XFF-host>[^ ]*) (?<host>[^ ]*) [^ ]* (?<user>[^ ]*) ¥[(?<TIME>[^¥]]*)¥] "(?<method>¥S+)(?:

+(?<path>[^ ]*) +¥S*)?" (?<status>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^¥"]*)" "(?<agent>[^¥"]*)" (?<response_time>[^ ]*))?$/

path /var/log/httpd/access_logtag apache.accesspos_file /var/log/td-agent/tmp/access.log.pos

</source>

#書き込む設定<match *.**>type filetime_slice_format %Y_%m_%dcompress gzippath /var/log/td-agent/access_log

</match>

今使っている話。

fluentdを導入した今の構成

補足

収集サーバ＋中間サーバ＋集計サーバ

なんでこの構成？

中間サーバの必要性

収集サーバ側fluentdプロセスのイレギュラー状況を避ける為に中間で「必ず」受信出来る構成を取る為

中間サーバでの負荷分散

集計サーバが一個で良い理由は今そのレベルだから。

ざっくり今の内部概要

導入・運用していて困った事とか。

●不具合はあった。

シンボリックリンク読むと永久ループとかUS-ASCII以外の文字列入るとエラーになるとか、prelinkのせいでrubyが壊れる為の回避設定に一部環境で抜けがあったとか。（全部直ってますよ）

●公式ドキュメント古い！！！！！！＆日本語版無い！

●プラグインの情報が散在している。

●性能について

in_forwardで安定して受信出来るのは1プロセス大体10,000message/secが限界だった。（Xeon E5607 2.27GHz）

●プロセス単体では受信性能がCPUコア分スケールしないので、手動マルチプロセスしている。今は3プロセス起動でとりあえず凌いでいる。

細かいtips的なもの

●Web/App側のconfigは動的生成して管理している。（詳細はこのあと）

●in_tailプラグインを使って読む時に、対象のログ構造を正規表現で記述するので、fluentdで設定する前にperl5.10以降だと名前付き後方参照が出来るので、それでテストしています。

●in_tailは今の所readするログファイルの名前の指定をしないといけない。rotatelogsとかで/access_log.%Y-%m-%dな名前でプロセスが初めからログファイルを作成する場合は、cronでシンボリックリンクを再作成する事で回避。

●forwardで投げる場合、互いの死活監視にudpパケットも投げるので、tcpとudpを許可しないと繋がらない。

●細かい内容をブログに書いて、そのURLをTwitterで「#fluentd」を付けてつぶやくと結構幸せになれた。

config管理について

各サーバ用のconfig配布方法

Configを動的生成する理由

●各ホスト毎に個別の値を持つ設定を付与する為、 configをPSGIで動的生成している。

(exミドルウェア名.ミドルウェア内のタグ.サービス名.IPアドレス

tag: apache.access.web_A.192.168.220.101

●負荷分散で受信する側のプロセスを複数起動しているので、サーバ

毎にメインで送信する先のportを分けている。

●例の様な値を設定したい時とかに、いちいちサーバ毎のconfig書きたくないし、chefとか（大人の事情で）入れられないのでいちいちscpで配布とかしか出来ない環境なので嫌だ。

なので

●チロッと書くには楽だったのでplack使っている。fluentdがrubyだからsinatraとかも良いかもね。

●configの内容はblogとかに書いているので、適当に読んで貰えれば。

●include rbとかでruby実行して動的生成されたconfig読み込みが今後出来ると更に捗るかも。

個人的な展望

●fluentd-plugin-mongoを利用して、datacounterだけでは計測出来ない細かい解析をしていきたい。

●もっと詳細なログ情報を集約・視覚化する事でシステム運用

に役立てたいというか楽したい。

●もっとビジネス的に意味のある数値をリアルタイムに可視化

したい。

●グラフの数を増やす時にCactiだと死ねるので、新しいグラフツールの導入（GrowthForecast とか）。

まとめ

fluentdはとてもいい!!

とりあえず影響が出ない様に小規模な所からサラッとやってみる。

細かい設定とかは直接質問して貰えれば。

ご清聴ありがとうございました。