「Cloudwatch input plugin」によるログの読込み状況保持/引継ぎについて

Elastic In Your Native Tongue 日本語による質問・議論はこちら
1

AWSのCloudWatchメトリクスを収集するため、
EC2インスタンス(Linux)にLogstash(7.11)をインストールし、
「Cloudwatch input plugin」を利用してメトリクスの収集を行おうとしております。

現状、Logstashサーバ2台を現用/待機構成(コールドスタンバイ)としており、
障害時に待機系に切替わった際は、待機系にはフェールオーバ以降に発生したメトリクスから収集することになります。

現用系ダウン時～待機系起動までの間のメトリクスを収集したく、
現用系にて最後に読み込んだ直後のメトリクスから、
待機系にて収集を再開したいと考えております。
上記実現にあたり、読込み状況の保持、および引継ぎをする方法をご教示いただけないでしょうか。
※「Cloudwatch input plugin」には、Sincedbのような設定が存在しないですが、
例として下記のように、「Cloudwatch input plugin」のrubyスクリプトを修正すれば
読込み状況の引継ぎが実装可能ではと考えました。
しかし、どのように修正すれば良いのかが分からず困っております。
もし、ご存じの方がいらっしゃいましたらご教示頂けませんでしょうか。

【参考rubyスクリプト】
/usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-input-cloudwatch- 2.2.4/lib/logstash/inputs/cloudwatch.rb

よろしくお願いいたします。

2

Logstash自体に、現用/待機といったクラスタの様な構成、つまりクラスタ内で状態を共有する様な仕組みがないので、

現用系ダウン時～待機系起動までの間のメトリクスを収集したく、
現用系にて最後に読み込んだ直後のメトリクスから、
待機系にて収集を再開したいと考えております。

といったことを厳密に保証する様なことは実現はできないです。これはPluginが何であれ同じことです。

Logstashの実装上、Input -> Internal Queue -> Filter/Outputとなるので、このInternal Queueに入った分のメッセージは、Logstashがクラッシュしたら消えてしまします。通常は、このInternal QueueはMemoryですが、Persistent Queueという機能でDiskに持つことで、メッセージロスを「ある程度」防ぐことは可能です。

ただし、これも1台のLogstashインスタンスにおける話で、複数台のLogstash間で状態を引き継ぐことは仕組み上出来ないです。

一つのアイデアとして、Persistent QueueのDiskを外部ストレージに持って、現用系のLogstashが落ちたら、待機系で再度そのDiskをマウントして、そこから読み出すと言うことは理論上は可能ですが、動作が保証されているもの（サポートされている使われ方）ではないです。

また、上記のInternal Queueに溜まっている量を抑えることで、障害児のロストを少なく出来ますし、逆にInternal Queueに一度に取り込む量を多くすることで、パフォーマンスの向上を図ることができますが、この辺りはLogstashの典型的なチューニング項目になります。

3

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.