25

私のチームは 100 以上のアプリケーションのサポートを継承しています。アプリケーションには共通のアーキテクチャがまったくないため、ログを記録するアプリケーションは通常、カスタム コードを使用してローカル ファイルまたはローカル データベースに記録し、すべて管理されていません。私たちはそれを変えたいと思っています。

アプリケーションを log4net を使用するようにゆっくりと移行し、ログに記録されるものの種類を標準化しています。次の質問は、ログをどこに送信する必要があるかということです。

私は、すべてのログを受信する専用の中央 SQL Server を使用するのが良いと考えていました。これにより、メンテナンスが容易になり (バックアップ/アーカイブ用の 1 つの場所)、データ マイニングとトレンド分析の将来の可能性が提供されます。

それはこの種のベスト プラクティスですか、それとも代わりに検討すべき専用のアプリケーション ログ サーバーがありますか?

更新: log4net と SQL Server についてさりげなく言及するよりも、もっと明確にする必要がありました。UNIX ソリューションは私たちにとって役に立ちません。

4

9 に答える 9

23

1 つの注意事項: 大きなショップで 100 以上のアプリがあり、それらのアプリを実行するホストが数百から数千に上る場合は、密結合を誘発するものを避けてください。アプリケーションのログ記録はログ リポジトリの可用性に依存するため、SQL Server やその他のデータベース ソリューションに直接接続することはほぼ不可能です。

中央リポジトリの可用性は、単に「接続できない場合はログに記録しない」よりも少し複雑です。通常、最も興味深いイベントは、物事がスムーズに進んだときではなく、問題が発生したときに発生するためです。興味深いことが起こったときにロギングがエントリを削除すると、インシデントを解決するために信頼されなくなり、他の利害関係者 (つまり、アプリケーション所有者) の牽引力とサポートを得ることができなくなります。
保持を実装し、失敗したログ情報の配信を自分で再試行できると判断した場合、困難な戦いに直面していることになります。これは簡単な作業ではなく、保持された情報の効率的で信頼性の高いストレージから始めて、思ったよりもはるかに複雑です。最後に、適切な再試行とインテリジェントなフォールバック ロジックを導入します。

また、認証とセキュリティの問題に対する答えも必要です。大規模な組織には、さまざまな信頼関係を持つ複数のドメインがあり、従業員は自宅から VPN またはダイレクト アクセス経由で侵入し、一部のアプリケーションは無人で実行され、一部のサービスはローカル ユーザーとして実行するように構成され、一部のマシンはドメインに参加していません。各アプリケーションのロギング モジュールがどのようにデプロイされ、中央リポジトリで認証されるのか (およびどのような状況がサポートされないのか) という質問への回答です。

ロギング モジュールには、すぐに使用できる配信メカニズムを使用するのが理想的です。MSMQ はおそらく最も適しています。堅牢な非同期の信頼性の高い配信 (少なくともほとんどのユース ケースの範囲で)がインストールされている場合は、すべての Windows ホストで利用できます(オプション)。アプリケーションがデフォルト以外の OS コンポーネントに依存することが主な問題点です。

中央リポジトリ ストレージは、要求された情報を配信できなければなりません。たとえば、次のようになります。

  • インシデントを調査するアプリケーション開発者
  • 顧客の苦情によって報告された失われたトランザクションを調査する顧客サポート チーム
  • フォレンジックを行うセキュリティ組織
  • 統計、トレンド、および集約情報 (BI) を要求するビジネス マネージャー。

重要な組織 (サイズ、有効期間) にこれを提供できる唯一のストレージはリレーショナル エンジンです。したがって、おそらく SQL Server です。テキスト ファイルに対して分析を行うだけでは、実際にはうまくいきません。

したがって、メッセージング ベースのログ転送/配信 (MSMQ) とリレーショナル セントラル リポジトリ (SQL Server) をお勧めします。その上におそらく分析コンポーネント (Analysis Services Data Mining) があります。ご覧のとおり、これは明らかに簡単な作業ではなく、単に log4net を構成するだけではありません。

何をログに記録するかについては、すでに考えているとおっしゃっていますが、追加の 2c を追加したいと思います。多くの場合、特にインシデントの調査では、追加情報を要求する機能が必要です。これは、インシデント マシンの特定のファイル コンテンツ、レジストリ キー、パフォーマンス カウンター値、または完全なプロセス ダンプを知りたいということを意味します。中央リポジトリ インターフェイスからこの情報を要求できることは非常に便利ですが、必要な場合に備えて常にこの情報を収集することは実際的ではありません。これは、アプリケーションと中央リポジトリの間にある種の双方向通信が必要であることを意味します。アプリケーションがインシデントを報告すると、追加情報 (障害のあるプロセスのダンプなど) を追加するように求められる可能性があります。

この答えは現時点ではやり過ぎのように思えるかもしれませんが、私はかなり長い間この問題の領域に関わっていました。これらの要件が存在し、有効な懸念事項であり、実装するとソリューションが非常に役立つことがわかります。最終的に、測定できないものを修正することはできません。大規模な組織は、ロギングや監査など、アプリケーション ストックの適切な管理と監視に依存しています。

ソリューションを提供するサード パーティ ベンダーがいくつかあり、log4net と統合されているものもあります。たとえば、bugcollect.com (完全な開示: それは私の会社です)、Error Traffic ControllerまたはExceptioneerなどです。

于 2009-11-18T22:37:08.490 に答える
9

Logstash + Elasticsearch + Kibana + Redis または RabbitMQ + NLog または Log4net

Storage + Search & Analytics: Elasticsearch
Collecting & Parsing: Logstash
Visualize: Kibana
Queue&Buffer: Redis
In Application: NLog

于 2013-10-03T12:29:46.590 に答える
5

これまでに述べた 1024 バイトの Syslog メッセージの長さの制限は誤解を招くものであり、問​​題に対する Syslog ベースのソリューションに対して誤ってバイアスをかけています。

廃止された「BSD Syslog プロトコル」の制限は、実際には 1024 バイトです。

BSD syslog プロトコル - 4.1 syslog メッセージの部分

最新の「Syslog プロトコル」の制限は実装に依存しますが、少なくとも 480 バイトである必要があり、少なくとも 2048 バイトである必要があり、さらに高くすることもできます。

BSD syslog プロトコル - 6.1。メッセージの長さ

例として、Rsyslog の構成設定は と呼ばれMaxMessageSize、ドキュメントでは、少なくとも 64kb に設定できることが示唆されています。

rsyslog - 設定ディレクティブ

質問者の組織が「UNIX ソリューションは役に立たない」「Microsoft ハウス」であることは、それほど差別的でない読者が正確な情報を得るのを妨げるべきではありません。

于 2013-11-15T00:40:34.967 に答える
1

Unix にはsyslogがあります。
また、こちらのケース スタディもご覧ください。

于 2009-11-15T14:51:09.493 に答える
0

*nix マシンで実行している場合、従来のソリューションはsyslogです。

于 2009-11-15T14:47:54.593 に答える