ASP.NET MVCアプリケーションの集中ログソリューション（Windowsサーバー）を探しています。集中ログソリューション
私のアプリケーションはスケーラビリティがあり、ログのスケーラビリティも必要です（ログサーバは単一の障害点/ボトルネックではありません）。
これまでLogFacesを使用していましたが、このソリューションはスケーラビリティがありません。これは、単一のログサーバーを使用します。
私はlog4netをロガーとして使用し、ログをプッシュするためにアペンダーを書く（または使用する）ソリューションを探しています。
提案がありますか？
ありがとうございます！ ELMAHに Roei
ルックは、アプリごとに実行することができます素晴らしい作品、または1つのインスタンスがサーバー
上のすべてのアプリケーションをカバーするために、私は、WCFのネットを経由してリモートマシン上のMSMQメッセージキューにメッセージを送信するアペンダを持っています。 tcpバインディング。それらのメッセージをデータベースに記録するサービスが相手側にあります。
あなたがasp.netについてのみ話しているのなら、elmahはおそらくかなり良いでしょう。私の理解は、それがプラグインされ、Windowsサービスなどのより一般的なものには対処しないということです。 wcfアプリケーションについて、またはあなたがasp.netアプリケーションを超えて何かを気にしているかどうかは不明です。おそらくあなたのシステムにはそれ以上のものがあり、標準化したいと思うでしょう。また、規模について心配しているので、ロギングのためにasp.netから直接データベースにアクセスする必要があるかもしれません。私の理解は、これがエルマがすることであるということです。それを調べていないのですが、おそらく私がmsmqに示唆していることをするために拡張することができます。スケールに関して本当に気にしているのであれば、メッセージングキューイングをある方法で組み込むことができますし、wcfはそのための良いオプションです。
ありがとう、私はそれを見てみましょう！ – Roei
Spreadが請求書に適合します。ロギングサービスではありませんが、Apache Webサーバーのmod_log_spreadモジュールなど、分散ロギングにはいくつかのプロジェクトが使用されています。それはC＃available hereのクライアントを持っています。
その価値は、単純な原則にあります。ログを生成するアプリケーションは、ログの行為によって制約を受けたり、中断されてはなりません。ロギングは通常アプリケーションの第二の関心事であり、ログファイルの宛先ディスクがいっぱいになる（またはログサービスがクラッシュする）ことは、アプリケーションが失敗する本当の悪い理由です。
このレベルの分離を実現するには、ロギング「サービス」とは完全に非同期かつ独立してログできるようにアプリケーションを構築する必要があります。スプレッドは、よく理解され確立された技術、UDP /マルチキャストを使用してこれを実現します。
スプレッドを使用してログを記録すると、アプリケーションがUDP経由で「火災と忘れ」モードでログインする可能性があります。これらのマルチキャストメッセージを消費するようにSpreadデーモンが設定されていない場合、ログメッセージは永遠に消えます。しかし、ログプロデューサとコンシューマ間のデカップリングは、アプリケーションがディスクをいっぱいにするログを心配する必要はなく、TCPを使用して中央のログサーバを見つけて接続する時間を心配する必要もありません。
スプレッドはすべてのアプリケーションではありません。お使いの環境がマルチキャストをサポートしていない可能性があります（EC2が先に出ているため）、ネットワーク管理者が運用環境内のマルチキャストパケットを阻止する可能性があります。
あなたの返信ありがとう！あなたが言ったように、私はEC2上で自分の環境を走らせます - それは問題です。 – Roei
多分Windowsイベントログですか？ログへの書き込みは、方程式の半分に過ぎないことに注意してください。それを管理し、情報を報告することは、もう半分です。ログに書き込むためのコードを記述している開発者は、運用中に管理しなければならない管理者に相談したいことでしょう。彼はいくつかの洞察/好み（イベントログやデータベースなど）を持っているかもしれません。 – David