一元化されたロギングのベストプラクティスは何ですか？
私のチームは100以上のアプリケーションのサポートを継承しています。アプリケーションには一般的なアーキテクチャがないため、ロギングを行うアプリケーションは通常、ローカルファイルまたはローカルデータベースへのカスタムコードを使用してロギングを行い、すべて管理されていません。それを変えたい。
アプリケーションを徐々にlog4netの使用に移行し、ログに記録されるものの種類を標準化しています。次の質問は次のようになります：ログをどこに送信すればよいですか？
すべてのログの受信専用の中央SQLServerを使用すると、メンテナンスが簡単になり（バックアップ/アーカイブ用に1つの場所）、将来的にデータマイニングや傾向分析が可能になると考えていました。
これはこの種のベストプラクティスですか、それとも代わりに検討する必要のある専用のアプリケーションロギングサーバーがありますか？
更新： log4netとSQLServerについてさりげなく言及するよりも、もっと明確にすべきでした。私たちはMicrosoftの家であり、ほとんどのものが.NETで書かれています。 UNIXソリューションは私たちにとって良くありません。
注意すべき1つの世界：大規模なショップの100以上のアプリで、数百、おそらく数千のホストがそれらのアプリを実行している場合、緊密な結合を引き起こすものを避けてください。アプリケーションのログはログリポジトリの可用性に依存するため、これにより、SQLServerまたは任意のデータベースソリューションへの直接接続がほぼ除外されます。
中央リポジトリの可用性は、通常最も興味深いイベントであるため、「接続できない場合はログに記録しない」よりも少し複雑です。物事がスムーズに進むときではなく、問題があるときに発生します。物事が面白くなったときにログがエントリを正確に削除した場合、インシデントの解決が信頼されることはなく、そのため、他の利害関係者（つまり、アプリケーション所有者）の牽引力とサポートを得ることができません。
保持を実装し、失敗したログ情報の配信を自分で再試行できると判断した場合、困難な戦いに直面しています。これは簡単な作業ではなく、効率的で信頼性の高いものから始めて、思ったよりもはるかに複雑です。保持された情報を保存し、適切な再試行とインテリジェントなフォールバックロジックを導入して終了します。
また、認証とセキュリティの問題に対する答えも必要です。大規模な組織にはさまざまな信頼関係を持つ複数のドメインがあり、従業員は自宅からVPNまたはダイレクトアクセスを介してベンチャーします。一部のアプリケーションは無人で実行され、一部のサービスはローカルユーザーとして実行するように構成され、一部のマシンはドメインに参加していません。各アプリケーションのロギングモジュールは、どこにでも展開され、中央リポジトリで認証されるのか（そして、どのような状況がサポートされなくなるのか）という質問への回答です。
理想的には、ロギングモジュールにすぐに使用できる配信メカニズムを使用します。 MSMQはおそらく最も適切な適合です：すべてのWindowsホストで利用可能な堅牢な非同期の信頼性の高い配信（少なくともほとんどのユースケースの範囲で）インストール時（オプション）。これが大きな問題点です。アプリケーションはデフォルト以外のOSコンポーネントに依存します。
中央リポジトリストレージは、要求された情報を配信できる必要があります。おそらく次のようになります。
- インシデントを調査するアプリケーション開発者
- 顧客の苦情によって報告された失われたトランザクションを調査するカスタマーサポートチーム
- フォレンジックを行うセキュリティ組織
- 統計、傾向、集約情報（BI）を要求するビジネスマネージャー。
深刻な組織（サイズ、存続期間）にこれを提供できる唯一のストレージはリレーショナルエンジンであるため、おそらくSQLServerです。テキストファイルに対して分析を行うことは、実際には距離を置くつもりはありません。
したがって、メッセージングベースのログ転送/配信（MSMQ）とリレーショナル中央リポジトリ（SQL Server）をお勧めします。おそらく、その上にanaalitycalコンポーネント（Analysis Services Data Mining）があります。ご覧のとおり、これは明らかに小さな偉業ではなく、log4netの構成だけではありません。
何を記録するかについては、あなたはすでに考えていると言いますが、私は私の余分な2cでチャイムを鳴らしたいと思います。多くの場合、特にインシデント調査では、追加情報を要求する機能が必要になります。これは、インシデントマシンからの特定のファイルの内容、いくつかのレジストリキー、いくつかのパフォーマンスカウンター値、または完全なプロセスダンプを知りたいことを意味します。中央リポジトリインターフェイスからこの情報を要求できることは非常に便利ですが、必要な場合に備えて、常にこの情報を収集することは現実的ではありません。これは、アプリケーションと中央リポジトリの間に何らかの双方向通信が必要であることを意味します。アプリケーションがインシデントを報告すると、追加情報（たとえば、障害のあるプロセスのダンプ）を追加するように要求できます。アプリケーションロギングと中央リポジトリの間のプロトコルから、インシデントの繰り返しを認識する中央リポジトリの機能、収集するlogginライブラリの容量まで、このようなことが発生するためには、多くのインフラストラクチャが整っている必要があります。必要な追加情報、特に次の発生時に追加情報が必要であるとインシデントをマークするオペレーターの能力。
この答えは今のところやり過ぎのように思われるかもしれませんが、私はかなり長い間この問題の領域に関与していました。MSにいた当時、ワトソン博士からのオンラインクラッシュレポートをたくさん見ていました。これらの要件が存在することを伝えてください。これらは有効な懸念事項であり、実装するとソリューションは非常に役立ちます。最終的には、測定できないものを修正することはできません。大規模な組織は、ロギングや監査など、アプリケーションストックの適切な管理と監視に依存しています。
ソリューションを提供するサードパーティベンダーがいくつかあり、log4netと統合されているものもあります。たとえば、 bugcollect.com （完全な開示：それは私自身の会社です）、 Error Traffic Controller または- Exceptioneer およびその他。
Logstash + Elasticsearch + Kibana + RedisまたはRabbitMQ + NLogまたはLog4net
ストレージ+検索と分析： Elasticsearch
収集と解析： Logstash
視覚化： Kibana
Queue＆Buffer： Redis
アプリケーション内：NLog
これまでに述べた1024バイトのSyslogメッセージの長さの制限は誤解を招きやすく、Syslogベースの問題の解決策に対して誤ったバイアスをかけています。
obsolete「BSDSyslogProtocol」の制限は確かに1024バイトです。
BSD Syslogプロトコル-4.1 Syslogメッセージパーツ
modern "Syslog Protocol"の制限は実装に依存しますが、少なくとも480バイトである必要があり、少なくとも2048バイトである必要があり、偶数である可能性がありますより高い。
例として、Rsyslogの構成設定はMaxMessageSizeと呼ばれ、ドキュメントでは少なくとも64kbまで設定できることが示唆されています。
質問者の組織が「UNIXソリューションは良くない」「マイクロソフトの家」であるということは、差別の少ない読者が正確な情報を得るのを妨げるべきではありません。
SQLは機能しますが、ログを集約するために Splunk を使用しました。 Splunkでデータにインデックスを設定し、クエリツールを使用して素敵なグラフを作成する方法に基づいて、驚くべき情報を見つけることができました。基本バージョンも無料でダウンロードできます。
他の回答が指摘しているように、業界標準に最も近いのは syslog です。しかし、あなたはWindowsの世界に住んでいるので、絶望しないでください。 KiwiにはWindows上で実行されるsyslogdaemaonがあり、無料です。 詳細 。
更新
@ MichaelFreidgeimが指摘しているように、Kiwiはsyslogデーモンの料金を請求するようになりました。ただし、他にも無料の代替手段があります。これ other SO answer それらのいくつかにリンクしています。
他の人がすでに指摘しているように、アプリやホストの規模からデータベースに直接ログを送信することはお勧めできません。専用の集中ログサーバーを使用することを支持して、もう1つの利点を追加したかっただけです。それは、ログインフラストラクチャからアプリを分離することです。 .Netを使用しているので、いくつかの適切な選択肢があります log4net および NLog 。どちらも非常に優れた製品ですが、私は特にNLogが好きです。これは、負荷が大きいほどパフォーマンスが高く、構成オプションがはるかに優れており、積極的に保守されていることがわかりました。私の知る限り、Log4Netは数年間変更されておらず、いくつかの問題がありますが、それでも非常に堅牢なソリューションです。したがって、このようなフレームワークを使用すると、ログを集中型サーバーに送信する方法、内容、タイミングをアプリレベルで制御できます。あったとしても。
logFaces をご覧ください。これは、説明する状況のために特別に構築されたもので、分析と監視のための集中ストレージとソースを提供するアプリとホストの規模からログを集約します。そして、既存のコードベースを変更せずに、これらすべてを邪魔にならないように実行します。大量のアプリとホストを処理し、データをどのように処理するかを指定できます。一方、リアルタイムで監視したり、データを掘り下げたりするための 非常に優れたGUI があります。データベースを直接扱う必要はまったくありません。 SQLとNoSQLの両方から選択できるデータベースはたくさんあります。ところで、RDBSは、非常に大規模なデータストアで最高のパフォーマンスを発揮するわけではありません。 logFacesは MongoDB で動作します-このセットアップは通常、最高の従来のRDBSブランドを10倍ほど上回っています。特に、上限のあるコレクションで使用する場合。
（開示のために、私はlogFacesの作者です）
ローカルのEventViewerへのlog4netログがある場合は、Windows 2008ボックスでこれらのログをマイニングできます。これを参照してください 集中監査の記事 。
そのボックスで、これらのイベントを簡単にインポートし、その上にいくつかの管理ツールとマイニングツールを提供できます。
* nixマシンで実行している場合、従来のソリューションは syslog です。