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

Самый простой способ централизации - это, вероятно, просто войти в базу данных, одно из преимуществ состоит в том, что несколько приложений и запись в базу данных проще, чем в один и тот же файл журнала. Для каждого приложения настройте 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/Is-anyone-using-NLog-with-SharePoint-td2171451.html

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

Удачи!

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

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

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

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

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

Я чувствую, что мы работаем над одним проектом! Несколько проектов, состоящих из веб-проектов, основных проектов 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.

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