Каков наилучший способ централизовать ведение журнала с помощью NLog?

Question

Мне присвоен проект с большим количеством плохо написанного кода, основанного на SharePoint.

Он состоит из около 15 подпроектов, некоторые из которых представляют собой службы Windows, некоторые веб-службы, некоторые веб-приложения, работающие внутри SharePoint, некоторые веб-части и даже консольные приложения. Все они работают на одном сервере и вызывают друг друга.

В производстве уже много проблем, но их трудно отследить.
Первоначальный разработчик, должно быть, был поклонником серий Сэлинджера или Покемона, судя по его неустанным усилиям поймать все исключения. К сожалению, никто из них не был зарегистрирован или зарегистрирован.

Моя текущая задача состоит в том, чтобы ввести логирование во весь проект, чтобы я мог найти невидимые сейчас исключения, следить за запутанными повторяющимися вызовами и, по крайней мере, иметь несколько трассировок стека. Я решил пойти с NLog , увидев, что он активен и крут, в отличие от log4net , который отлично подходит, но в некотором роде не такой уж на мой вкус.

Поскольку компоненты тесно связаны, я хочу централизовать ведение журналов в одном файле, чтобы связанные с ними ошибки не распространялись по жесткому диску. Поэтому мне нужны два или три разных файла журнала, в которых пять или более проектов пишут в каждый из них более или менее одновременно.

Каков наилучший способ настройки NLog для централизации ведения журнала? Должен ли я иметь файл конфигурации для каждого проекта, или связанные проекты должны совместно использовать их? Где я должен поместить файл конфигурации для входа из веб-частей SharePoint? Буду ли я сталкиваться с какими-либо проблемами с разрешениями?

Я использую SharePoint 2007.

Answer 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, поэтому я не могу комментировать любые проблемы с конфигурацией или разрешениями, с которыми вы можете столкнуться.

Вот ссылка, которую я нашел, где обсуждается, как заставить NLog работать в среде SharePoint:

http://nlog -forum.1685105.n2.nabble.com / Кто-нибудь использует-NLog-with-SharePoint-td2171451.html

Эта ссылкакажется, ставит вас на вершину форума NLog вместо конкретного поста.Ищите этот текст на форуме «Кто-нибудь использует NLog с SharePoint», и вы должны найти правильный пост.

Удачи!

Answer 2

Вы также можете просто использовать существующую инфраструктуру ведения журналов в SharePoint и записывать в журналы ULS. Таким образом, ваша информация журнала может быть просмотрена в полном контексте с помощью ULS log viewer . Для SharePoint 2007 посмотрите этот блог, как записать в журнал ULS: Журналы трассировки SharePoint и Унифицированная служба ведения журналов (ULS)

В SharePoint 2010 это стало еще проще благодаря улучшениям класса SPDiagnosticsService , в котором можно использовать новый метод WriteTrace .

Answer 3

Лично я записываю исключения в журнал событий. И я использую NLog для регистрации деталей, отладочной информации или трассировки.

Поскольку NLog можно легко включать и выключать, я активирую его только во время отладки или когда мне нужно проверить исключение в процессе производства. Я никогда не был большим поклонником функции трассировки по умолчанию в .NET.

Я предпочитаю простые текстовые файлы журнала. Хотя регистрация в базе данных работает отлично, если в вашем коде не реализовано слишком много «строк журнала».

Answer 4

Я чувствую, что мы работаем над одним проектом! Несколько проектов, состоящих из веб-проектов, базовых dll-проектов, консольных приложений, сервисов и т. Д. К сожалению, я не работаю в sharepoint, как вы, но я могу описать, как я пытаюсь централизовать нашу регистрацию.

У нас есть один базовый проект .Net Framework. Именно здесь я разместил наш класс-оболочку журнала. Этот проект также содержит DLL-файлы nlog и файл конфигурации nlog. В этот основной файл проекта вы можете добавить его, который автоматически перемещает конфигурацию при создании проектов с зависимостью от этого основного проекта.

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

Мы обнаружили, что некоторые веб-проекты, которые не компилируют dll, автоматически не извлекают файл конфигурации, поэтому мы оставим это до процесса сборки. Это помогает централизовать нашу регистрацию, поэтому вам нужно всего лишь управлять одной конфигурацией.

Кроме того, помните, что когда вы создаете регистратор для каждого класса, имя журнала должно содержать пространство имен, чтобы вы могли создавать конкретные цели, которые фильтруются на основе пространства имен, если вам нужны другие настройки для конкретных проектов.

Что касается централизации, где заканчиваются журналы, мы решили использовать цель файла и указать полный путь. Это потому, что на наших серверах приложения запускаются из C: \, но у нас есть большие D: \, которые могут хранить журналы. На наших производственных серверах у нас также есть несколько серверов, поэтому мы используем Splunk для объединения всех наших журналов.

Если о splunk не может быть и речи, и вы работаете в распределенной системе, база данных звучит как хорошая идея, как предложено выше. Если вы не хотите поддерживать экземпляр SQL, есть целевые оболочки для mongo db.

Надеюсь, полезно, мне любопытно, если у кого-то есть предложения или мнения о том, как я это делаю!