Когда мне нужно более одного TraceSource в коде?

Question

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

Answer 1

Посмотрите эти ответы на другие вопросы для хорошей отправной точки при использовании TraceSources:

не могу понять трассировку.net 2010 и app.config

Как использовать TraceSource в разных классах

Я бы сказал, что всякий раз, когда у вас есть более одного класса, вы можете (возможно) подумать о наличии более одного TraceSource.

Одним из преимуществ наличия более одного TraceSource является то, что он увеличивает степень детализации, с которой вы можете контролировать ведение журнала. Например, если вы используете разные TraceSource в каждом классе, вы можете контролировать ведение журнала до уровня класса. Вы можете включить один (или несколько) определенных классов и отключить все остальные.

Это общий шаблон для пользователей NLog и log4net. Типичная инициализация классов с использованием этих платформ журналирования будет выглядеть примерно так:

public class A
{
  //NLog example
  private static Logger logger = LogManager.GetCurrentClassLogger();

  public F()
  {
    logger.Info("Inside F");
  }
}

В этом примере регистратор для класса A назван по имени полностью определенного класса (NLog выполняет тяжелую работу в GetCurrentClassLogger()).

Чтобы сделать нечто подобное с TraceSource, вы должны сделать что-то вроде этого:

public class A
{
  private static TraceSource ts = new TraceSource(System.Reflection.GetCurrentMethod().DeclaringType.ToString();

  public F()
  {
    ts.Information("Inside F");
  }
}

Если бы вы делали это в каждом классе, вы могли легко контролировать ведение журнала по классам.

Я не уверен, что этот шаблон так же распространен в TraceSource, как в log4net и NLog. Я думаю, что вы можете чаще видеть, как пользователи TraceSource получают свои TraceSources по функциональным областям.

Таким образом, вы можете разделить свое приложение на функции "Чтение", "Обработка" и "Запись" (или все, что имеет для вас смысл). В этом случае вы можете получить соответствующий TraceSource в ваших классах на основе функциональной области, в которой они используются:

public class FileReader
{
  private static TraceSource ts = new TraceSource("Read");

  public F()
  {
    ts.Information("Hello from FileReader.F");
  }
}

public class NetworkReader
{
  private static TraceSource ts = new TraceSource("Read");

  public F()
  {
    ts.Information("Hello from NetworkReader.F");
  }
}

И так далее.

Теперь вы можете включить ведение журнала для "Чтение" и отключить все остальные функциональные области (или включить подробное ведение журнала для "Чтение" и менее подробное ведение журнала для всех остальных).

Кроме того, одним из параметров TraceListeners является вывод имени TraceSource. Таким образом, в ваших выходных данных будет легче разобраться в вашей регистрации, потому что вы можете, если вы решите сделать это, относительно легко найти все сообщения регистрации, которые генерируются из определенной функциональной области (или с помощью определенного TraceSource).

Если у вас есть хорошее соглашение об именовании пространств имен, вы можете даже рассмотреть возможность получения TraceSource для каждого класса на основе некоторого узла в иерархии пространства имен или даже на основе сборки, в которой живет класс. Существуют.NET-вызовы для типа, который будет получать эта информация для вас.

Поскольку вы смотрите на TraceSources, я бы посоветовал вам взглянуть на этот проект на codeplex:

http://ukadcdiagnostics.codeplex.com/

Это хороший проект (основанный на TraceSource), который позволяет вам форматировать выходные данные журнала аналогично тому, что вы можете делать с log4net и NLog.

Я также призываю вас взглянуть на эту оболочку регистрации, построенную вокруг TraceSource от Castle.

https://github.com/castleproject/Castle.Core/blob/master/src/Castle.Core/Core/Logging/TraceLogger.cs

Интересно, что они сделали, чтобы обеспечить иерархию имен TraceSource. Я реализовал нечто подобное в прошлом. Это работает довольно хорошо.

Мой ответ на этот вопрос дает представление о том, как может быть полезна иерархия TraceSource:

Каков наилучший подход к ведению журнала?

Удачи!