「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なので簡単に。変更したら再コンパイルもない
• 対 Flume
  • masternode、Zookeeperが必要
    • 導入のハードルが上がる
  • 設定が結構たいへん
  • Flumeには設定が一元管理されるため、大規模な場合は、その点では有利
• アーキテクチャ
  • Input
    • ノンブロッキング
  • Buffer
    • 一番大事
    • データを一定期間貯める
    • チャンクを固めて投げる
    • チャンク送出エラー時のリトライ処理
  • Output
    • 書きだす処理の部分で、拡張が簡単
• 同梱されているプラグイン
• テスト用のフレームワークもある
  • MRUnitテイスト
• Dataは全てTCPで。ただし、HeartbeatはUDPを使用。
• 文字コード
  • バイナリ
    • MessagePack
• TREASURE DATA のフレームワーク？
  • AWS上で動作
  • Hive
  • ディスクの使用料の部分はなるべく安く
    • どのようなデータを使うかは、利用直後には分からないかもしれないから
  • 解析部分で課金
• Bufferの順序は保証
  • ただし、S3などに使用するパラレルモード(2〜3個のチャンクをまとめて投入)の場合は、順序は保証されない
    • S3は書き込みレイテンシが大きい
• 認証は今のところなし
  • セキュアなサーバでの使用を前提
  • 自前でセキュアに対応するプラグインを作成できる
• APPサーバにfluentdがあれば、直接MongoDBへ書き込みはできるが、MongoDBに書きこむ前に一度集約することで、負荷の軽減
• 設定ファイルはAPPサーバ毎になので、大規模でfluentdを使うなら、Puppetなどの構成管理ツールで設定ファイルの管理が必要
  • include http://コンフィグサーバ/　の利用も検討
• Bufferサイズは制限可能
  • デフォルトは256MB
  • 超えた場合
    • ファイルサイズが超えた
      • ファイルが増える
    • キューの長さを超えた
      • 一番古いものが捨てられる
      • セカンダリという仕組みがあありそちらに
      • ログを絶対になくしたくない場合
        • 入力時にバックアップ用にローカルに保存しておくなどで対処可能
• Bufferに書きこむところのリトライ機能
  • inputプラグインの実装による
  • AWSを使う場合、EBSが死んだりした場合に起きそう

「Dive into Fluent Plugin」 Masahiro Nakagawaさん (@repeatedly)

• 柔軟なアーキテクチャ
• いかにプラグインをうまく使うか？
• プラグインの作り方
  • Rubyは1.9以上
  • MessagePackを意識して作る
  • Cool.io
    • libev
    • LoopとWatchers
  • Buffer
    • zfileは使わない方がいい。圧縮しかしない・・・？
• fluentdはmascot募集中
• 複数行を1リクエストでやりたい
  • tailプラグインのparse lineをオーバーライド。行を溜めて、溜まったら処理
• CPUの使用率を出したりする場合
  • TimeSliceを使い、60秒毎に処理が走るので、それをWriteメソッドで処理
    • 遅れて到着したものについては、それに対して時間を指定できる

「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サーバのローカルの生ログから復元
  • プラグインの問題は自分でも直せる安心感

「Distributed message stream processing on fluentd」 Tagomori Satoshiさん(@tagomoris)

• ログの変換
  • タブ区切り。HiveのLOADで読み込めるから
  • 見せたくない情報のマスクも可能
• scribelineは軽量
• scribeプロトコルは重い
• Linuxの設定は大規模なコネクションを捌けるようにはなっている
  • CentOSのデフォルトのままでは厳しい？なんともいえない