uWSGI ("/var/log/uwsgi/uwsgi.log") などのアプリケーションのログを、複数のインスタンスからアクセスできるデバイスに保存し、ログをその特定のデバイスに独自のインスタンス名 dir で保存できるようにしたいと考えています。
そのため、AWS はそれを行うためのソリューションを提供しています....
uWSGI ("/var/log/uwsgi/uwsgi.log") などのアプリケーションのログを、複数のインスタンスからアクセスできるデバイスに保存し、ログをその特定のデバイスに独自のインスタンス名 dir で保存できるようにしたいと考えています。
そのため、AWS はそれを行うためのソリューションを提供しています....
ここで取るべきアプローチはいくつかあります。ファイルシステムに直接書き込むようなエクスペリエンスが必要な場合は、s3fsなどを使用して、共通の S3 バケットを各インスタンスにマウントすることを検討できます。これにより、多かれ少なかれリアルタイムのログ マージが可能になりますが、正直なところ、大量のアプリケーションでこのような設定を行うとパフォーマンスが心配になります。
ログを一定の間隔で処理して、データを共通のストアにプッシュすることができます。これはリアルタイムではありませんが、非常に単純なソリューションになる可能性があります。ここでの問題は、異なるサーバーからのログ エントリを時間順に並べる必要がある場合、ログ エントリをインターリーブするのが難しい場合があることです。
個人的には、所有しているインスタンス クラスターごとにGraylogサーバーをセットアップし、アクセス ログ、エラー ログなどをすべてログに記録します。これは UDP ベースであるため、アプリケーション サーバーの観点から言えば、ファイア アンド フォーゲットです。優れた検索/クエリ ツールも提供します。個人的には、アプリケーション サーバーからログ管理が完全に取り除かれるため、このアプローチが気に入っています。
私が使用した2つのオプション:
syslog (または Syslog-NG) を使用して、中央の場所にログを記録します。これは、AWS ログ データをオフサイトのデータセンターに発送するためです。Syslog-NG はプレーンな Syslog よりも信頼性が高く、MongoDB をバッキング ストアとして使用できます。
logrotate を使用して、ログを S3 にプッシュします。Syslog ソリューションのようにリアルタイムではありませんが、特に多数のインスタンスがあり、VPC を使用していない場合は、セットアップと管理がはるかに簡単です。
LogglyとSplunk Stormも、この問題を解決することを目的とした 2 つの興味深い SaaS 製品です。