#fluentdmeetup


fluentd meetup

opening

5年間やってるよ
0.14インストールしてね
fulltimeエンジニアが二人いるのでずっと開発できる
issue報告よろ

0.12でできるようになったこと
label、tagの書き換えが不要になった
@ERROR label
filter
at most once
configuration atmost once & atleast once
ログの重複はないがエラーでなくなるかも
tcp heatbeat & dns round robin サポート
buffer queue full actionのエラーのときの振る舞い指定

buffer pressure:送り先のやばさを考慮してストップしとく
pull forward。必要なサービスがデータを取りにくる。もうtagomorisさんに開発された?
compress buffer:バッファを圧縮する。
fistributed buffer: 分散環境でレプリケーションする
service plugins:fluentdの上でパッケージのアプリを動かす。norikraとか
schema-validated logging:ログのレコードに対してスキーマ利用してバリデーション
centralized config manager:dockerの設定、起動したインスタンスの中をいじるのめんどい。git pushでイメージをばらまけるように?


v0.14 overview

new plugin api
input/outputまわり
0.12、0.10でのプラグインはほぼ動く。
ほぼ間違いなく動く予定。compatch layerがいる
バッファのデザイン変更
es、decodeのレコード転送。レコード内データでifしたい
chunkを分解する必要があった
するとchunk内のどこかで失敗すると全部リトライ

メタデータごとにchunkを保存
どっかで失敗しても
別々のchunkがふらっしゅされる
この機能はプラグイン側で対応出来る

strage helpers
プラグイン開発でリスタートしたときも
プラグインないで使えるkvs
以前保存したデータがとれる
開発者が楽になる

time with nanosecond 時間精度の向上
秒間1万レコード流れても1sにまとめられる
esでmsも対応できる
eventtimeもnsとかmsに対応出来る
書き換えなくてもintegerっぽく動くけどnsが必要な場合はプラグイン書き換え

serverengine based supervisor
rubyでサーバー作るようのフレームワーク supervisorがserverengineで動く
windows環境でも動くように。

v0.14 、あと半年でv1になる
v0.14はAPIをfixするためのバージョン。APIを壊すことはない。0.14の間にフィードバックすると治るかも

v0.10のversion configは消す ( usev1 などオプション)
detach proess も消したい

multicore processing
plugin-multiprocessでは複数supervisor -> ひとつのsupervisorで複数コアできる
counter API

secure forwardをcoreに入れる
CPU不可はちょい上昇

v0.14はtd-agent3からはいるので、td2のアップデートでは大丈夫
ruby2.3、最新版が入る
ubuntu 10.04とcentos 5 はサポート終わり

死んだchunkの一部だけリトライした場合は?
->無理。errorでroutingする。プラグインないにemit errorを仕込んでerror labelでキャッチ


server engine & windows support

@narittan

serverengine workerとserverの間をつなぐby heartbeat
workerモジュールとserverモジュール作成
モジュール内のconfigにworker数とか指定
serverではthread process spawnなどworkerタイプを指定してworkerを作成する
windowsにforkがないのでspawnでマルチプロセスを実現
めりっと:
・auto restart
heatbeatでworkerの生死を検知、自動的に再起動
・live restart
serverがworkerを
tcpが必要な場合、socketがtcpのsocketを開いている。conf読み直してtcpのsocketを生きたままshareできる
fluentdのsystem configの設定がserver engineの中に入ってる。ユーザーがいじる必要はない。
configを読みにいった時間を確認しにいき、confが新しくなってればrestart、workerを再起動せずにconfだけserverの再起動で読み直せる
・socket manager
socketのlistenが必要なときにsocketを作る
socket情報をworker側にシェアする
workerでsocketを受診、acceptする
socket managerのメリット:
将来的にmulticoreでsocket使えるようにする
全てのworkerに同じ処理ができる
・signal handler、log rotatiton
queベース
serverengineないのプロセスでログローテーションが設定できる
debugyよい細かいtraceもできる
・windows
spawnでナイスな処理

ワーカー数はtd-agent-confで設定できるようになる予定
td-agent-log multiprocessで同じloggerにかける


tagomoris

なぜ0.12からplugin用のapiを変える必要があったのか
今までのapiの問題:
developper docがない
fluentのpluginをこうやったら描けるブログを参考にするしかない
10sごとに処理するには?thread作りまくるとか。threadの起動をまってからtestが〜sleep 5s~->testがめんどくなる
outputが4種類
ユーザーがplugin内の設定よく読んで設定しないといけない
output plugin自体の設定はどこなのか、buffered pluginでも使えるのか?
あるpluginで使っていたparamが他のparamで使えるかわかんない
superでshutdownを呼んでない
buffering time sliceだと時間ごと、他のだとtagごと。まぜてできない。
bufferのコントロールは現在バイト数でしかできない
一度に遅れるレコード数しばりのある行き先とかがあるときつい
coreの処理をpluginで上書きされててつらい
fluentのrubyコードはけっこうrubyのお作法がやばい。ディレクトリ構成とか

0.12との互換性は?
0.12のプラグインは0.14で動くか?
0.14でcompatibility layerを提供。
fluent::hoge -> flunet::compat::hogeに勝手にかわる
変換、引数の場所違い、methodを動的に足して渡す、などする
動くはず。しかし
1,buffer pluginは動かない。3rdのbuffer pluginはほとんどいない
2,engine emitは無効。label routingが死ぬから。 -> router emitに書き換えてね

0.12用の設定で0.14は動くか?
自動的にパラメータを変換する何かが提供される
0.14用に作ったpluginは0.12で動くか?
無理。プラグインアップデートするときには0.14にしないとまずい

fluent/plugin/**.rb
Fluent::Pluginいかに全てのクラスが必要
fluent::plugin::baseを継承する必要がある
defaultにimplementされてるやつをoverrideしたmethodではsuperを必ず呼び出す。(今もsuperを呼ぶべきだけど)
今superが呼ばれてない場合は?互換性レイヤでsuper呼ばれてないことを検知、無理やりsuperのshutdownをcallする

class構成がすっきりする
baseの上に全部乗った形に

fluent::plugin::inputはだいたいいっしょ。もっと簡単に動く
filterはほとんど同じ
fileter streamのoverrideもあり

outputはすげー変わった
いろいろあったoutputは統合
bufferをしてからoutput、しないでoutput、両方もできる。userのconfigに合わせて変更することができるように
今まではbufferサイズベースでのbuffering
interbalベースもできる
tagごとにbufferningを分けてできる。tagごとにたまってからflush。レコードごとの吐き出しができる
時間ごとの細かい制御ができるようにした
レコードのありとあらゆるフィールドでchunkを分けられる。table名もレコードからつくれる
全部組み合わせられる

必要なmethod: 4つ。一つあればそのモードで動く
process non bufferd
write bufferd
try_write 非同期でのbuffered
format defaultではstandard formatで動く

全部実装してあったら、複雑な条件で起動モードが決まる
実装してるのがどれか1つならそのモードで動き始める
決め打ちしたいならoverride?
prefer~というmethodは動的に呼ばれる。pluginのconfigが動いたあとに変更も可能
bufferって書いて動いたらまる。だめだったら外す。みたいな設定をする。ユーザー側は

非同期なbuffering writeとは
bufferががっと溜まってた場合、全レコードが相手に受け取られたとackがくるのが確定するまで時間かかる
flushようthreadがその受け取り待ちでロックされてしまう
flushようのthread数を大きくしないとだめ。
try_writeではcommitを待たずにreturnする。送ってすぐにbufferを消さない。並列になる
commit_writeが来なかったら自動的にリトライする
データ放り込んで書き込み確認しにいってokならcommitする、もできる。
応答の悪いシステムとの連携が頑健になる

tag, time, record内のなんかのkey
default tag, time interval
time: 時間ごとにchunkを分割。
any key: たくさんあると細切れのchunkが増える

flush modeもいじれる
lazy or interval: 必要になればflush する : 時間を見る
immediate: 入ったらすぐ書き出し、失敗はすぐリトライできる

retry
何回リトライするかしかなかった + リトライする時間指定を追加。
exponential backoff:2倍ずつリトライのびるー>リトライのインターバル指定オプション追加
exponential自体も変更できるように
secondary plugin
リトライリミットを越えたらsecondary pluginに吐き出すオプション。networkでミスったらfileに書き出すなど
リトライリミットを80%が越えたらsecondary、などが指定できるように。
buffer params
chunk_limit_size
chunk_records
指定したバイト数までいったら
書き込み中のチャンクについてはディスク溢れうる
データ量を指定できるように。

chunk metadata
ファイルバッファとチャンクが対応づけされていたが、そのbufferがどう生成されたかなどのデータがmetadataとして生成される
table名を渡してmetadataを渡すとformatができてtableに送信できる、など。

other plugin types:
owned pluginsが追加。
primaryとはinput output filter
そうでないものとはcoreが直接ロードしないもの。上のplugin経由でロードされる。parserとか。
設定から直接呼び出すことはない。pluginによってownされているplugin。parserはinputに属する、など。
pluginのloggerなどを親から引き継ぐ

storage plugins
primaryに対してkvsを提供。アップデートなどのmethodを提供。
pluginないで保有したい情報がある。ex. 入ってきたevent数など。オンメモリだとrestartで消えてしまうがそれを書き出しておくなど。
jsonでディスクに吐き出す。
みんな作れる。redisやconsulに書き込んだりなど。confで設定可能に

plugin helpers
mixinをやめるために。プラグインから明示的にimportする。プラグインで使ってた面倒な機能をfluentd側で提供
helpersのdefaultがプロセス周りなどの立ち上げやtimerなどを全て包括
test driverはプラグインが走ってから動くようになる。sleep 3s とか不要に
threadのプロセス並列管理。パイプの中身を受け取ってblockで処理など。

event emitter helper, plugin strageの有効化。tcp udp tlsに対してserviceを立ち上げる

test drivers
v0.12でのformatを呼ばないなどtestとしてのヤバさをなくした。全部呼ぶ。
logにwarnが出る
outputを通ったあとにformatされたかどうか
flushができたら次のテスト、などがsleep依存でなくdriverが全部チェックしてくれる
一つイベント届いたら次にいく、などができる。中断なども。
shutdownなども細かくチェック。

0.14.xでは
multiprocess。同じbuffer pathを見ないように
pluginの雛形generator
system tag。これが必須になる

pluginガイド
移行、テスト、書き方、ユーザー用。docが充実する予定

シェアする

  • このエントリーをはてなブックマークに追加

フォローする