fluentdmeetup2016summerにいってきた

いってきたので備忘録です。誤字すみません。

http://eventdots.jp/event/588701

#fluentdmeetup

---------------------------

fluentdの昔と未来の話

ふるはしさん

5年目。ずっとアクティブに開発が続いている。

トレジャーデータの２人がフルタイムコミッタでもりあがってる

0.14が昨日リリースされた
Fluentd v0.14.0 has been released | Fluentd
バグがあるかもしれないので使ってみてissue登録してね！
lavel機能、tagのかきかえ
tagかきかえやってしまうと設定ファイルの構造がみにくくなるのでlavelをつかいましょう
エラー処理も書きやすくなっている
タグの書き換えをしなくていい
特定のラベルにたいしてフィルタプラグイン
forwardプラグイン
at-most-once、重複はおきないけどなくなる可能性があったが柔軟に
届いた応答がくるまでバッファをフラッシュしない
ハートビートがtcpで
ラウンドロビンのサポートができるように！
fluentd-uiでwebから設定
デフォルト値、例外の動作

信頼性の高いシステムにどんどんなっているのではと

未来の話

バックプレッシャー
バッファリングによってネットワークの負荷を克服できる
pubsub＆pull forward　自らとりにいくスタイル
バッファを圧縮する
バッファを分散環境で分割して保存できるといいかも(カフカ？
サービスプラグイン、in-monitor-agent、上にのせるやつはハックするしかないがそれをタグとかで設定するだけでサービスが上がるようにするとか（サーバ指定できるエージェントならよさそう？)
スキーマをバリデーションしたやつだけ送る機能とか（フィルタプラグインかも
分散環境で一か所で管理したい（Dockerとかでうれしいかも

ロゴ、新しいのがでるらしいよ（色がわかりやすくて見やすいかも

ruby withグランプリでロゴがならんだときの見栄えで文字と一体化してたらしい

------------------------------

なかがわさん

v0.14Overview

きのう出ました。3日前にデッドロックをみつけたけどなおした。

あたらしいプラグイン

ナノ秒対応
win対応

バッファとアウトプットバッファのパフォーマンス改善など
APIたしたり削ったり、刷新したので互換性がない

0.12からなら動くはず。Compatibleレイヤーがあるため。
タグベースでChunkを保存していた。たいていのケースでうまくいくがelasticsearchつかってる勢、いままではOutput時のリトライに問題があった。指定したタグやキー毎にflushするようになる。プラグインの対応が必要なのでCompatibleレイヤーはつかえないのでいずれ対応しようとしている
Plugin Strage & Helpers
nano秒対応、keeptimekey、とかめんどくさいことをしていた。最近はnano秒のとこがおおいのでミリ秒じゃなくてナノ秒対応しようということになった
ServerEngineというのに置き換わる、プロセスマネージが安定するし使いやすくなる。これのおかげでwindowsでもうごくようになった。なんともうすでに動かしてる会社がある模様。
signalでkillコマンドでバッファフラッシュしてたがhttpRPCでいけるようになる模様

入れられなかった機能のはなし

issuesの1000になんっかのこってるらしい

https://github.com/fluent/fluentd/issues/1000

v1になるまえまでにプラグインのフィードバックをおねがいしますとのこと。
detach_processの機能は消したいらしい
マルチプロセス

　　　マルチコアの機能を使うことができるやつ

　　　立てたぶんだけポートを分ける必要があった

　　　スーパバイザをサービスマネジャにおきかえたのでワーカだけ処理を分けることでフィルタとかアウトプットを高速にできる

　　　multiprocessのプラグイン使っている人は幸せになれる

CounterAPI統計がとれる
secure-forwardがコアに入る！めんどかった使い分けがいらなくなる
CPUの使用率が若干上がる

　　　　ベンチの結果として、in_tailのパースでいろいろとられるのでnoneでベンチしたけっか、4%ほど使用率があがる

　　　　in_forwardはかわってないのでかわらない

　　　　tdlogと組み合わせでちょっとあがる

　　　　optimizeはしていく予定でこうご期待

パッケージのtd-agentは3になる
Rubyを2.3にしないとつかえない（パッケージ版はってことかな？）
msi（winついかよてい
Cent5とUbuntu10.04をサポートからはずす
パッケージのrelese日はまだ未定

バッファのチャンクのスライドもう一回みたい

エラーストリーム、Routerというとこにえみっとエラーでローカルのファイルに落としといて解析してからリトライしたほうが安全らしい

---------------------------------------

なりたさん

サーバエンジンとWindowsの話

ServerEngineの導入がv0.14から

とはなにか

robustなマルチプロセスエンジンを導入

サーバモジュールとワーカモジュールの２つをあつかい簡単に実装できる

spawn機能でマルチプロセスを実装してる（winにthread機能がないから）

Auto restart機能、意図せずにworkerが死んだときに検知して走らせる機能

デモがわかりやすい

Live restart

ゼロダウンタイムでリスタートできる

sendSIGUP、tcpソケットがサーバ側であらかじめ開いて共有する

ログレベルをinfoからtraceにしてデモ

winにはSIGUPがないのでhttpRPCを使ってlive restart要求を送る

/api/process.intrrupts....

systemconfig reload

　定期で動的に見に行って動的にrelaedするとか。夢のよう。

SocketManager、ソケットのやりとりのはなし

簡単にマルチコアを使うことができるもの。

ワーカーの数を設定できるようになる予定

signal handler

シグナル同士の競合をキューで管理してふせぐものらしい

easer log rotation

マルチプロセスでログローテーションをできる機能

デバッグよりさらに細かいtraceをできる

winだと機能が置き換わってる

-----------------------------------

たごもりさん

Fluentd v0.14.0 をリリースした & Fluentd meetup 2016 Summer をやってしゃべってきた - たごもりすメモ

なぜfluentdは新しいAPIのセットをもたないといけないのか

いままでの問題：

　ドキュメントがない

　古いブログにかきちらしたやつがしんじられてる

　プラグインの仕事じゃないやつをプラグイン内でやっててテストが複雑になる

　そのせいでプラグインのテストが失敗するのでテストにsleepいれてテストに時間がかかる問題

　ユーザが考えてつかわないといけない、大変わかりにくい

　inputとoutputの設定がmatchにまるごと混ざっているのでどれがどのプラグインの設定かわからない

　あるプラグインの設定が別のプラグインで使えるかどうかわかｒない

　shutdownというメソッド、だれもsupoerで呼んでない、よくfuentd終了できてるなと思う

　タグごと、、

　バッファはどういうタイミングでflueshして最終的な目的地にかきだすかをいまバイト単位でしかできない

　同期的なバッファのフラッシュができない

　rubyのコードでできることは何でもやっていいんだなというサバンナ状態

　コアの大事な処理をプラグインで上書きしててだめ

　fluenedのコードはrubyのダメなコードのあつまりでまねされて自由すぎる、グローバルな定数がいっぱいあるとか

　なんとか統制のきく状態にしたいついでに便利な機能を提供して移行がすすむようにしたい

設定ファイルに対する互換性のはなし

0.12対応してるプラグインがCompatレイヤで自動的にネームスペースが変換される。足らないメソッドが自動で追加されたりする

バッファプラグインは動かない

　世界中に4人くらいしかいないはずなので切った

テストコードも独自すぎると動かない

Engine emitはラベルでのルーティングが動かないので無効になる

いままでの設定ファイルは？

ファイルプラグインは0.14にしてないけどすることになっても、

bufferというタグが増えるっぽい

v0.14のAPIつかえるように書いたものは0.12でつかえない

クラス構造のはなし

fluent/plugin/*.rb(in gems)

Fluent::Plugin::のしたに暮らすをおく

すべてのプラグインはFluent::Plugin::Baseのサブクラスでなければならない

メソッドを上書きするときは必ずsuperを置いてね！とのこと

まだコアのプラグインでもワーニングが出る状態らしい

クラスのヒエラルキーの図の解説が。

サードパーティプラグイン作る人用。

便利なブロックを引き出してきて使えるように。

filterプラグインはほんとんどなにも変わってない

Outputプラグインの話

ものすごくいろいろ変わった

バッファリングしないする、両方いけるのをかけるようになった

何をベースにバッファリングを変えるかを選択がふえた

レコード数でflueshできる

1分とか1時間はできたけど15分とかはできなかったができるようになったtimekey

ありとあらゆるフィールドでチャンクをわけられるようになった

DelayedCommit

相手がキチンとうけとったのを返してもらうモード

いまだとnum_threadsを増やすひつようがある、ackをまってるだけで。

非同期化することでcommitをまたずにリターンしちゃう

writeメソッドいっかいかえしちゃうとチャンクがけされてたけど

try_writeの場合はけされない、commit_writeが帰ってきてはじめて消される

commit_writeがあるていど帰ってこなければretryする

これで並列度をあげる（すげーうれしい。これ。

分散ファイルシステムかいたあとすぐよめないとかの場合

jobキュープラグインとかいいかも

応答性の悪いシステムと連携するときに便利な機能

ここでPCの電源が落ちたので録音に切り替え（たごもりさんがビールでいい気分になる手前くらい）

ここからの書き起こしは待て後日ということで大変申し訳ありません。

6/7追記：

細切れのチャンクがたくさんできるとアレなのでwarningだしたほうがいいかも？。

なにもしないとbufferd_outputとおなじ、タグだけ指定するとobject_bufferd_outputとおなじ、timeだけしていするとおおむね今までのtime_slice_outputとおなじ。これを一つのプラグインによって設定で全部つかえるということ。

チャンクがフラッシュされるモード、flush_modeをlagyとintervalとimmediate、隠しパラメータのdefaultがあってchunk_keyの指定で挙動が変化する。bufferd_outputと整合性をとったせいで存在。lazyだとflush_intervalをみないモード、intervalがflush_intervalをみてそのとおりflushする、immediateはレコードが入った瞬間にflushする。すぐにかきたいんだけど何かおきたときはリトライする。今まではflush_interval 0とかで実装されていた。

そのほかにflsh_interval、dilayed_commit_timeoutを指定するとこの間かえってこなかったらリトライする。ユーザが制御可能。

ビールタイム。

リトライとsecondory_plushgin

リトライのタイムアウトを設定できるようになったretry_limitより優先するパラメータ。

5時間たったらリトライをあきらめる等の設定

いままでのretry_limitは17回で17回たつと72時間経過していることになる。わかりにくいので時間を指定できるようにした。

いままでエクスポーネンシャルバックオフというものだけだった、リトライ事に2倍の間隔にするもの。

それだけだと扱いにくいケースがあるのでぺリオディックを導入、3分だったら3分毎にリトライするというもの。

奇数と乗数を指定できるパラメータもあるのでエクスポーネンシャルバックオフマニアの方は設定すればいいだそうで（いらなさそう）

セカンダリプラグイン：リトライリミット到達したら書き出す先のファイル。これはけっこう危険でfluentdのバッファには標準フォーマットがないので一つのプラグインで読み出せたものがほかのプラグインで読み出せるとは限らない。いままではやらないよりはましで当たるも八卦当たらぬも八卦だった。セカンダリに書き出すのに失敗するとretryをくりかえすいつまで続くのかわからない。そうではなくてretry_timeoutの80%いったらセカンダリに書き出すということにする

total_limit_size、baffer_limit_sizeと対になるもの。全体でこの指定したバイト数までいったらいっぱいになる。いままではbuffer_queue_limitだと掛け算しないとサイズがわからないのとキューに入ってない書き込まれてる最中のチャンクが考慮されてないのでディスクギリギリに指定してるとあふれると大変なことに。トラブル事例は聞いたことがないけど本当に大丈夫なのか心配。なのでtotal_limit_sizeで書き込み中のチャンクも含めたリミットを指定することで安心。一応互換性のためにqueue_length_limitというのがありキューに入っている長さでも指定可能。

チャンクのメタデータというのがあってそのバッファチャンクに何が入っているのかを持つためのデータ構造。ファイルバッファを使うと今まではファイルバッファのチャンクひとつにつき1ファイルあったがその１ファイルにプラスして.metaというファイルができる。そのなかにどういう単位でバッファのチャンクを処理しているかいつ作られたなどなどが書かれる。プラグインのAPI上どうみえるか、writeメソッドに渡ってくるchunkというオブジェクトに今まで無かったメタデータというメソッドが生えてて中身がみれるが普通は意識する必要は無く、意識するとしたらテーブル名に任意の情報を埋めたいときにextract_press_holders?というのがoutputプラグインに生えていてそれにformattingをやりたいデータを持ってるメソッドとformatingのchunkのmetadataを渡すと、formattingが自動的に行われて、文字列が入るのでそれをつかってDBインサートを行うなど。（おっそいコードらしいので乱用しないようにとのこと）

コアじゃないownedプラグインはコアのinputとかoutputプラグイン経由で呼ばれるらしい。他のプラグインにたいして所属するプラグインのこと。親プラグインからloggerとかpluginidを引き継ぐなど。パーサプラグインはinputプラグインで指定した情報をつかってtypeとか親から引き継ぐなど。親で書いといたバッファ関連の設定などを引き継いだり。

プラグイン側で持っておきたい情報をディスクに書いたりするのがストレージプラグイン。localの指定した場所にjsonで吐き出すが、プラガブルなので誰かがプラグインを書けばredisに渡したりも可能とのこと。

便利メソッド集、pluginhelpersはmixinのかわりにつくったもの。プロセスをフォークしてごにょごにょとかをプラグイン側でやらなくてすむようによく使われる機能をfluentd側で提供するもの。スレッドだとかタイマーだとか。テストドライバーのおかげでsleep入れる必要が無くなった。

イベントエミッターというもの、outputプラグインでは無効の状態。。プラグイン開発者向けのテストドライバとかの話はちょっと割愛。

マルチプロセスはバッファパスがかぶるとダメ等の対策など準備がととのったらバージョン0.14のどっかでリリースするそうです。

バッファの圧縮を入れるつもりだそう。あとプラグインのジェネレータをつくると。ないとみんなどっかのプラグインをまねするので教育によくないそうで。systemというセクションを書くと色々設定できるらしい。マルチプロセスモデルでほぼ必須になるらしい。そこに一箇所バッファパスのディレクトリを指定しておくと自動的に引き継がれてほかに書かなくて良くなる機能。fluentd全体でバッファをいくつまで入れられるか指定する機能も入れたい。CounterAPIというのがあって、ストレージプラグインに似てるけどちょっと違って、ストレージプラグインと同じようにkeyとvalueがありただしvalueは数値だけ。それを増やしたり減らしたりするだけのもので、fluentdがマルチプロセスだとか複数台にまたがったりしたときに全体の流量をとりたいだとか全体の何かのリソースの制御をしたいケース用のAPI。0.14の安定版、来年の早いうちに出せるといいな。プラグインの移行ガイドとかテストガイドとかを書こうと思ってはいるとのこと。

互換性レイヤは用意してあるので今すぐverupというよりはちょっとお待ちくださいとのこと。まず開発者向けドキュメントから書きますとのこと。プルリクはmasterに送ってねだそうです。

まあ他の人が書いたブログやハッシュタグを追うとかもおすすめします。

プラグイン開発者向けの話が多かったです。

#fluentdmeetup

https://twitter.com/search?q=%23fluentdmeetup&src=typd

Fluentd Meetup 2016 Summer レポート〜 v0.14 の新機能からプラグイン開発者向け API まで - 無印吉澤

とりあえず、必要になる対応は以下がありそうかと思いました。

・Cent7にしてruby2.3いれる（独自PATHでパッケージ同梱ならrubyの対応は不要そう）

・td-agent3いれる

・根本的なconfigの修正（プラグインごとにブロックつかいわけるかんじ？）

・tagやめてlabelつかう

・elasticsearchプラグインが更新されるのをまってバージョンアップ