Help us understand the problem. What is going on with this article?

fluentd elasticsearch 送信と受信でログ行数に差異がある時

More than 5 years have passed since last update.

かなり、感覚的な表現で申し訳ないですが参考程度に。。。。orz

fluent plugin elasticsearch

detached forwarding server
とかゆー送信サーバでエラーが出て

retryとか勝手に何回かされると

ログが重複する。。。orz

300万行ぐらい送って、elasticsearch側では330万行ぐらいになってた。。。orz

fuluentdのバッファメモリをバッファファイルへ変更

・送信先のバッファファイルが3個以上になったら送信を待つ 
・送信元のバッファファイルが2個を超えたら処理を待つ

みたいな監視をこさてゆっくりゆっくりと送ってあげる。

送信元のfluentDのchank limitあたりを調整

300万行を90分かけて送ってあげたらドンピシャだったぜ。

【追記】
fluentDが買ってにリスタートしやがった。

しかも送信行数と受信行数にも差異が。。。リスタートでもずれる模様。。。

【追記2】
送信元のchank limitを512kで、かなり調子よく送信できた。

2500万行を10時間程度で送信完了。

受信側、送信側ともログ行数もドンピシャ!☆-(ノ゚Д゚)八(゚Д゚ )ノイエーイ

ちょっとずつの方が、早く処理できて調子よさげ。

【追記3】
送り元のchank limit 512kでも送り先のbufferファイル数が15近くになってた。

検証初期の段階でbufferファイル数が20近くなると、

detached forwarding server

が出て、errorとtryを繰り返して送信ログ数が合わなかったので

送り元のchank limit 512k → 256kに変更。

2500万行を10時間程度と、前回とほぼ同じ時間で処理完了。

受信側、送信側ともログ行数の一致を確認!☆-(ノ゚Д゚)八(゚Д゚ )ノイエーイ

送り側のbuffer数もmaxで8個とかなりいい感じ。(゚∀゚)キタコレ!!

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした