私が求めている主な要件は、複数のマシンから結合されたログを表示し、簡単な検索を実行できることです。ただし、ソリューションが (コア) システムの残りの部分に与える影響は最小限に抑えたいと考えています。リアルタイム要件はなく、プロセスは非同期でかまいません。
当初、syslog は良い選択肢のように見えましたが、syslog サーバーが停止したらどうなるでしょうか? 最悪の場合、コア システムのユーザーにエラーが表示され、最良の場合でも一部のログが失われます。
そこでいろいろ探してみるとLogstashを見つけました（http://logstash.net/）。現在の私のアイデアは次のとおりです。
- 各サーバー（システムのコアコンポーネントを実行している）にはLogstashエージェントが稼働しています。
- エージェントはログファイルを監視し、ElasticSearchクラスタに送信します。
- Logstash UIを備えた別のサーバーがあります
その方法：
- 単一障害点がない
- ESクラスタが停止しても、影響を受けるのはエージェントのみであり、アプリケーションは引き続きファイルにログを書き込みます。
- ES が戻ってきた後、エージェントは (うまくいけば) 追いついて、保留中のログをすべて送信します (Logstash はそれを実行できるほど賢いのでしょうか?)
これはうまくいくと思いますか? あるいは、別の解決策をお勧めいただけますか?
答え1
ログあなたが説明している機能の一部を備えており、プロジェクトには信頼性の高いメッセージ転送に関する豊富なドキュメント。
つまり、rsyslogでは、レルプ信頼性の高い syslog メッセージ転送のためのプロトコルを使用すると、メッセージの損失を心配する必要がなくなります。また、リモート サーバーがダウンした場合に rsyslog がメッセージをバッファリングするローカル スプール ファイルを構成するオプションもあります。リモートが復旧すると、エージェントが追いつきます。
また、rsyslog をリレーショナル データベースに書き込むように構成するオプションもあり、必要に応じてデータベースを冗長化できます (個人的には、syslog サーバーの方がクラスタ化しやすいと思います)。
答え2
この質問はトピック外として閉じられる可能性が高いので、FAQ を参照してください。
いずれにしても、syslog (または任意の syslog ベースのシステム) は問題なく動作するはずです。結局のところ、ログの損失が心配な場合は、通常の DR シナリオの一環として syslog サーバーをバックアップするようにしてください。これは非常に簡単なタスク/要求です。