Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Fluentd casual
Semelhante a Fluentd casual (20)
Mais de oranie Narut
Fluentd casual
- 2. 自己紹介 id:oranie @oranie • サイバーエージェント グループ子会社で、グループ内でも余り知ら れていないシステムでなんか色々やる簡単なお仕事しています。 • 緑色のみんながよく知っているサービスの裏側とかは全く知らない です！聞かないで下さい！ • カジュアル枠として参戦でございます。優しくしてね！
- 4. 言いたいこと fluentdを使ってみているという話が中心です。 詳細な話は結構割愛。 今日発売のSofftwareDesignが スピーカー殺しすぎる。
- 6. fluentd＋ fluent-plugin-datacounter＋Cactiを 使って Webサーバのレスポンスタイムを可視化したり
- 10. 旧構成（と言っても今も動いている） Webサーバ 日次処理によるログ退避 集約サーバ DBサーバ 各Webサーバの生Apacheログをパー ス、追加情報を付与して整形する 各log_data{yyyymm}テーブルを元に 日次、月次での各テー 解析用のテーブルとか分割したテーブ ル作る ブル作成、及び集計処 理を実行 必要な元ネタテーブルが作成完了した DBにINSERTする ら、各集計用スクリプトを実行し、それぞ れのテーブルを更新して行く
- 12. そこに！
- 14. 思いつくままに ●設定が面倒くさい。 ● syslog-ngはオワコンくさい。 （2年前くらいから経路機器のログ集約で使ってますよ。ちくしょう！） ●デフォだから逆に使いたくない。 （設定問題でkernelが出すmessageログとかに支障を出したくない） ●今の仕組み変えなきゃいけない。 ● cronのタイムラグ。サイズが大きくなると差分だけ欲しい。 差分と言えばrsync？ ●今の需要なら受信した側も差分だけで良いパターンがほと んどだけど、そこまで考慮したプログラム組むの面倒くさ い・・・。
- 15. これらの問題を踏まえてfluentdの良い所 ●設定が柔軟 ●プラグインが豊富 （out系は主要なデータストア向けがほぼ出揃った。） ●既存のログシステムに影響を与えずに新たなログ収集・解析が出来る （主にin_tailを使えばね） ●大規模で使われている安心感（cookpadさん,NHNさん） ●開発が活発（本体＆プラグイン共に） ● 運用サーバはRHEL系がメインなのでtd-agent使うと構築も捗る ●必要なプラグインを作るのが容易らしい（僕はまだ作っていないですが・・・・）
- 16. 設定例 もしローカル上のログを読んで、別ディレクトリに吐き出す場合。 LogFormat "%{X-Forwarded-For}i %h %l %u %t ¥"%r¥" %>s %b ¥"%{Referer}i¥" ¥"%{User-Agent}i¥" %D" combined のapacheログを読んで、それをfluentdで構造化して別のディ レクトリに吐いてみる。
- 17. 設定例 #読み込む設定 <source> type tail format /^(?<XFF-host>[^ ]*) (?<host>[^ ]*) [^ ]* (?<user>[^ ]*) ¥[(?<TIME>[^¥]]*)¥] "(?<method>¥S+)(?: +(?<path>[^ ]*) +¥S*)?" (?<status>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^¥"]*)" "(?<agent>[^¥"]*)" (?<response_time>[^ ]*))?$/ path /var/log/httpd/access_log tag apache.access pos_file /var/log/td-agent/tmp/access.log.pos </source> #書き込む設定 <match *.**> type file time_slice_format %Y_%m_%d compress gzip path /var/log/td-agent/access_log </match>
- 18. 今使っている話。
- 19. fluentdを導入した今の構成
- 21. ざっくり今の内部概要
- 22. 導入・運用していて困った事とか。 ●不具合はあった。 シンボリックリンク読むと永久ループとかUS-ASCII以外の文字列入る とエラーになるとか、prelink のせいでrubyが壊れる為の回避設定に一 部環境で抜けがあったとか。（全部直ってますよ） ●公式ドキュメント古い！！！！！！＆日本語版無い！ ●プラグインの情報が散在している。 ●性能について in_forwardで安定して受信出来るのは1プロセス大体 10,000message/secが限界だった。（Xeon E5607 2.27GHz） ●プロセス単体では受信性能がCPUコア分スケールしないので、手動マ ルチプロセスしている。今は3プロセス起動でとりあえず凌いでいる。
- 23. 細かい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」を付けてつぶやく と結構幸せになれた。
- 24. config管理について
- 25. 各サーバ用のconfig配布方法
- 26. Configを動的生成する理由 ●各ホスト毎に個別の値を持つ設定を付与する為、 configをPSGIで 動的生成している。 (ex ミドルウェア名.ミドルウェア内のタグ.サービス名.IPアドレス tag: apache.access.web_A.192.168.220.101 ●負荷分散で受信する側のプロセスを複数起動しているので、サーバ 毎にメインで送信する先のportを分けている。 ●例の様な値を設定したい時とかに、いちいちサーバ毎のconfig書き たくないし、chefとか（大人の事情で）入れられないのでいちいちscp で配布とかしか出来ない環境なので嫌だ。
- 27. なので ●チロッと書くには楽だったのでplack使っている。fluentdが rubyだからsinatraとかも良いかもね。 ●configの内容はblogとかに書いているので、適当に読んで 貰えれば。 ●include rbとかでruby実行して動的生成されたconfig読み込 みが今後出来ると更に捗るかも。
- 28. 個人的な展望 ●fluentd-plugin-mongoを利用して、datacounterだけでは計 測出来ない細かい解析をしていきたい。 ●もっと詳細なログ情報を集約・視覚化する事でシステム運用 に役立てたいというか楽したい。 ●もっとビジネス的に意味のある数値をリアルタイムに可視化 したい。 ●グラフの数を増やす時にCactiだと死ねるので、新しいグラフ ツールの導入（GrowthForecast とか）。