-
- いいね！0
そのっつ (Naotoshi Seo)
@sonots
fluentd さんが、データ送れない場合はログファイル読みこまない、という処理をしてくれればいいんやで / “flunetd、forward先がダメだった時にforward元である程度ログを担保したい - さよならインターネット” http://t.co/dm46XjcSaB
2014-04-02 01:10:47
Sadayuki Furuhashi
@frsyuki
@sonots tagさえ決まれば、宛先のプラグインも決まるはず。コアのAPIにopen(tag)みたいなAPIを追加すれば、宛先のバッファサイズを取ることも可能そうな。@repeatedly
2014-04-02 01:15:51
そのっつ (Naotoshi Seo)
@sonots
@frsyuki fluent-agent-lite は送信失敗している限りは新しく読み込まないので、このあたりうまいです。
2014-04-02 01:16:20
Sadayuki Furuhashi
@frsyuki
@repeatedly @sonots フィルタがあった場合は…困るので、open(tag)じゃなくて、collect_buffer_size(tag)みたいなAPIにを追加して、連なるoutputプラグインのバッファサイズを累計する機能が必要なのかなぁ
2014-04-02 01:17:39
そのっつ (Naotoshi Seo)
@sonots
@repeatedly @frsyuki フィルタあると難しいので、in_tail_forward みたいながっしゃんこしたプラグインを作るしかないかな、とか思ってました
2014-04-02 01:18:06
Sadayuki Furuhashi
@frsyuki
@sonots @repeatedly がっしゃんこプラグインを作るならfluent-agent-liteでいいような気がしますが、fluentdプラグインになっていると便利なことがあります？
2014-04-02 01:18:39
そのっつ (Naotoshi Seo)
@sonots
@frsyuki @repeatedly in_tail の機能豊富さは魅力的ですねぇ。fluent-agent-lite は position を覚える機能もないので。
2014-04-02 01:19:41
そのっつ (Naotoshi Seo)
@sonots
がっしゃんこしちゃうと、out_copy して２重に送信、とかできなくなっちゃうな。その辺のプラグインエコシステムを使いつつうまくやろうとすると、やはり大変そうだ
2014-04-02 01:24:12
Sadayuki Furuhashi
@frsyuki
@sonots @repeatedly あー確かに構造的に無理ですね。buf_fileに溜めておくのはダメなんでしたっけ？
2014-04-02 01:25:09
tagomoris
@tagomoris
シンプルな構造だから達成可能な利点というものと、ある程度の複雑さを備えることによる利点というのは基本的に相反するので、グレートな落とし所か一発逆転アイデアを思い付かない限りは妙な中間地点を狙うのは損することが多い
2014-04-02 01:28:40
tagomoris
@tagomoris
ので、思い切って超シンプルか超高機能に振ることが多くて、fluent-agent-liteは前者、norikraは後者
2014-04-02 01:29:16
そのっつ (Naotoshi Seo)
@sonots
@frsyuki @repeatedly out_forward で buf_file を使うとディスク書き込みの分遅くなったりしないんでしょうか？いつもは buf_memory で、queue 溢れたら溢れた分は buf_file する、とかしてくれるならよさそう
2014-04-02 01:31:19
Sadayuki Furuhashi
@frsyuki
@sonots @repeatedly ディスクIOがボトルネックになっている環境なら遅くなりますが、だいたいCPUの方が遅い気がします。queue溢れたらfileに落ちるバッファは、良いですね。
2014-04-02 01:30:59