NLogでロギングを集中管理する最良の方法は何ですか？

Question

私は、SharePointをベースとしたコードが沢山あり、プロジェクトに割り当てられています。

約15のサブプロジェクトで構成されています。その中には、Windowsサービス、一部のWebサービス、SharePoint内で動作するWebアプリケーション、Webパーツ、さらにはコンソールアプリケーションなどがあります。それらはすべて同じサーバー上で実行され、お互いに電話をかけます。

プロダクションではすでに多くの問題がありますが、トレースするのは難しいです。
オリジナルの開発者は、すべての例外を捕らえようと努力して、サリンジャーまたはポケモンシリーズのファンであったにちがいありません。残念ながら、それらのどれも報告されたり、記録されたりすることはありません。

私の現在の仕事は、プロジェクト全体にロギングを導入して、今や目に見えない例外を見つけ出し、絡み合った繰り返し呼び出しに従い、少なくともいくつかのスタックトレースを持つことです。私はNLogと一緒に行くことにしました。それは、アクティブでクールだと感じました。log4netとは対照的ですが、私の趣味にはあまり好きではありません。

コンポーネントが緊密に結合されているため、関連するエラーがハードドライブに分散されないように、ログを1つのファイルに集中させたいと考えています。したがって、私は、2つまたは3つの異なるログファイルを5つ以上のプロジェクトに書き込むことを検討しています。

ロギングを集中化するようにNLogを設定する最も良い方法は何ですか？プロジェクトごとに設定ファイルを用意するか、関連するプロジェクトで共有する必要がありますか？ SharePoint Webパーツからログを出力する設定ファイルはどこに置く必要がありますか？許可の問題に直面するつもりですか？

私はあなたにもちょうどSharePointでの既存のロギングインフラストラクチャを活用し、ULSログに書き込むことができSharePointの2007

Answer 1

一元管理する最も簡単な方法は、単にデータベースにログを記録することです.1つの利点は、複数のアプリケーションが存在し、同じログファイルよりも簡単にデータベースに書き込むことです。アプリケーションごとに、それぞれに同じデータベースターゲット設定パラメータを使用して、データベースターゲットにログするようにNLogを設定します。あなたのNLog.configファイルは次のようになります：あなたは確かに、データベースへの（またはその代わりに）ログに加えて、ファイルにログを記録でき

<?xml version="1.0" encoding="utf-8" ?> 
<!-- 
    This file needs to be put in the application directory. Make sure to set 
    'Copy to Output Directory' option in Visual Studio. 
    --> 
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" 
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     autoReload="true" 
     internalLogLevel="Debug" 
     internalLogFile="nlog_log.log"> 


    <targets async="true"> 
    <target name="sqlexpress" xsi:type="Database"> 
     <connectionString> 
     Data Source=.\SQLEXPRESS;Initial Catalog=LoggingDB;Integrated Security=True; 
     </connectionString> 
     <commandText> 
     insert into LogTable(DateTime,Logger,LogLevel,Message,ProcessId,ManagedThreadId) values (@DateTime,@Logger,@LogLevel,@Message,@ProcessId,@ManagedThreadId); 
     </commandText> 
     <parameter name="@DateTime" layout="${date:format=yyyy\-MM\-dd HH\:mm\:ss.fff}"/> 
     <parameter name="@Logger" layout="${logger}"/> 
     <parameter name="@LogLevel" layout="${level}"/> 
     <parameter name="@Message" layout="${message}"/> 
    </target> 

    </target> 
    </targets> 
    <rules> 
    <logger name="*" minlevel="Trace" writeTo="sqlexpress" /> 
    </rules> 
</nlog> 

。

私はこれをSharePointから行うことに慣れていないので、そこに実行する可能性のある設定やアクセス許可の問題についてはコメントできません。ここで

は、SharePoint環境で動作するようにNLogを得るための議論があるところ私が見つけたリンクです：

http://nlog-forum.1685105.n2.nabble.com/Is-anyone-using-NLog-with-SharePoint-td2171451.html

リンクの代わりにNLogフォーラムの一番上にあなたを置くために表示されていること特定の投稿フォーラムでこのテキストを検索するには、「SharePointでNLogを使用している人は誰ですか？」と、適切な投稿を見つける必要があります。

幸運を祈る！

Answer 2

を使用しています。このようにして、ログ情報はULS log viewerを使用して完全なコンテキストで表示できます。 SharePoint 2007のためにULSログへの書き込みをどのようにこのブログを参照してください。 SharePoint Trace Logs and the Unified Logging Service (ULS)

のSharePoint 2010では、それはあなたが新しいWriteTraceメソッドを使用することができますSPDiagnosticsServiceクラスへの改善でさえも簡単になりました。

Answer 3

イベントロガーの例外を個人的に記録します。また、ログの詳細、デバッグ情報、またはトレースにNLogを使用します。

NLogは簡単にオンとオフを切り替えることができるので、デバッグしているときや、プロダクションで例外を検査する必要があるときにのみアクティブにします。私は決して.NETのデフォルトのトレース機能の大ファンではなかった。

私はシンプルなプレーンテキストのログファイルが好きです。あなたのコードにあまりにも多くの "ログライン"が実装されていなければ、データベースへのロギングは効果的です。

Answer 4

同じプロジェクトに取り組んでいるような気がします。残念ながら私はあなたのような共有ポイントで作業していませんが、私がどのようにログを集中させようとしているのか説明できます。

私たちは1つのコア.NETフレームワークプロジェクトを持っています。ここで私たちはログのラッパークラスを配置しました。このプロジェクトには、nlog dllとnlog設定ファイルも含まれています。このコアプロジェクトファイルでは、このコアプロジェクトに依存するプロジェクトをビルドするときに自動的にconfigを移動することができます。

<None Include="Logging\NLog.config"> 
    <link>NLog.config</link> 
    <CopyToOutputDirectory>Always</CopyToOutputDirectory> 
</None> 

我々は、DLLをコンパイルしていないいくつかのWebプロジェクトが自動的に設定ファイルに引っ張らないでください、私たちはビルドプロセスにそれを任せるだろうことがわかりました。これにより、ロギングを一元化し、単一の設定を管理するだけで済みます。また

は、クラスごとにロガーを作成するときに、特定のプロジェクトのためのさまざまな設定をしたい場合は、名前空間をオフに基づいてフィルタ具体的な目標を作ることができるので、ログ名は、その名前空間を持つ必要があります覚えています。

ログの最終的な集中化に関しては、ファイルターゲットを使用してフルパスを指定することを選択しました。これは、私たちのサーバー上でアプリケーションがC：\から実行されているためですが、ログを格納できるより大きなD：\があるためです。私たちのプロダクションサーバでは、複数のサーバも持っているので、すべてのログを集約するためにsplunkを使用しています。

Splunkは問題外ですし、分散システム上にある場合は上記示唆したように、データベースは良いアイデアのように聞こえます。 SQLインスタンスを立ち上がらせたくない場合は、mongo dbのターゲットラッパーもあります。

誰かが私のやり方に関する提案や意見を持っているのであれば、私は好都合です。