big data入門に見せかけたfluentd入門

Big  Data入門に見せかけたFluentd入門

June  5th,  2013  Authored  by  Keisuke  Takahashi  (a.k.a.  @keithseahus)

• ご案内  – このドキュメントの想定読者層  

•  Big  DataやFluentdのプロでない方。Big  Data関連の仕事をしていない方や、Fluentdに触ったことが無い方。  

•  Fluentdが注目される理由を、背景から理解したい方。  •  Fluentdの開発者向け公式ドキュメント（現行）が日本語に翻訳されたら本気を出そ

うと思っているソフトウェア開発者。  

– 間違いに気づいたら…  •  著者にそっとご連絡頂けると嬉しいです。ベストエフォートで直します。  

– ライセンスについて  •  クリエイティブ・コモンズ・ゼロです。再利用にあたって、著者の表示を削除するこ

とを含め、著作権上の制約は一切ありません。居住地における法規及び国際法の範囲内で、ご自由にお使い下さい。  

– 免責  •  本ドキュメントにより生じた一切の事象について、著者は一切の責任を負わないも

のとします。

Big  Data  is  何？

各自がBig Dataの定義を持っており、唯一の正しい定義というものは無いはずです。みなさんはどう捉えていますか？

多くの文献が、Gartnerの発表を引用しています。

多くの文献が、Gartnerの発表を引用しています。

データの容量(volume)  データの種類(variety)  

データが増加する速度(velocity)  それぞれが飛躍的に増大するため  

活用することが難しいと考えられていたデータ

ここでは、これをベースに話を進めます。

ビジネス面での課題

データの容量  -­‐  volume  -­‐

IDCによれば、世界のデータ量は、2015年には7.9ゼタバイトまで増大するとのことです。

データの種類  -­‐  variety  -­‐

ユーザはインターネット上の多様なサービスを利用してデータを生成し、サービスもまた増え続けています。

データを生成するのは人間だけではありません。デバイスが生成するデータもあります。

Webサイトのマウストラッキングデータも活用可能なデータです。

データの解像度も増えています。

データが増加する速度  -­‐  velocity  -­‐

モバイルで常時接続の高速インターネットが可能になり、ユーザが膨大なデータをインプット・アウトプットできる時代になりました。

近距離無線やセンサーデバイスが発達し、データを生成しインターネットへ出力する主体は、飛躍的に増加しています。

結果、データは加速度的に増加し、データの総量は指数関数的に増加しています。

技術によるアプローチ

容量・種類・速度の課題に対する、技術的なアプローチを見てみましょう。

大量データの検索を  高速化するための技術  

volumeに対するアプローチです。

• インメモリデータベース  • 列指向データベース  • 超並列データベース  • ハイブリッド型データベース

HBase, Hypertable, Cloudataなどは列指向データベースにカテゴライズされます。

大量データの取扱いを  簡易にするための技術  

varietyに対するアプローチです。

• キーバリューストア  • ドキュメント指向データベース  • グラフデータベース

例えばKVSはCassandra, Kyoto Cabinet, Couchbase, Redis, Riak、ドキュメント指向DBはMongoDB, CouchDB、グラフDBはNeo4jが有名です。

大量データの処理を  高速化するための技術  

velocityに対するアプローチです。

• 並列分散処理  • 複合イベント処理  • イベントストリーム処理

並列分散処理はHadoopのMapReduceが有名。データを蓄積せずに、流れるデータに対して解析処理をかける技術もあります。

何が変わるのか？

分析手法

従来のデータ分析 Big  Dataの分析

生成元 企業の基幹システム アクセスログ  ソーシャルデータ  センサー  ...

構造 構造化データ 半構造化データ  非構造化データ  

保管方式 リレーショナルデータベース  データウェアハウス

分散ストレージ  キーバリューストア  ...

分析手法 定型レポート データマイニング

視覚化 ビジネスインテリジェンス ビジネスインテリジェンス

分析の対象が質的にも量的にも異なるため、従来とは異なるアプローチで分析する必要があります。

従来のデータ分析 Big  Dataの分析

生成元 企業の基幹システム アクセスログ  ソーシャルデータ  センサー  ...

構造 構造化データ 半構造化データ  非構造化データ  

保管方式 リレーショナルデータベース  データウェアハウス

分散ストレージ  キーバリューストア  ...

分析手法 定型レポート データマイニング

視覚化 ビジネスインテリジェンス ビジネスインテリジェンス

まさにゴミの山から宝物を探すような分析になります。データマイニングについて少し深堀りしましょう。

データサイエンティストと呼ばれる人たちが、統計的手法を用いてBig Dataの分析を行います。そのため、統計分析が可能な形にBig Dataをクレンジングする必要があります。

Big  Data  活用までの道のり

Big Dataが活用されるまでのシーケンスを追ってみましょう。

• 監視やレポート（ゴール）  

Big Data活用のゴールは、主に監視やその予測に役立てたり、ビジネスを先見するレポートを出力することです。

• 監視やレポート（ゴール）  • データマイニングと可視化  

予測や予見など、未来を推し量ることができるのは、統計分析を行うためです。

• 監視やレポート（ゴール）  • データマイニングと可視化  • 蓄積と処理  

基本的に、材料となるデータはストレージに蓄積します。それらに対して、データマイニングが可能となるよう、必要な処理を行います。

• 監視やレポート（ゴール）  • データマイニングと可視化  • 蓄積と処理  

• データの生成

蓄積されるデータは、世界中の不特定な場所で常に生成されています。

• 監視やレポート（ゴール）  • データマイニングと可視化  • 蓄積と処理  • ？？？  • データの生成

重要なシーケンスが一つ抜けています。何でしょう？

データ収集

不特定の場所で生成されるデータを集め、ストレージへと集約する処理です。

従来

従来のデータ分析での収集方法を見てみましょう。ここではログデータを例にします。

最もポピュラーなデータ収集方法は、syslogではないでしょうか。

問題点

従来的な手法であるsyslogををBig Dataに対しても使用することは、無理があります。なぜでしょう？

構造の観点で、データには大きく2つに分類されます。統計分析を行うためには、データは構造化されている必要があります。

ログは  非構造化データ  

である  （Big  Data解析の観点から）

各種ログにも構造はありますが、それはアプリケーションごとに異なる独自の構造で、そのまま集約して分析することはできません。

Big Data時代には様々なイベントログが分析対象となります。従来のログ同様、これらは非構造化データです。

分析をするためには  構造化処理が必要  

ログを構造化  するには？

非構造化データを構造化データに変換するためには、どうすればよいでしょう？

世の中には、さまざまな非構造化データがあります。

バラバラな  フォーマットを  

共通化

これらを、構造化データに変換するためには、まずフォーマットを統一する必要があります。

共通の  フォーマット？

そのフォーマットの要件は何でしょう？

 ASCIIである  

現在のBig Data分析の対象は、バイナリではなくASCIIデータです。

 ASCIIである   値の意味が明示的である  

数値やテキストだけがあっても分析できません。それが何の値なのか、システムにとって明示的である必要があります。

 ASCIIである   値の意味が明示的である   柔軟である

データの種類は不特定です。スキーマレスであることが必要です。

それ何て　　　　　？

※まぁ、　　　　　でもいいですけど…

そんなログコレクタ

不特定多数の非構造化データを収集し、構造化データに変換する、ログコレクタがあります。

他のログコレクタ  との比較

ログコレクタは他にもあります。比較してみましょう。

Scribe

Flume

Fluentd

設定は後述のincludeディレクティブで、HTTPでコンフィグのURLを指定して読み込むことができ、これで一元管理が可能です。

そんなログコレクタ

重要なことなので２回言います。

重要なことなので２回言います。

Log  everything  in  JSON.

Sponsored  by

ちなみに、Treasure Dataは、Fluentdを使用してBig Dataソリューションを展開する注目のベンチャーです。

先ほど、Fluentdのメリットを挙げました。

これらの特徴について、詳しく追ってみましょう。

インストール

インストールが容易という特徴です。

　　の環境が  ある場合

　　の環境が  無い場合

Rubyがインストールされていなくても、Fluentdは利用可能です。

td-­‐agent

td-agentをインストールします。

td-agentのインストールも、非常に簡単です。

gem版はtrunkに近い、所謂オープンソース版。  td-­‐agentの方が十分テストされているとのこと。

一応、留意点です。

gem版とtd-­‐agentとで  標準プラグインの種類が若干異なるらしい…

一応、留意点です。

インストール前に必要な、  ちょっとした準備があります。  

hOp://docs.fluentd.org/ja/arTcles/before-­‐install

NTPの設定、ファイルディスクリプタの最大値増加、ネットワーク関係のカーネルパラメータの最適化。設定後、OSの再起動が必要です。

セットアップ

セットアップが容易という特徴です。

コンフィグファイル

セットアップは単一のコンフィグファイルを編集することで行います。

場所

コンフィグファイルは以下の場所にあります。

gemでインストールした場合は、コマンドでパスを指定します。td-agentを利用する場合は、特定のパスにコンフィグファイルがあります。

形式

コンフィグファイルの形式を見てみましょう。

Apacheのコンフィグに近い、構造化テキストです。

風味

構成

XMLの構成を見てみましょう。

Fluentdのコンフィグファイルは、3つのディレクティブから成り立っています。シンプルですね。

構造化ログ

ログが構造化されているという特徴についてです。

{  “Time”:”2013-­‐07-­‐05  09:00:00”,  ”Tag”:”apache.log”,  ”Record”:{“host”:”127.0.0.1”,”method”:”GET”,”path”:”/”}  }

Fluentdが出力するイベントログは、先述の通り、JSONで構造化されています。例えばApacheのログを読み込み、このように出力することができます。

入力ソース

入力ソースを自由に選べることが特徴の一つです。どれくらい自由なのでしょう？

プラグインで  自由に定義可能  

定義できさえすれば、何でも入力ソースにできます。

出力先

出力先を自由に選べることも特徴の一つです。どれくらい自由なのでしょう？

プラグインで  自由に定義可能  

こちらも、扱える範囲であれば、どこへでも出力できます。

機能拡張

機能拡張が容易であることも特徴の一つです。

Rubyで  自由に拡張可能  

Rubyでプラグインを作ることができます。

速度

FluentdはRubyで書かれていますが、速度が必要な部分はCで書かれています。それによる高速さを示す事例を紹介します。

事例1  Cookpad  

hOp://www.slideshare.net/hotchpotch/20120204fluent-­‐logging

合計100台弱からtd-agentでログを収集し、ほとんどのロギングはfluentdに移行。中央のfluentdは1台で、1スレッドで十分処理できているとのことです。

事例2  NHN  Japan  

hOp://www.slideshare.net/tagomoris/log-­‐analysis-­‐with-­‐hadoop-­‐in-­‐livedoor-­‐2013

16ノードからログの収集を行い、毎秒120,000+行の転送量、最高400Mbpsを記録し、毎日1.5+TBのログを集めいているとのことです。

メンテナンス

Fluentdはもちろんメンテナンスされているソフトウェアです。

オープンソース  コミュニティ

本体は開発者である古橋氏を中心に、33名のコントリビューターがいます。膨大なプラグインはコミュニティの各メンバーが開発・メンテしています。

使用例

簡単な使用例を紹介します。

192.168.0.3

←  あえて混在環境を  　作り出すため  　gemでインストール

←  商用を想定し  　td-­‐agentでインストール

GlusterFSのクラスタで各ノードに出力されるログを集めてみましょう。

<source> type tail path /var/log/glusterfs/usr-local-glusterfs-3.4.0beta2-etc-glusterfs-glusterd.vol.log pos_file /var/log/td-agent/usr-local-glusterfs-3.4.0beta2-etc-glusterfs-glusterd.vol.log.pos tag glusterd format /^(?:\[(?<date_ymd>[0-9]{4}-[01][0-9]-[0-3][0-9]) (?<time_hms>[0-2][0-9]\:[0-5][0-9]\:[0-6][0-9])\.(?<time_usec>[0-9]{6})\]) (?<log_level>[TDINWECA]) (?:\[(?<source_file_name>[^\[\]:/ ]*):(?<source_line>[0-9]*):(?<function_name>[^\[\]:/ ]*)\]) (?<component>[^\[\]:/ ]*)\: *(?<message>.*)$/ rotate_wait 5 </source>

/etc/td-­‐agent/td-­‐agent.conf  (GlusterFS側)

GlusterFS側のtd-agentには、glusterdのログファイルをtailさせます。sourceディレクティブにはこのように記述します。

<match glusterd.**> type hostname key_name host add_prefix filtered </match> <match filtered.glusterd.**> type forward send_timeout 60s recover_wait 10s heartbeat_interval 1s phi_threshold 8 hard_timeout 60s <server> name dev-centos host 192.168.0.3 port 24224 weight 60 </server> <secondary> type file path /var/log/td-agent/forward-failed </secondary> </match>

/etc/td-­‐agent/td-­‐agent.conf  (GlusterFS側)

matchディレクティブでは、hostnameプラグインを使用し、イベントログの中にノード名を挿入するようにしました。

# wget https://raw.github.com/fukata/fluent-plugin-hostname/master/lib/fluent/plugin/out_hostname.rb

/etc/td-­‐agent/plugin  にプラグインをインストール  (GlusterFS側)

<source> type forward port 24224 bind 0.0.0.0 </source> <match filtered.glusterd.**> type file path /home/keith/var/log/fluent/glusterd </match>

$HOME/fluent/fluent.conf  (192.168.0.3側)

ログ収集を行うノードには、出力先のディレクトリパスを指定します。

[root@dev-centos ~]# gluster volume info dist Volume Name: dist Type: Distribute Volume ID: a62edcc6-23c9-46d8-bf6d-f0682ac08c64 Status: Stopped Number of Bricks: 2 Transport-type: tcp Bricks: Brick1: glusterfs-unstable-01:/mnt/lv0/dist Brick2: glusterfs-unstable-02:/mnt/lv0/dist

192.168.0.3側でGlusterFSのvolumeをstart

[root@dev-centos ~]# gluster volume start dist volume start: dist: success

では、ログを出すために、GlusterFSのvolumeをstartしてみましょう。

Fluentdでログの構造化と転送が行われたことを、192.168.0.3側で確認。

[root@dev-centos ~]# grep glusterfs-unstable-01 /home/keith/var/log/fluent/glusterd.20130708.b4e0ed6e32655d35f | tail -3 2013-07-08T00:52:43+09:00 filtered.glusterd {"date_ymd":"2013-07-07","time_hms":"15:52:43","time_usec":"778961","log_level":"I","source_file_name":"socket.c","source_line":"3495","function_name":"socket_init","component":"0-management","message":"using system polling thread","host":"glusterfs-unstable-01.localdomain"} 2013-07-08T00:52:43+09:00 filtered.glusterd {"date_ymd":"2013-07-07","time_hms":"15:52:43","time_usec":"779397","log_level":"W","source_file_name":"socket.c","source_line":"514","function_name":"__socket_rwv","component":"0-management","message":"readv failed (No data available)","host":"glusterfs-unstable-01.localdomain"} 2013-07-08T00:52:43+09:00 filtered.glusterd {"date_ymd":"2013-07-07","time_hms":"15:52:43","time_usec":"779668","log_level":"I","source_file_name":"socket.c","source_line":"2236","function_name":"socket_event_handler","component":"0-transport","message":"disconnecting now","host":"glusterfs-unstable-01.localdomain"}

formatで指定した正規表現の通りにログをパースし、JSONで転送できていることが確認できました。

[root@dev-centos ~]# grep glusterfs-unstable-02 /home/keith/var/log/fluent/glusterd.20130708.b4e0ed6e32655d35f | tail -3 2013-07-08T00:52:43+09:00 filtered.glusterd {"date_ymd":"2013-07-07","time_hms":"15:52:43","time_usec":"759502","log_level":"I","source_file_name":"socket.c","source_line":"3495","function_name":"socket_init","component":"0-management","message":"using system polling thread","host":"glusterfs-unstable-02.localdomain"} 2013-07-08T00:52:43+09:00 filtered.glusterd {"date_ymd":"2013-07-07","time_hms":"15:52:43","time_usec":"759838","log_level":"W","source_file_name":"socket.c","source_line":"514","function_name":"__socket_rwv","component":"0-management","message":"readv failed (No data available)","host":"glusterfs-unstable-02.localdomain"} 2013-07-08T00:52:43+09:00 filtered.glusterd {"date_ymd":"2013-07-07","time_hms":"15:52:43","time_usec":"760057","log_level":"I","source_file_name":"socket.c","source_line":"2236","function_name":"socket_event_handler","component":"0-transport","message":"disconnecting now","host":"glusterfs-unstable-02.localdomain"}

Fluentdでログの構造化と転送が行われたことを、192.168.0.3側で確認。

[root@dev-centos ~]# grep glusterfs-unstable-01 /home/keith/var/log/fluent/glusterd.20130708.b4e0ed6e32655d35f | tail -3 2013-07-08T00:52:43+09:00 filtered.glusterd {"date_ymd":"2013-07-07","time_hms":"15:52:43","time_usec":"778961","log_level":"I","source_file_name":"socket.c","source_line":"3495","function_name":"socket_init","component":"0-management","message":"using system polling thread","host":"glusterfs-unstable-01.localdomain"} 2013-07-08T00:52:43+09:00 filtered.glusterd {"date_ymd":"2013-07-07","time_hms":"15:52:43","time_usec":"779397","log_level":"W","source_file_name":"socket.c","source_line":"514","function_name":"__socket_rwv","component":"0-management","message":"readv failed (No data available)","host":"glusterfs-unstable-01.localdomain"} 2013-07-08T00:52:43+09:00 filtered.glusterd {"date_ymd":"2013-07-07","time_hms":"15:52:43","time_usec":"779668","log_level":"I","source_file_name":"socket.c","source_line":"2236","function_name":"socket_event_handler","component":"0-transport","message":"disconnecting now","host":"glusterfs-unstable-01.localdomain"}

上がFluentdで構造化したログ、下がオリジナルのログです。

[root@glusterfs-unstable-01 plugin]# tail -3 /var/log/glusterfs/usr-local-glusterfs-3.4.0beta2-etc-glusterfs-glusterd.vol.log [2013-07-07 15:52:43.778961] I [socket.c:3495:socket_init] 0-management: using system polling thread [2013-07-07 15:52:43.779397] W [socket.c:514:__socket_rwv] 0-management: readv failed (No data available) [2013-07-07 15:52:43.779668] I [socket.c:2236:socket_event_handler] 0-transport: disconnecting now

Fluentdの  アーキテクチャ

Fluentdのアーキテクチャについて追ってみましょう。

出典：hOp://www.slideshare.net/treasure-­‐data/the-­‐basics-­‐of-­‐fluentd

Fluentdの本体は3,000-4,000行の小さなソフトウェアで、それはプラガブルな作りとなっており、3つのパートにプラグインを適用して動作させます。

Fluentdのプラグイン  

どのようなプラグインがあるか、見てみましょう。

•  Inputプラグイン

–  in_forward  •  他のfluentd等からイベントログを受け取る

–  in_hOp  •  HTTP  POSTのURLをtag、bodyをrecordとしてイベントログを受け取る。

–  in_tail  •  イベントログをファイルから読み込む

•  ApacheとSyslogのパーサ付き

•  カスタムパーサも書ける

–  in_exec  •  外部プログラムから標準出力経由でTSV形式のイベントログを受け取る

–  in_syslog  •  syslogプロトコルでイベントログを受け取る

–  in_scribe  •  Scribeからイベントログを受け取る

–  ...  Inputプラグインは、外部ソースからイベントログを受け取るインタフェースです。thread socketとlisten socketを生成するためノンブロッキングです。

•  Bufferプラグイン

– buf_memory  •  メモリ上にバッファすることで速度を高める

– buf_file  •  ファイルにバッファすることで信頼性を高める

Bufferプラグインは2種類です。パフォーマンスを向上させるか、信頼性を向上させるかを選ぶことができます。一連の処理をスレッドセーフにする作用もあります。

•  Outputプラグイン

– out_file  •  イベントログをファイルに書き出す

•  ファイルは日ごとに生成する

– out_forward  •  イベントログを他のFluentdに転送する

•  ロードバランシングとフェイルオーバ機能を提供

– out_exec  •  TSV形式のイベントログを標準入力経由で外部プログラムへ渡す

– out_exec_filter  •  out_execにイベントログを渡す前に、他の外部プログラムに対するTSV形式イベン

トログの標準入出力を実行する。

– out_copy  •  イベントログを複製して複数のOutputプラグインに渡す

– out_roundrobin  •  複数のOutputプラグインに対してラウンドロビンでイベントログを渡す

Outputプラグインによって、イベントログの書き出し又は送信を行います。

•  Outputプラグイン(続き)– out_stdout

•  イベントログを標準出力に書き出す

– out_null•  イベントログを捨てる

– out_s3•  Amazon  S3にイベントログを出力する

– out_mongo•  イベントログをMongoDBへ書き出す

– out_mongo_replset•  出力先のMongoDBでReplicaSetを使用する場合はこちらを利用する

– out_webhdfs•  イベントログをHDFSへ書き出す

– …

Outputプラグインによって、イベントログの書き出し又は送信を行います。

多彩な  コミュニティ製  

プラグイン  

コミュニティでは、様々な開発者がプラグインを開発・公開しています。膨大な中から、ピックアップしてみました。

•  flowcounter  –  一定期間中に流れるイベントログの数とデータ量をカウントする

•  dstat  –  dstat用Inputプラグイン

•  ping-­‐message  –  fluentdプロセスをpingで死活監視する

•  munin  –  munin-­‐nodeのメトリックデータを取得するInputプラグイン

•  map  –  あるイベントログを異なるイベントログに変換する

•  noTfier  –  イベントログのマッチングとアラートメッセージの送信を行う

•  sampling-­‐filter  –  イベントログからサンプリングを行う

•  mysql  –  JSONのままMySQLにINSERTを行う

•  amplifier-­‐filter–  イベントログ中の数値の加減を行う

•  flaOen–  ネストされたkey/valueをフラットにする  

•  tail-­‐asis  –  パーサを使わずに行全体をイベントログに格納する

•  cassandra  –  Cassandra用Outputプラグイン

•  mysqlslowquery  –  MySQLのスロークエリログ用Inputプラグイン

•  twiOer  –  TwiOer  Streaming  API用Input/Outputプラグイン

•  zabbix  –  Zabbix用Outputプラグイン

•  mail  –  イベントログをメールに出力する

•  amqp  –  AMQP用Input/Outputプラグイン

•  serialport  –  シリアルポート用Inputプラグイン

•  extract_query_params  –  URLのクエリパラメータからkey/valueを取り出す

•  Tme_parser  –  時刻パラメタ用パーサ

•  irc  –  IRC用Outputプラグイン

•  dbi  –  DBとの接続にRubyのDBIモジュールを使うOutputプラグイン

•  tagfile  –  イベントタグを利用してソースのホスト毎に異なるディレクトリへイベントログをファイル

出力するOutputプラグイン

•  hostname  –  ホスト名をイベントログに挿入する

•  df  –  dfコマンド用Inputプラグイン

•  jvmwatcher  –  Java  VMの情報を収集するInputプラグイン

•  websocket  –  websocketサーバとして機能し、JSON文字列又はMessagePackバイナリを、接続された

全てのクライアントにブロードキャストするOutputプラグイン。

•  resolv  –  IPアドレスの名前解決をして上書きをする

Fluentd  プラグインの  

開発  

プラグインの開発も簡単にできるようになっています。詳しく見てみましょう。

•  カスタムプラグインのインストール

–  rubygemsで配布しない場合

•  /etc/fluent/plugin  にスクリプトを配置する

–  rubygemsで配布する場合

•  lib/fluent/plugin  に<TYPE>_<NAME>.rb  の名前でインストールされるようにする

まず、開発したプラグインをFluentdに読み込むための方法です。RailsのようにCoC(設定よりも規約)なスタイルです。

•  Inputプラグインを書く

– Fluent::Input  クラスを継承

– 規定のメソッドを実装

•  configure(conf)  •  start  •  shutdown  

– イベントログを生成する

•  Fluent::Engine.emit(tag,  Tme,  record)  –  tag:  String  –  Tme:  UNIX  Tme  in  integer  –  record:  Hash  

Inputプラグインの開発の仕方です。クラスを継承して規定のメソッドを実装し、受け取ったログからFluentdのデータ構造に合わせたイベントログを生成するだけです。

•  Bufferd  Outputプラグインを書く

– Fluent::BufferedOutput  クラスを継承

– 規定のメソッドを実装•  configure(conf)  •  start  •  shutdown  •  format(tag,  Tme,  record)  •  write(chunk)  

–  data  =  chunk.read  –  print  data  

– オプション

Outputプラグインは3種類が開発可能です。大筋はInputプラグインと同様です。

•  Time  Sliced  Outputプラグインを書く

– Fluent::TimeSlicedOutput  クラスを継承

– 規定のメソッドを実装

•  configure(conf)  •  start  •  shutdown  •  format(tag,  Tme,  record)  •  write(chunk)  

–  day  =  chunk.key  –  data  =  chunk.read  –  print  data  

例えば1日ごとに出力先ファイルを変更するようなOutputプラグインを書く場合、開発するのはTime Sliced Outputプラグインになります。

•  Non-­‐bufferd  Outputプラグインを書く

– Fluent::Output  クラスを継承

– 規定のメソッドを実装

•  configure(conf)  •  start  •  shutdown  •  emit(tag,  es,  chain)  

–  Fluentdがイベントを受け取ったらコールされる。

– 各イベントを処理するために、es.each  イテレータを使用する。

BufferプラグインをスルーするようなOutputプラグインも作れます。

•  Tail  Inputプラグインでパーサをカスタマイズする方法

– Fluent::TailInput  クラスを継承

– メソッドをオーバーライド

•  configure_parser(conf)  •  parse_line(line)  

ファイルをtailして読み込むようなInputプラグインを作る場合は、TailInputクラスを拡張して簡単に書けるようになっています。

•  プラグインのデバッグ方法

– デバッグメッセージの表示

•  fluentd  -­‐vv  で起動

•  match  **ディレクティブにtype  stdoutを指定

– out_copy  でstoreディレクティブの一つにtype  stdoutを指定

Rubyのpデバッグのような方法でデバッグする方法があります。また、out_copyを使用することで、デバッグ用のOutputプラグインにデータを流し込むことも可能です。

•  テストケースを書く

– Unitテスト・フレームワーク

•  Fluent::Test::InputTestDriver  •  Fluent::Test::OutputTestDriver  •  Fluent::Test::BufferedOutputTestDriver  

Unitテスト用のクラスも用意されています。

作ってみた  

TailInputを利用してGlusterFSの各ノードからログを収集するInputプラグインを書いてみました。ログコレクタ・フレームワークと言って良いくらい楽に作れます。

Class呼び出し時にセットしたいパラメタは、RubyのiniTalizeメソッド内で定義することも、独自のconfig_paramメソッドを使うこともできます。

parse_lineメソッドの引数にログが1行ずつ代入されているので、このメソッド内でパースしていきます。

TailInputでメインとなる作業は、parse_lineメソッドの拡張です。

最終的に、Fixnum型のunixTmeと、Hash型のレコードを、配列で返します。

簡単ですね。

まとめ  

•  Big  Dataを処理するには、前段階として「処理を前提とした収集」が必要。

•  ログコレクタの中で最も注目を集めているのがFluentd。

•  Fluentdはシンプルでプラガブル。柔軟でカスタマイズしやすい。デベロッパ・フレンドリー。

•  今まで個別に存在していたデータも、Fluentdで集約すればBig  Data分析の対象になり得る。レッツトライ。

参考文献  

1.  Christy  PeOey,  "Gartner  Says  Solving  'Big  Data'  Challenge  Involves  More  Than  Just  Managing  Volumes  of  Data"  hOp://www.gartner.com/newsroom/id/1731916  (2013/06/30)  

2.  2012  Big  Data  Now:  2012  EdiFon,  O'Reilly  Media,  Inc.  3.  Noreen  Burlingame  &  Lars  Nielsen,  2012  A  Simple  IntroducFon  To  DATA  SCIENCE,  New  Street  

CommunicaTons,  LLC  4.  三木大知 2013  『パターンでわかるHadoop  MapReduce  -­‐  ビッグデータの処理入門』翔泳社

368pp  5.  John  Gantz  and  David  Reinsel,  "ExtracTng  Value  from  Chaos"  hOp://www.emc.com/

collateral/analyst-­‐reports/idc-­‐extracTng-­‐value-­‐from-­‐chaos-­‐ar.pdf  (2013/06/30)  6.  Pramod  J.  Sadalage,  MarTn  Fowler,  2012  NoSQL  DisFlled  -­‐  A  Brief  Guide  to  the  Emerging  

World  of  Polyglot  Persistence,  Addison-­‐Wesley  Professional  7.  Guido  Schmutz,  2012  Welcome  NoSQL  for  Data  Services,  Data  VirtualizaFon  &  Big  

Data  hOp://www.servicetechsymposium.com/dl/presentaTons/nosql_for_data_services_data_virtualizaTon_and_big_data.pdf  (2013/06/30)  

8.  Shashan  Tiwari  2012『NoSQLプログラミング実践活用技法』翔泳社 432pp  9.  Publickey  「NoSQLの現状。これまでの成功と失敗」 hOp://www.publickey1.jp/blog/13/

nosql_2.html  (2013/06/30)  10.  Pete  Warden,  2011  Big  Data  Glossary  -­‐  A  Guide  to  the  New  GeneraFon  of  Data  Tools,  O'Reilly  

Media,  Inc.  11.  Tom  White,  2012  Hadoop:  The  DefiniFve  Guide,  3rd  EdiFon  -­‐  Storage  and  Analysis  at  Internet  

Scale,  O'Reilly  Media,  Inc.  12.  舘野祐一 「fluentd  を利用した大規模ウェブサービスのロギング」 hOp://

www.slideshare.net/hotchpotch/20120204fluent-­‐logging  (2013/06/30)  

13.  TAGOMORI  Satoshi,  "Log  analysis  system  with  Hadoop  in  livedoor  2013  Winter"  hOp://www.slideshare.net/tagomoris/log-­‐analysis-­‐with-­‐hadoop-­‐in-­‐livedoor-­‐2013  (2013/06/30)  

14.  "Fluentd  DocumentaFon"  hOp://docs.fluentd.org/  (2013/06/29)  15.  @johtani  「Fluentd  Meetup  Japanに参加しました。」 hOp://johtani.jugem.jp/?eid=60  

(2013/07/07)  16.  Sadayuki  Furuhashi,  "Fluentd  meetup  in  Japan  -­‐  Fluentd,  The  Event  Collector  Service"  hOp://

www.slideshare.net/treasure-­‐data/fluentd-­‐meetup-­‐in-­‐japan-­‐11410514  (2013/06/29)  17.  Sadayuki  Furuhashi,  "Fluentd  meetup  #2  -­‐  fluentd,  Log  everything  in  JSON"  hOp://

www.slideshare.net/treasure-­‐data/fluentd-­‐meetup-­‐2  (2013/06/29)  18.  Sadayuki  Furuhashi,  "Fluentd  meetup  #3  -­‐  CollecFng  app  metrics  in  decentralized  systems  -­‐  

Decision  making  based  on  facts"  hOp://www.slideshare.net/treasure-­‐data/fluentd-­‐meetup-­‐3  (2013/06/29)  

19.  Masahiro  Nakagawa,  "The  basics  of  fluentd"  hOp://www.slideshare.net/treasure-­‐data/the-­‐basics-­‐of-­‐fluentd  (2013/06/29)  

20.  "Fluentd  plugins"  hOp://fluentd.org/plugin/  (2013/06/29)  21.  "Treasure  Data:  Big  Data  as  a  Service"  hOp://www.treasure-­‐data.com/  (2013/06/30)  

Thank  you.