.Net Log によるいくつかのログ管理方法は
、アプリケーションの実行ステータスを記録するだけでなく、アプリケーションの更新や変更を容易にするためにいくつかのバグを記録することもできます。
.Net でログを管理するには、いくつかの方法があります。
1. データベースログ。
2. テキストログ。
3. システムイベントログ。
まず第一に、データベースログに使用するのは簡単で便利です。ここではあまり詳しく説明しませんが、データ関連のプロジェクトを書いたことがある人なら誰でも、データを使用してログを記録すると思います。ただし、唯一の欠点は、最初にデータベース リンクが正しいことを確認する必要があることです。
ただし、この保証は避けられないものではないため、ここでは他の 2 つの状況、テキスト ログとシステム イベント ログについて説明します。
テキストログ:
使い方も簡単で、見やすいです。欠点は、大量のログを作成するのが不便であり、ログの内容を表示および分析するのが不便であることです。ただし、データベースのログ記録が適さない場所では引き続き使用できます。たとえば、いくつかのテスト メッセージの出力、いくつかの独立したコンポーネントの少量のログなどです。
通常、ログファイルは管理を容易にするために日単位で分類されます。このようにして、ファイルを簡単に管理できます。例：このログがいつのものかをファイル名で知ることができ、データベースと同様のクエリを作成するだけで管理も便利です。結局のところ、テキストはシステムにとって非常にシンプルです。
.Net には、リスニング形式でトレースとデバッグにテキストを追加できる診断クラスがあります。これにより、トレースとデバッグに送信されたすべての出力がファイルに記録されます。これはとても良い方法です。
System.Diagnostics を使用します;
Debug.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(DateTime.Now.ToString("yyyyMMdd")+"..log"));
Debug.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(Console.Out));
または:
Trace.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(DateTime.Now.ToString("yyyyMMdd")+"..log"));
Trace.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(Console.Out));
ここでの違いは、Trace は Release で使用できるのに対し、Debug は Debug でのみ使用できることです。
テキストログの中で、上記の方法が一番使いやすいと思います。別のログ管理クラスを作成するだけで済みます。
もちろん、モニターは 24 時間後に更新する必要があることにも注意してください。現在のモニターをクリーンアップして、新しいモニターを追加する必要があります。それもシンプルです。
自分で文章を書いて管理するという方法もあります。この方法は少し面倒ですが、難しくはありません。
ただし、テキスト ログには、大量のログ記録作業を行うのに不便なだけでなく、プロセスの競合という致命的な問題もあります。
テキスト ログは書き込み中のテキスト ファイルをロックするため、ファイルに書き込みたい他のプログラムでエラーが発生します。通常の状況では、プログラムのコピーが 1 つだけ実行され、ログがグローバル静的オブジェクトとして処理される場合、大きな問題は発生しません。ただし、プログラムの 2 番目のコピーは、ファイルを開くことができないため、起動できません。
これは解決できない問題ではありませんが、プログラムのコピーがあることを確認してください。それが保証されていない場合は、ちょっとややこしいので、これ以上はここでは議論しませんが、この問題については次回機会があれば議論したいと思います。
上記の問題に対して、テキストログを一時的に放棄し、システムイベントログを使用して対処したいと考えています。
システムイベントログ:
.net には EventLog クラスがあり、システムのイベント ログに直接関連付けられています。
簡単なもの:
EventLog.WriteEntry("LogSource","これはテスト ログです。");
イベントをシステムに書き込むことができます。
ただし、それをうまく使用するのは少し難しいかもしれません。まず、上記のメソッドはシステムのアプリケーションの下にイベント ログを書き込みます。デフォルトは情報タイプです。これは管理に役立ちません。管理ツールでログを確認すると、自分で書き込んだ小さなログを見つけることは不可能です。
ただし、.Net では、ログをより適切に管理するための方法がいくつか提供されています。
1. 新しいログソースを追加します。
ログソースとは何ですか?実際、簡単に言うと、ログの分類マークです。たとえば、指定した内容を LogSource とするログを一度に取得するプログラムを使用できます。このようにして、ソース名を覚えていれば、ログを読んで分類することができます。
デフォルトでは、EventLog の静的関数を使用してログを直接書き込む場合、LogSource を指定する必要があります。LogSource が存在しない場合は、Application の下に自動的に LogSource が作成されます。
2. 新しいログを追加します。
ログとは何ですか? ここでのログは、システム イベント ログの大規模なログ分類を指します。通常、システムにはアプリケーション、システム、サービスの 3 つのログがあり、それぞれが異なるログ システムを形成します。
.NET にはログを作成するメソッドが提供されていないため、ログを個別に作成することはできません。関数 CreateEventSource(string, string) のみを使用できます。
ソースを作成するには、次のようにします。 CreateEventSource("MySource", "MyLog");
ログ マネージャーに追加の MyLog クラスが表示され、次のようにログを書き込みます。
EventLog.WriteEntry("MySource","これはテスト ログです。");
MyLog カテゴリにレコードを書き込むことができるので、自分のログを適切に管理できます。
説明する必要があるのは次のとおりです。
ソースがすでに存在する場合、作成は失敗します。注: ソースのどのログであっても、ソースの名前がすでに存在する限り、作成は失敗します。例: アプリケーションに「Source1」というログがある場合、他のログに「Source1」という名前のログを作成することはできません。さらに、プログラムを使用して作成したログは、ログ マネージャーでは削除できません (メッセージは削除できますが、ログ カテゴリは削除できません)。その方法は、プログラムを使用して削除することも、レジストリで削除することもできます。その場所: [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventlog]
レジストリを見てみると、何かがわかるかもしれません。
最後のステップは、ログ インスタンス オブジェクトを使用してログを書き込むことです。ログ名とソース名を指定してログを書き込むことができますが、ログとソースは一致する必要があることに注意してください。一致しないとエラーが発生します。これは、静的メソッドを使用して直接ログを記録するよりも少し複雑ですが、より自由度が高くなります。
システム イベント ログの欠点は、ログが 3 か月しか保存されず、管理が難しいことです。サーバーを直接管理できるか、ローカルで実行できれば良いのですが、そうでない場合は、ログを管理するためのコードを自分で記述する必要があります。もちろん、重要なログを他のファイルにエクスポートできる場合は、
その利点は数多くあります。
1. データベースに接続する必要がなく、効率が向上し、データベースアクセスの失敗の問題も発生しません。
2. プロセスの競合は発生しません。どのようなアプリケーションであっても、ログを書き込むことができます。
3. グローバルに利用できるため、ログはどこにいても直接書き込んで読み取ることができます。したがって、メッセージング通信プラットフォームとみなすことができます。 (もちろん、これを行うのは脳に問題がある人だけかもしれません。) ただし、ここで説明しておきたいのは、プロセス A によって書き込まれたログは、プロセス B によって直接読み取られるということです。
さて、今回のログはここまでです。
http://www.cnblogs.com/Wucountry/archive/2006/08/22/483090.html