ロギングフレームワーク、良いアイデア?

c# log4net logging

まず第一に、主観的に聞こえるタイトルの謝罪 これは直接的な質問として意図されています。

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

  • C#Windowsサービス。主にOracleデータベースを管理します。

  • データベースのコンテンツを処理するためのC#Windowsサービス(複数のノードサイトで使用されます)。

  • 「システム」全体の管理を容易にするASP.NET Webインターフェース

現在Windowsサービスはコンソールアプリケーションとして(デバッグ/開発を容易にするために)開発されており、私はこれらをサービスに変換している最中です。 これらのサービスで2、3日間テストした結果、ログ記録の粒度を上げたいと思っています。 Console.WriteLine()が欠けているので、このタイプの出力にはフラットファイルなどの代替ログソースを提供したいと思います。 これは私に「私はフレームワークを使うべきなのか、それとも十分なものがあるべきなのか」と考えさせました。

私が開発している側面について述べたのは、自分の状況に対する洞察を提供するためです。 すべてのコンポーネントに共通の「コア」DLLが作成され、アプリケーションとデータベースの間の対話層が抽象化されました。 「データベース内のテーブルにログを記録する」または「失敗した場合はローカルのイベントログに記録する」ことを試みるクラスが作成されたのは、このDLLの範囲内です。 これはそれです、それは伐採の範囲です。

前述のツール全体を通して、ロギングには次のような違いがないわけではありません。

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

非常に基本的ですが、このメソッドはエラーの原因を特定するためにリフレクションを利用します。

私の質問

私の現在のロギングソリューションを見ると、それが何をしているか、そしてそれがどのように私のすべてのソリューションと統合されているかという点で、それは「十分」に見えます。 しかし、私はロギングフレームワーク(特にlog4net)とそれらの機能を見てきました。 将来必要になったときに、別の出力形式(SMTPサーバーなど)を追加する機能は、私にとってはすごくいい気がします! 🙂

(log4netのような)フレームワークに移行することの利点は何でしょうか? 自分のコードをどの程度適応させる必要があるでしょうか。 もう一方の緑の芝生だけを見ているのかどうか。 そして最後に、おそらく最も重要なこととして、私は正しいことをしているのでしょうか。 Logクラスに “LogDebug”の機能を追加してそれを実行する必要がありますか? 私がしたいと思う最後のことはちょうど「基本的な」機能のために私のスイートを完全に見直すことです、しかし他の利点があるならば(デザイン、信頼、良い習慣? 私は興味があります。

ありがとう、

  8  1


ベストアンサー

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

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

コメント投稿者が指摘したように、それも使用するのは非常に簡単です。

13


適切なロギングは、複数のリモートシステムでコードを実行する場合に特に有益です。思い出せる限り、log4netを使用すると、コーディングのオーバーヘッドをほとんど発生させることなくリモートsyslogサーバーにログを送信できます。これを行うと、システムのバグや問題に関する情報を入手するのにかかる時間が大幅に短縮されます。また、その問題がどの程度発生しているかを示すこともできます。

他の記事で述べたように、log4netは複数のアペンダと複数のログレベルも可能にします。 データベースやローカルのフラットファイルでは、ちょっとlog4netを使えばtelnetでログを吐き出すことさえできます)。

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

私はチュートリアルシリーズ hereが特に有用であると思います、そしてそれは私がここでできる以上に深くまた入るでしょうlog4netを設定する利点とさまざまな方法について。

6


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

  • さまざまなロガーインスタンスのログレベルを設定します。

  • それぞれの異なるロガーインスタンスに対して「アペンダ」または出力を設定します。

おそらく、もっと重要なことに、ロギングフレームワークを使用するのであれば、ロギングフレームワークの実装を別のものに交換するのは非常に簡単です(おそらく単にメッセージを破棄するnull実装)。あなたがすべてのロギングステートメントを直接書くのであれば、直接、実装を交換することは悪夢になるでしょう。

4


私はあなたがLog4netを使うべきだと思います、なぜならそれはあなた自身のものを作ることよりも常に再利用するのが良いからです。 log4netは多くの開発者によって使用されており、かなり成熟しています。

メンテナンスの見込みについて考えてください。 1〜2か月後には、マルチスレッドサポートなどを追加するために、カスタムロギングクラスを少し調整する必要があるかもしれません。 そして、ロギングクラスから発生したバグを修正しているとき、あなたはLog4netを見逃すでしょう。

3


大きな利点の1つは、コードを自分で管理する必要がないことです。 ほとんどの場合、ロギングフレームワークはあなた自身のソリューションよりもずっと多くの機能を持っています。 それらはロギングに非常に集中しているので、それらのフレームワークは通常それを実装するための機能と方法の両方においてかなり完成しています。 そして信頼性があります。ロギングフレームワークにバグがあるので何もロギングしていないことよりも悪いことはありません。 ;)

たとえば、ASP.netアプリケーションの場合は ELMAHです。 通知、さまざまなターゲット形式へのエクスポートなども含まれます。 かなり便利なものですが、本当に必要でない限り自分で作ることはできません。

あなたのコードにどれだけの変更を加える必要があるかは明らかにあなたのコードと選択したフレームワークの両方に依存します。 それについて何か言うのは難しいです。

3


NLog(http://nlog-project.org/home)は、ほとんどのoss .Net libsの ‘Straight Java Port – then rewrite’シンドロームに悩まされていないので、私は叫ぶことにします。

私達にとってのいくつかの主な利点は非常に速いLogger.IsFooEnabled(揮発性読み取り)とシステムの全体的なパフォーマンスでした。

だがそれなりにはあるが、私は個人的に私のプロジェクト(そして私のクライアントの中にも)にはNLogを好む。

乾杯、フロリアン

3


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

また、フレームワークを変更したときにコードを変更することを心配している場合、または自分自身でロールバックしたいと思う場合は、いつでもロギングフレームワークへの独自のインターフェースを作成できます。 その後は、コードを一箇所で変更するだけで済みます。

1


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

log4netも書き込みますがSystem.Diagnostics.EventLogを調べてください

1


http://logging.apache.org/log4j/1.2/index.html [log4j webサイト]の最初の文はあなたの質問のいくつかを助けるかもしれません、基本的な原則はlog4netと同じです:

__
log4jを使用すると、アプリケーションのバイナリを変更せずに実行時にロギングを有効にすることができます。 log4jパッケージは、これらのステートメントが出荷時のコードに残っていてもパフォーマンスに大きな負担がかからないように設計されています。 ロギング動作は、アプリケーションバイナリに触れることなく、設定ファイルを編集することによって制御できます。

ロガー階層を使用すると、どのログステートメントを任意の細かさで出力するかを制御することができますが、非常に簡単です。 これはログに記録される出力の量を減らし、ログ記録のコストを最小にするのを助けます。
__

この場合、明らかにホイールを作り直す必要はありません。 ほとんどのLoggingフレームワークはやや単純であるため、変更の範囲はおそらく既存のプログラムのサイズに依存します。

0


あなたがきちんとあなたのロガークラスを書くならば、それはあなたのニーズのどれにでも簡単に消耗するでしょう。 どんなフレームワークでも多くの機能をあなたに印象づけることができますが、別のフレームワークはあなたに存在しないエラーを与えることができるか、あなたのアプリケーションと組み合わせてそれ自体でエラーを作ることができるのであなたのデバッグプロセスにおける別の変数です。 あなたがオープンソースソフトウェアプロジェクトのためのベータテストをする準備ができているなら、これは結構です…​

あなたの場所で私はそれを拡張する機能を備えたログクラスを書くでしょう。 何かをファイルに記録してからsmptで送信しても問題はありません。1つの小さな関数がその仕事をします。

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

ごくわずかな部分だけをログに記録する必要がある場合は、これらのフレームワークを適切に使用する方法を学ぶ必要があると思います。

0


タイトルとURLをコピーしました