Fluentd casual
Upcoming SlideShare
Loading in...5
×
 

Fluentd casual

on

  • 8,589 views

 

Statistics

Views

Total Views
8,589
Views on SlideShare
6,168
Embed Views
2,421

Actions

Likes
15
Downloads
29
Comments
0

8 Embeds 2,421

http://6pongi.wordpress.com 1235
http://okochang.hatenablog.jp 622
http://d.hatena.ne.jp 542
http://webcache.googleusercontent.com 14
http://translate.googleusercontent.com 3
https://twitter.com 3
http://cache.yahoofs.jp 1
http://www.diffbot.com&_=1361098584689 HTTP 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Fluentd casual Fluentd casual Presentation Transcript

  • 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か?rsyslogsyslog-ngcron(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 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>
  • 今使っている話。
  • 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はとてもいい!!とりあえず影響が出ない様に小規模な所からサラッとやってみる。細かい設定とかは直接質問して貰えれば。ご清聴ありがとうございました。