質問

まず、主観的な響きのタイトルについておaび申し上げます。これは直接的な質問として意図されています。

現在、私は一連のツールに取り組んでいます:

  • C#Windowsサービス、主に Oracleデータベースを保守します。
  • C#Windowsサービス(これは 複数のノードサイトで使用) データベースのコンテンツを処理します。
  • ASP.NET Webインターフェイス 全体の管理を促進する "システム"

現在、Windowsサービスは(デバッグ/開発を容易にするために)コンソールアプリケーションとして開発されており、これらをサービスに変換している最中です。これらのサービスで数日間テストした後、ログの粒度を上げたいと思っています。 Console.WriteLine()を見逃していることがわかりました。このタイプの出力には、フラットファイルのような代替ログソースを提供したいと思います。これにより、「フレームワークを使用する必要がありますか、それとも十分ですか?」

私が開発している側面に言及した理由は、私の状況に対する洞察を提供するためです。 "コア" DLLは、すべてのコンポーネントに共通して作成され、アプリケーションとデータベース間の相互作用層を抽象化します。このDLL内で、「データベース内のテーブルにログを記録」しようとするクラスが作成されています。それ以外の場合は、「ローカルイベントログへのログ」が失敗します。これが、ロギングの範囲です。

前述のツールを通して、以下とは異なるロギングのインスタンスが複数あります:

Log.LogError("Code", e.Message + "\n" + e.StackTrace);

非常に基本的な方法ですが、この方法ではリフレクションを使用してエラーの原因を特定します。

私の質問

現在のロギングソリューションを見ると、「十分」だと思われます。それが何をするのか、そしてそれが私のすべてのソリューションとどのように統合されるのかという点で。ただし、ロギングフレームワーク(特にlog4net)とその機能に感銘を受けました。将来必要に応じて、別の出力形式(SMTPサーバーなど)を追加する機能は、私にとっては格好いいですね! :)

フレームワーク(log4netなど)に移行するメリットは何ですか?どのくらいコードを適応させる必要がありますか?反対側の緑の草を見ているだけかどうか?そして最後に、おそらく最も重要なことは、私は正しいことをしていますか? Logクラスの機能を" LogDebug"に追加するだけですそしてそれで終わりましたか?最後にしたいことは、「基本」のためだけにスイートを完全にオーバーホールすることです。機能が、他の利点がある場合(設計、信頼、良い習慣など)私は興味があります。

ありがとう、

役に立ちましたか?

解決

適切なロギングは、複数のリモートシステムでコードを実行する場合に特に有益です。思い出す限り、log4netを使用すると、多くのコーディングオーバーヘッドなしでログをリモートsyslogサーバーに送信できます(つまり、すべてのマシンのログを1台で表示できます)これにより、システムのバグや問題に関する情報を取得するのにかかる時間が大幅に短縮されます。また、問題がどの程度広がっているかを示す必要があります。

他の投稿で述べたように、log4netでは複数のアペンダーと複数のログレベルも許可されているため、特定のログ情報の場所(つまり、データベースまたはローカルフラットファイル)を決定します。 )格納されるのは絶対にだらだらです。

それを実装することに関しては、セットアップを通してあなたに話しかけるいくつかの良いサイトがあります。 log4netが提供するロギングオブジェクトを実際に使用する方法はアーキテクチャ上の選択ですが、オブジェクトのコンストラクターを変更してlog4netオブジェクトを取得し、このオブジェクト内から、Console.WriteLineのようにlog4netオブジェクトを使用するだけです。 。

チュートリアルシリーズ

他のヒント

はい。既存の実績のあるロギングフレームワーク(Log4netなど)を使用することをお勧めします。

Log4Netは実行時に設定可能です(本番コードの問題を追跡するのに最適です)。

コメンターが指摘したように、使い方も非常に簡単です。

はい、あなたは間違いなくロギングフレームワークを使いたいです。ロギングフレームワークを使用すると、次のことができます。

      
  • 異なるロガーインスタンスのログレベルを設定します。
  •   
  • 「アペンダー」を設定します;または、異なるロガーインスタンスごとに出力します。

より重要なのは、ロギングフレームワークを使用する場合、ロギングフレームワークの実装を別のものに交換することは非常に簡単です(おそらくメッセージを単に破棄するnull実装)。一方、すべてのロギングステートメントを直接記述した場合、実装の交換は悪夢になります。

Log4netを使用するべきだと思います。それは、独自のものを構築するよりも常に再利用する方が良いからです。 log4netは多くの開発者によって使用されており、かなり成熟しています。

メンテナンスの見通しについて考えてください。 1〜2か月後、カスタムロギングクラスを少し調整して、マルチスレッドサポートなどを追加する必要がある場合があります。また、ロギングクラスから生じたバグを修正する場合、Log4netが見つかりません。

NLog( http://nlog-project.org/home )ほとんどのoss .Netライブラリの「ストレートJavaポート-書き換え」症候群に悩まされないため。

私たちにとっての主な利点は、非常に高速なLogger.IsFooEnabled(揮発性読み取り)とシステム全体のパフォーマンスです。

ただし、それぞれ独自ですが、私は個人的にプロジェクト(および一部のクライアントも)でNLogを好みます。

乾杯、 フロリアン

Log4Netのような優れたロギングフレームワークを使用する利点は、変更する必要のあるコード行に関して、コードにわずかな影響しか与えないことです(つまり、既存の各ロギング行を変更するだけですみます)。

また、フレームワークを変更した場合にコードの変更が懸念される場合、または独自のロールを作成したい場合は、常に a ロギングフレームワークへの独自のインターフェイスを作成できます。その後、コードを1か所で変更するだけで済みます。

システム管理者は、サービスがWindowsのアプリケーションイベントログに記録することを期待していると思います。

System.Diagnostics.EventLogを検索しますが、log4netもそれに書き込みます。

log4j Webサイトの最初のステートメントは、質問、根本的な原則はlog4netと同じです:

  

log4jでは、有効にすることができます   変更せずに実行時にロギング   アプリケーションバイナリ。 log4j   パッケージは、これらが   出荷されたコードにステートメントを残すことができます   重いパフォーマンスを引き起こすことなく   コスト。ロギング動作は   構成を編集して制御   ファイル、アプリケーションに触れることなく   バイナリ。

     

ロガー階層を使用すると、   どのログを制御することが可能   ステートメントは任意に出力されます   細かい粒度だけでなく、非常に簡単。   これは、記録されるボリュームを減らすのに役立ちます   出力し、コストを最小化   ロギング。

この場合、明らかに車輪を再発明する必要はありません。ほとんどのロギングフレームワークはやや単純であるため、変更の範囲は既存のプログラムのサイズに依存する可能性が高くなります。

ロガークラスを適切に記述すると、どのようなニーズにも簡単に使用できます。どのフレームワークでも多くの機能を使用できますが、別のフレームワークは、存在しないエラーを生成したり、アプリケーションと組み合わせて単独でエラーを発生させたりする可能性があるため、デバッグプロセスの別の変数です。オープンソースソフトウェアプロジェクトのベータテストを行う準備ができている場合は、これで問題ありません...

あなたの代わりに、既知のフレームワークが持っている機能のリストに基づいて、プロジェクトに興味がある機能を拡張する機能を備えたログクラスを作成します。ファイルに何かを記録し、それをsmptで送信しても問題はありません。1つの小さな関数が仕事をします。

さらに、クラスをテストするために外部フレームワークを使用する必要がある場合は、コードへの影響を最小限に抑えてクラスを使用できるように、かなり抽象的で基本的なコードをそこに置く独自のクラスを作成できます。フレームワークがコードレベルでどのように実装されているかを見てください。

これらのフレームワークを適切に使用する方法を学ぶ必要があると思うのは、現時点でそのほんの一部を記録する必要がある場合だけです...

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top