shingo
December 25, 2017, 8:10am
1
みなさま、はじめまして。最近Elasticデビューしました。
初投稿となりますので、至らない点がございましたらご容赦ください。
<環境>
・Elastic Server (以降、ES) 6.x
・Beats (Metric、File、Packet) 6.1
・Ubuntu 16.04.2 Server(ES、Beats双方とも)
[ES] <------- [Beats]
<質問>
・ESサーバ障害時やネットワーク障害など、BeatsからESへの通信が途絶した場合、
Beatsによって収集されたMetricデータは障害復旧後に自動的に送信されますか?
・障害時、Beatsがローカルにデータを保管する期限や場所、容量等の指定は可能でしょうか?
・これらが記載されたドキュメントを見つけられませんでした。
ご存知のかた、いらっしゃいましたらご教授願います。(英語でも可)
tsgkdt
(tsgkdt)
December 25, 2017, 3:57pm
2
ESサーバ障害時やネットワーク障害など、BeatsからESへの通信が途絶した場合、
Beatsによって収集されたMetricデータは障害復旧後に自動的に送信されますか?
送信に失敗したときはリトライする設定がbeatsにはあるので、たとえばmetricbeatですとESへの通信が途絶し、
復旧したら、max_retriesによって自動的に送信されるようです。
これは、こんな感じで動作確認できるかと思います。
確認手順
ESを起動
metricbeatの起動 (max_retries: 30 )
ESを停止
1分待つ
ESを起動
4で停止していた時間内もデータが登録されてることをKibanaで確認
max_retriesについては、こちらに記載がありました。
障害時、Beatsがローカルにデータを保管する期限や場所、容量等の指定は可能でしょうか?
送信途中に落ちてしまったときのためにディスクにキューを書いておく、というPersistent queuesがLogstashにはありますが、
beatsが障害発生時にローカルファイルにデータを書き出す、という内容については私も探せませんでした。
discuss内の他の投稿で、githubからforkして作ってみるよ、という方はいらっしゃいましたが、公式にファイルに書き出す、というものは見当たりませんでした。
I'm writing a Beat to pull events from a message queue and publish them via libbeat. If an event fails to publish, I'd like to send it to a dead letter queue. However, from looking at the outputs/elasticsearch/client.go#PublishEvent implementation, I get the impression that publication failure isn't always communicated back to the beat.
Can anyone suggest the right approach for detecting and handling failures? My ultimate goal is to ensure that event data is never lost.
可用性やスケールを考慮した場合、どういう配置にするかといった点では、以下のページが参考になるかと思います。
shingo
January 10, 2018, 1:35am
3
tsgkdtさま
返信が遅くなり大変申し訳ありません。
確認手順まで用意いただき感謝いたします。
提示いただいたリンク内容を確認し、max_retriesについて理解が深まりました。
beatsが起動さえしていれば、max_retriesに基づいて良しなに再送してくれることも確認できました。
一部Filebeatなどはmax_retriesの設定が無視されるとの記載も。
今後、可用性やスケールについて検討したいと思います。
ありがとうございました。
system
(system)
Closed
February 7, 2018, 1:35am
4
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.