「Fluentd meetup in Japan」に参加しました
http://www.zusaar.com/event/193104
感想など
fluentdは導入もプラグインの作成も比較的簡単なようなので、とりあえず、触ってみないと。
社内ネットワークにも比較的簡単に導入できるんじゃないだろうか。ログを残すシーンはあると思うし。
とりあえず、今日の資料はどれも有用なので、後でもう一度見直そうと思う。
関係ないけど、Amazon SQS、Amazon SNSはちょっと気になるから後で調べておこう。
濃密な内容過ぎて、脳が疲れた・・・
以下、適当なメモ・・・
「What's Fluentd? - The missing log collector」 古橋 貞之さん(@frsyuki)
- 対 Scribe
- Fluentの方がインストールが楽
- gem install
- apt、yum
- Fluentの方がカスタマイズも楽
- rubyなので簡単に。変更したら再コンパイルもない
- Fluentの方がインストールが楽
- 対 Flume
- masternode、Zookeeperが必要
- 導入のハードルが上がる
- 設定が結構たいへん
- Flumeには設定が一元管理されるため、大規模な場合は、その点では有利
- masternode、Zookeeperが必要
- アーキテクチャ
- Input
- ノンブロッキング
- Buffer
- 一番大事
- データを一定期間貯める
- チャンクを固めて投げる
- チャンク送出エラー時のリトライ処理
- Output
- 書きだす処理の部分で、拡張が簡単
- Input
- 同梱されているプラグイン
- テスト用のフレームワークもある
- MRUnitテイスト
- Dataは全てTCPで。ただし、HeartbeatはUDPを使用。
- 文字コード
- バイナリ
- MessagePack
- バイナリ
- TREASURE DATA のフレームワーク?
- AWS上で動作
- Hive
- ディスクの使用料の部分はなるべく安く
- どのようなデータを使うかは、利用直後には分からないかもしれないから
- 解析部分で課金
- Bufferの順序は保証
- ただし、S3などに使用するパラレルモード(2〜3個のチャンクをまとめて投入)の場合は、順序は保証されない
- S3は書き込みレイテンシが大きい
- ただし、S3などに使用するパラレルモード(2〜3個のチャンクをまとめて投入)の場合は、順序は保証されない
- 認証は今のところなし
- セキュアなサーバでの使用を前提
- 自前でセキュアに対応するプラグインを作成できる
- APPサーバにfluentdがあれば、直接MongoDBへ書き込みはできるが、MongoDBに書きこむ前に一度集約することで、負荷の軽減
- 設定ファイルはAPPサーバ毎になので、大規模でfluentdを使うなら、Puppetなどの構成管理ツールで設定ファイルの管理が必要
- include http://コンフィグサーバ/ の利用も検討
- Bufferサイズは制限可能
- デフォルトは256MB
- 超えた場合
- ファイルサイズが超えた
- ファイルが増える
- キューの長さを超えた
- 一番古いものが捨てられる
- セカンダリという仕組みがあありそちらに
- ログを絶対になくしたくない場合
- 入力時にバックアップ用にローカルに保存しておくなどで対処可能
- ファイルサイズが超えた
- Bufferに書きこむところのリトライ機能
- inputプラグインの実装による
- AWSを使う場合、EBSが死んだりした場合に起きそう
「Dive into Fluent Plugin」 Masahiro Nakagawaさん (@repeatedly)
「fluent を使った大規模ウェブサービスのロギング」 舘野 祐一さん (id:secondlife, @hotchpotch)
- データの規模
- 1500万UU PCのみ
- 110万レシピ
- このくらいの規模なら転送サーバは1台で十分
- RPMでfluentdで導入した場合
- ruby 1.9.2 をインストール。既に入っている、旧バージョンに影響のない形で
- AWSの話
- DynamoDB使う?
- 検討に値する。東京リージョンに導入されたら。
- DynamoDBはバルクインサートがない。現在、RESTで1件ずつ
「fluentをサービスで使ってみた」 Tetsuya Ohiraさん(@just_do_neet)
- 運用にまつわる話
- fluentdが落ちたりした場合は、APPサーバのローカルの生ログから復元
- プラグインの問題は自分でも直せる安心感