ログファイルの集中化-TCP経由での送信、vs SANレプリケーション？
複数のデータセンターにまたがる複数（20以上）のアプリケーションサーバーがあります。ログファイルを一元化し、単一のボックスから監視する必要があります。
要件：
- アプリケーションごとに1日あたり5〜10 Gbのオーダーの大きなログファイル-したがって、1秒あたり数千行になる可能性があります。
- レイテンシーは重要です。可能であれば、ログイベントに数秒以内に対応できる必要があります。
- パフォーマンスフットプリントは可能な限り低くする必要があり、ログファイルのサイズに応じて予測どおりに拡張する必要があります。
これらのログファイルを一元化するための最善のアプローチについて意見を聞きたいですか？
私たちが考えたアプローチの1つは、Logstash（ http://logstash.net/ ）とGraylog2（ http://graylog2.org/ ）を使用して、ログを送信することでした。ネットワークを介して、ストレートTCPまたはRabbitMQなどのバスを介して監視ボックスにイベントを送信します。
2番目のアプローチは、すべてのアプリケーションサーバーがログファイルを書き込む「共有」SANボリュームを持つことです。
上記のアプローチの長所/短所は何ですか？注意すべき注意点はありますか？ベストプラクティス？
オープンソース nxlog ツールを使用すると、LinuxおよびWindowsホストからログファイルを一元化できます。 UDP、TCP、SSLを介して転送でき、強力なフィルタリング機能、ディスクベースのバッファリング、およびその他の豊富な機能を備えています。
syslog-ng（または最新のトレンドのようにrsyslogd）を実行する集中ログサーバーをセットアップし、syslogサーバーにログを記録するようにサーバーアプリケーション/ syslogを構成するだけです。そのアプローチはクリーンであり、世界中でフィールドテストされています。
1日1アプリあたり5〜10 GBは適切ですが、syslog-ngを過負荷にするようなものではありません。いいえ、それはより多くの努力を必要とします。毎秒数千行は私が毎日仕事で見ているものであり、syslogサーバーは主にアイドル状態です。
私はsyslog-ngがとても好きです。なぜなら、それはプラグアンドプレイだからです。 Syslogサーバーを指す新しいサーバーを追加すると、syslog-ngはログファイルに必要なディレクトリ階層を自動的に作成します。sysadminは必要ありません。
Rsyslogからこのドキュメントを見てください：
http://rsyslog.com/doc/rsyslog_reliable_forwarding.html
このような設定を使用すると、メッセージをリモートsyslog（またはsyslogメッセージをリッスンできるgraylog2-server）に転送でき、リモートサーバーがダウンしている場合は、ディスク上でローカルにキューに入れられます。高負荷でgraylog2に転送する際に問題が発生しました。graylog2またはelasticsearch（graylog2はストレージに使用します）がメッセージレートに追いつかない場合、それらをメモリにキューイングします。使用可能なすべてのメモリをいっぱいにすると、ハングするまでハングします。それを殺します（すべてのメッセージを失います）。
私は1年前にLogRhythmを評価しましたが、そのサービスは本当に素晴らしかったです。彼らに見てもらいましょう。彼らは単にログを一元化するだけでなく、もっと多くのことを行うことができます。アラート、正規化、レポートなど。