source: lab.git/Commentary/Fluentd/fluentd.#2.log @ 512faed

古橋
http://www.slideshare.net/treasure-data/fluentd-meetup-2
    cedec awards 2012
        fluentdで受賞
    
    self-introduction
        treasure data
            hadoop, big data
            logを入れる仕組みを誰も作っていなかった -> fluentd
            
    video
        概要
            logをjson形式で集めて蓄積する
    
    次のバージョンどうするか
    アンケート
        ログ解析に何を使っているか
            7割の方がfluentd
        保存先？
            mongdb 46%くらい
            RDBMS 40%強
    導入障壁
        検討中
        ドキュメントが不足
            英語のDocが足りない、と思っている人は？ -> 12人ぐらい
            日本語のDoc欲しい人は？ -> 4人ぐらい(ほとんど居ない)
        プラグインなど機能が少ない
        実績が…
    なぜロギングするのか
        error notify
            new reric
        performance monitor
            資源の仕様傾向をみて、あらかじめサーバを増強など
        user segment analysis
            ユーザの使用傾向
        funnnel analysis
            TOPページに来た人 -> サインアップしてくれた人はそのうち何%？
        heatmap
            時刻と曜日の二軸グラフ化
    なぜロギングにfluentdを？
        alerting / analysis / archiving で様々な使い方をする
        log sourceも様々な物がある
        log sourceと蓄積先・alalysisをどうつなげるか
            bash script? perl?
            悪魔的なスクリプトは…
            メンテナンスできる人がいなくなると困る
            スクリプト書く人と、フロントエンドを書く人が別
                期待するログのフォーマットが違う
        logrotate
            最大24h待たされる
        fluentd をhubに使えば上記の問題は解決する！
    Input / Output / buffering
        それぞれpluginになっている
    input pluginですべてjsonにする
        output pluginはjsonに対応すればよい
    logの必須3要素
        時刻
        タグ
        jsonレコード
    fluentdの特徴
        拡張可能な plugin 形式
        json という統一フォーマット
        インストールが楽
    
    plugins一覧
        DL人気順に並んでいる
    
    既存システムとの比較
        scribe
            拡張可能ではない
            統一フォーマット無い
            ....
    
    誰がfluentdを使っているのか
        slide share
        viki
        context logic
        nhn japan
        cookpad
        quora.com にどのように使われているのか、実績が書かれている
    
    fluentdの次バージョンについて
        filter pluginの導入
        <source> に filterを書けるようにする予定
        filter pluginによるpipelineが可能になる予定
        <label>
            デフォルトではマッチしない
            別のサーバでラベルを付けてからforwardされてくると、マッチするようになる
            設定ファイルは一緒だが、サーバごとに違う挙動をさせられる
    
    MessagePack for Ruby v5
    
    td-agent-lite
        in_tail = out_forward in "single" binary
    
    new process model & live restart
        現在は中央のプロセスを経由している
        
        live restart
            ログを取りこぼさずに再起動する
    
    後方互換性
        fluentd::new
        fluentd::old
        の名前空間で対応
    
    Q&A
        時刻の単位が秒なのだが、もっと細かくならないか
            ミリ秒とかが欲しい
        互換性の問題があるので、変更は難しい
        
        jsonで構造化されているのが売りだとのことだが、
            テキストベースの製品もまだある。どちらが良いのか
        Hadoopなどでパースするときに、jsonだと難しい
            ただし、ログの構造を知らない人がテキストファイルをパースするのは無駄が大きい
            なのでjsonにあらかじめ強制しておけば混乱がない
        
        日本語Docあるとうれしいので、お手伝いしたい
        オフィシャルのリポジトリ以外で、どんどん翻訳するというのはむしろ歓迎する
            どんどん広報して、力を合わせて欲しい
            公式Docと乖離してしまう問題はあるが、無いよりは全然良いので是非
        
        coolioを捨てる計画はあるか
        pluginとしては残すが、fluentd本体としてはthreadに移ろうと計画している
    
佐々木 @yssk22 with ワリ @wallyqs
http://www.slideshare.net/rakutentech/fluentd-meetup-logging-infrastructure-in-paa-s
    loggin infrastructure in PasS with fluentd
    
    Cloud Foundry (tm)
        VMware の PaaS
        ruby
        main points
            open source
            separation of concerns from IaaS
            Scalable architecture
        Easy to deploy applications
            node.js の deploy 4行くらい
        mission criticalなappはまだ難しい
            ソースをいじりながら対応しようとしている
    Cloud Foundry + Fluentd
        $ vmc target api.cloudfoundry.com
        $ ...
        $ vmc push yssk22-myapp -n
        $ ...
        $ curl http:// ...
        $ vmc logs yssk22-myapp
        アプリケーションのupdateをするとログが消えてしまう
            現在の仕様
            FileSystemが永続化されていない
            解析が不能
    
    fluentd はrubyで書かれているので、cloudfoundryのエコシステムに組み込むのは優しい
    droplet execution agent
    どのようにログを蓄積するか
        [ App -> fluentd ] -> log storage
            log storageを外に用意する
            fluentd側でファイルなどから自由にログを収集してくれるので、
            app側でどのファイルにはき出すかなどを心配しなくて良くなる
        
        [ appA -> fluentd ] -> [ another fluentd -> storage ]
                               ^
        [ appB -> fluentd ] ---^
    
    Fluentd Pros & Cons
        Pros
            Easy to include in CloudFoundry compared to other solutions
            Easy to extend
            Easy to change storage tech depending on scale
        Cons
            ....
    NATS input plugin
        adding new forwarding nodes dynamiccally through NATS
    
    github:rakutentech/dea
        https://github.com/rakutentech/dea
        https://github.com/rakutentech/dea/commit/64d271904de1e195cc90ca1958eadf704f530d94
    
    nginx + lua
        luaのloggerがあるとうれしい
    appをdeployするたびにfluentdが立ち上がる点がちょっと複雑
    
    Q&A
        ログの流量はどれくらい？
        まだまだ全然
            CloudFoundryの上で動くappの数に依存すると思われる

Q&A
    fluentという名前で最初は開始したが、既に同じ名前があったので、fluentdとした
    
    プラグインのデバッグがとても難しい、どのようにやっているのか
    test frameworkのできがとても良くない
    rspecを次バージョンで入れる予定
    input -> fluent cat or 出力に stdioを入れるなどの対応


外道父@GedowFather
http://www.slideshare.net/GedowFather/fluentd-meetup-2-fluentd
Fluentdを優しく見守る監視事例
    自己紹介
        ドリコム
        インフラエンジニア
        
    動作環境について
        IDCがいっぱいある環境
            それぞれにfluent agentが入っている
            Global IP/暗号化
            vpnは使っていない
            HDFSに保存
    プラグイン
        改造したtail コマンドでagentへ
        ローカルで保存ししつつforward
        agent -> collector -> HDFS
    collector
        test / production のログ切り分けを tagによって行っている
    Fluentd vs flume OG
        flume OG
            十分な機能(暗号化は無かったので追加した)
            Java
            agentが数百台オーダーになるとメモリ不足
            agentからのキュー再送が不安定
            -> fluentdへ
            flume NG -> 知識の引き継ぎが出来ない感じだった
        td-agentにした
            パッケージ管理は重要
            Rubyエンジニア対応できる
    ローカル監視
        必要な理由
            プロセス操作はローカルでやるべき
            サーバが社外にある場合
                サーバを調査したり、煩瑣な設定変更 -> ローカルに無いと面倒
        注意点
            ログの内容が正しいか・ちゃんと記録されているか
            td-agentがきちんと起動・動作しているのか
            HDFSへちゃんと送られているか
        監視にはmonitを使っている
            CPUやメモリ、プロセス、ポート・プロトコルで監視できる
            スクリプト実行の返値でアクション
                起動スクリプト実行、メール、etc
        monit
            td-agentの基本プロセスの監視
                td-agentは常に動作している必要がある
                    主に人災(操作ミス)対策
                    check process によるチェック
                    collectorに対しては Listen portもチェック
            td-agentの重複デーモン監視
                fluentdはtcp/udpごとに2プロセスが必要
                psコマンドによってプロセス数が2つ見つからなかったらNG
                プロセス名が ver 1.1.8 から変更になった
                unicornなどのほかのrubyプロセスを除外
                瞬間的に出てくる特権モード [td-agent] を除外
                もし重複して起動していたら
                    init.d/td-agent stop
                    pkill
                    td-agent start
                1.1.7までのtd-agentの起動スクリプトにはバグがある
                    confの内容によっては、service startの数だけプロセスが重複
                mazgi事件
                    flumeはもうオワコンなので、fluentdだ！ プラグインよろしくー
                    作ったプラグインを確認すると18/16倍くらいに増えてる
                    agent分よりHDFSが多くなっていた
                    あれ？4プロセス動いているサーバが2台有るぞ？
                    mazgi先生は濡れ衣だった
                    結論: agentが重複するとログが増える！
            flowcounterで転送状態監視
                アプリがログを記録している証明
                fluentdがログを拾って配送していること証明
                部分的な記録ミスなどは、無視
                あまりやり過ぎるとアラート対象が増える
                問題点
                    copyなので、forwardに失敗してもflowcounterのカウント記録は成功したことになっている
                    collectorやHDFSが落ちたときは考慮していない
        fluentd + monit十分な感じ
    リモート監視
        アラート・グラフ作成の集約と、状態の可視化
        特にCollectorのキャパシティ対策
        nagios + nrpe-server
        グラフはcactiとか
            cacti <- snmpd
            CPUとtrafficは必ず入れておかないと、fluentdを将来どうスケールするか読めなくなる
        一行350バイト程度・毎秒500行程度
        traffic
            圧縮でagent -> collector (10秒おき)
                0.7Mbpsくらい
            collector -> HDFS
                1.5Mbpsくらい
        CPU
            25%くらい -> 秒間2000行くらいまではいけるかなぁ
            ただし、ログのトラフィック量が変化しても、CPU負荷はあまり変化しない
                agentの数や、agentからのflush間隔でCPU負荷が変わってくる？ (要調査)
        CollectorでAgentを把握したい
            Agentは様々な環境にたくさん配置される
            Collectorの位置でまとめてAgentの状態を確認できるとうれしい
            NATだと、source addressが一つになってしまって、IPで識別は出来ない
            hostnameのprefixでグループ化？
    監視を設定することで安定した運用が望める

    Q&A
        agentの数は？
        300-400くらい
        
        VPNを張らなかった理由は？
        VPNは多様性と負荷分散性に弱い
        増やしたときにうまく分散するようにしたかった
        サーバの管理が社外に出てしまうこともあったため、そうなるとVPNは難しい
        
        圧縮・暗号化はどうやったのか
        forwardを改造した
        gzip/growfish
        
        暗号化は認証が欲しいが、どのような方法の認証が良いのか悩んでいる by 古橋

Q&A
    forwardのソースを見ると、メッセージの送り方が三つあるが？
    tag time record
        一番単純
    ？
        バッチで送る
    packed forward
        serialize/de serializeせずにforwardしたいとき
    
    公称対応限界は？
    CPUの処理能力に単純に依存している
    6万message / 8coreくらい
        forwardで受けて、flowcounterして、さらにforwardしているだけのノード
        1coreあたり8000くらい？
    次のバージョンでマルチプロセスで並列化出来るようにする予定

    forward -> UDPでkeepalive, TCP -> data connectionとなっているが、
    message数が増えてくると、UDPの方が落ちてくることがままあった
    次バージョンでheatbeatの改善を入れたい
    TCPで接続が出来たら、heatbeatと見なすようにしたい
    
    collectorでのCPU負荷とTrafficの量に関連性が薄かったが、どこがCPU負荷になっていると考えられるか
    リクエストの回数にbindするはず
    lockに処理を奪われている感じがある
    
    Windows対応はどんな感じか？ F#実装の性能は？
    ログの発生源がWindowsの場合は、td-agent-liteをWin対応にして、ログ集積はLinux
    F# -> テストは通って、実験は成功したが、ログ収集先をWindowsにしようとしているので手間取っている感じ
    
    設定ファイルをDSL化(erb)する話はどうなった？
    DSL化すると、Rubyist以外につらい
    設定ファイルは設定ファイルというままにした
        設定ファイルにプログラムを書き始めるのは負けだと思っている
    mixin プラグイン側で対応するかも
    
    設定のDSL化が欲しいパターンはあまりなさそう
    config expander
    
池田 @mikeda
http://www.slideshare.net/baguzy/fluentd-meetup-2-14073930
    fluentd & TeasureDataでこっそり始めるログ集計
    
    自己紹介
        450台くらい
    
    fluentd
        データストリームを構造化するインフラとして認識している
    
    アクセスログ
        2億/day くらい
    アプリケーションエラーログ
    メールログ(試験中)
    
    「ログとかそんなに頑張らなくても良いのでは？」
        実際どうだったか
        工数
                    ---これ以降はノートPCが電源切れたので記憶を頼りに書いている
            一人でやってもそうかからなかった(?)
            ... とs... でadmin用簡易webUIを作った
                100行＋100行くらい
                SQLっぽいクエリで結果をtableで得られる