4

私は、SharePointに基づいた多くの不十分に記述されたコードを含むプロジェクトを割り当てられました。

これは約15のサブプロジェクトで構成されており、そのうちのいくつかはWindowsサービス、いくつかのWebサービス、SharePoint内で実行されるいくつかのWebアプリケーション、いくつかはWebパーツ、さらにはコンソールアプリケーションです。それらはすべて同じサーバー上で実行され、相互に呼び出します。

本番環境にはすでに多くの問題がありますが、追跡するのは困難です。
元の開発者は、すべての例外をキャッチするための彼のたゆまぬ努力から判断して、サリンジャーまたはポケモンシリーズのいずれかのファンであったに違いありません。残念ながら、それらのいずれも報告またはログに記録されません。

私の現在のタスクは、プロジェクト全体にログインを導入することです。これにより、現在は表示されていない例外を見つけ、絡み合った繰り返し呼び出しを追跡し、少なくともいくつかのスタックトレースを取得できます。私はNLogを使用することにしました。これは、 log4netは完全に優れていますが、私の好みには多少劣るのとは対照的に、アクティブでクールであることがわかりました。

コンポーネントは緊密に結合されているため、関連するエラーがハードドライブ全体に分散しないように、ログを1つのファイルに一元化する必要があります。したがって、5つ以上のプロジェクトが多かれ少なかれ同時にそれぞれに書き込みを行う2つまたは3つの異なるログファイルを探しています。

ロギングを一元化するようにNLogを構成する最良の方法は何ですか？プロジェクトごとに構成ファイルを用意する必要がありますか、それとも関連するプロジェクトで共有する必要がありますか？SharePoint Webパーツからログに記録する構成ファイルはどこに置く必要がありますか？許可の問題に直面しますか？

SharePoint2007を使用しています。

4

4 に答える 4

6

一元化する最も簡単な方法は、おそらくデータベースにログを記録することです。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を使用している人はいますか」でこのテキストを検索すると、適切な投稿が見つかります。

幸運を！

于 2011-02-09T17:54:59.237 に答える
3

SharePointの既存のログインフラストラクチャを活用して、ULSログに書き込むこともできます。このようにして、 ULSログビューアを使用して、ログ情報を完全なコンテキストで表示できます。SharePoint 2007については、このブログでULSログへの書き込み方法を参照してください： SharePointトレースログと統合ログサービス（ULS）

SharePoint 2010では、新しいWriteTraceメソッドを使用できるSPDiagnosticsServiceクラスが改善され、さらに簡単になりました。

于 2011-02-09T06:24:38.710 に答える
1

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

NLogは簡単にオンとオフを切り替えることができるため、デバッグ中または本番環境で例外を検査する必要がある場合にのみアクティブにします。私は.NETのデフォルトのトレース機能の大ファンではありませんでした。

単純なプレーンテキストのログファイルが好きです。ただし、コードに実装されている「ログ行」が多すぎない場合は、データベースへのログ記録はうまく機能します。

于 2011-05-27T07:18:14.417 に答える
0

同じプロジェクトに取り組んでいるような気がします！Webプロジェクト、コアdllプロジェクト、コンソールアプリ、サービスなどで構成される複数のプロジェクト。残念ながら、私はあなたのようにSharePointで作業していませんが、ログを一元化しようとしている方法を説明できます。

1つのコア.Netフレームワークプロジェクトがあります。これは、ログのラッパークラスを配置した場所です。このプロジェクトには、nlogdllとnlog構成ファイルも含まれています。このコアプロジェクトファイルにこれを追加すると、このコアプロジェクトに依存するプロジェクトをビルドするときに構成が自動的に移動します。

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

dllをコンパイルしない一部のWebプロジェクトは、構成ファイルを自動的にプルしないことがわかったため、ビルドプロセスに任せます。これにより、ロギングを一元化できるため、すべての構成で1つの構成を管理するだけで済みます。

さらに、クラスごとにロガーを作成する場合、ログ名には名前空間が含まれている必要があるため、特定のプロジェクトに異なる設定が必要な場合は、名前空間に基づいてフィルタリングする特定のターゲットを作成できます。

ログの最終的な場所を一元化することに関しては、ファイルターゲットを使用し、フルパスを指定することを選択しました。これは、サーバー上でアプリケーションがC：\で実行されているが、ログを保存できるD：\が大きいためです。本番サーバーには複数のサーバーもあるため、splunkを使用してすべてのログを集約しています。

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

うまくいけば、私もそれをどのように行っているかについて誰かが提案や意見を持っているかどうか興味があります！

于 2015-12-17T03:47:06.503 に答える