Какие виды журналирования следует добавить в приложение, которое будет полезно позже?
Если вы генерируете исключения из ваших собственных классов исключений, или, что еще лучше, все ваши классы исключений происходят из базового класса, добавьте ведение журнала уровня ОШИБКИ в (базовом) конструкторе исключений; избавляет вас от необходимости помнить о каждом улове / броске. Полезно, если у вас большая кодовая база.
Для исключений CLR или сторонних разработчиков регистрируйте Exception.ToString (), а не просто сообщение, в противном случае вы пропускаете трассировку полного стека (при условии, что программисты не проглатывают исключения или не перебрасывают внутреннее исключение без sans)
Сосредоточьтесь на деталях отладки в тех областях, где вы либо знаете, либо подозреваете, что у вас будут проблемы (просто спросите QA или техподдержку, где искать; -)
Если вы следуете принципу надежности , то вы можете захотеть регистрировать INFO или WARN, когда игнорируете или изменяете входные данные или ожидаемое поведение. Это может быть полезно, если ваша служба WCF начинает получать неожиданные (но анализируемые) входные данные.
Чтобы убедиться, что ваше приложение работает хорошо, не отправляйте / не устанавливайте его с включенным по умолчанию протоколированием уровня DEBUG, возможно, вам подойдут ERROR или WARN.
Я не согласен с последней частью принятого ответа, потому что log4net обладает потрясающими возможностями фильтрации; при условии, что ваши программисты понимают, что ведение журналов обходится дорого (согласно ответу CK), и они (и QA и Техническая поддержка) знают о фильтрах, и что настройка всего в DEBUG - плохая идея. Если вы регистрируете на уровне DEBUG большой граф объектов, XML-документ, результат db и т. Д., Оберните его в некоторый код, который уменьшает затраты:
if (log.IsDebugEnabled)
{
log.DebugFormat("Loaded in {0} ms {1}", timer.ElapsedMilliseconds, dataSet.GetXml());
}
Я бы посоветовал вам следовать рекомендованному подходу статического логгера для класса, просто потому, что он должен сделать логирование более полезным, когда вам действительно нужно его использовать, и сузить проблему с помощью фильтров, например. LoggerMatchFilter.
Если вы следуете такому подходу и хотите получить (довольно небольшое) снижение производительности, вот один из способов, который использует трассировку стека для создания объектов ILog для любого класса и обеспечения подключения файла конфигурации для отслеживания изменений:
public static class LogFactory
{
/// <summary>
/// Create log whose name is the calling methods class name.
/// </summary>
/// <remarks>
/// <para>
/// Configures the log repository if it hasn't been configured before.
/// </para>
/// <para>
/// Creates a debug log message right after getting the logger, this follows
/// the log4net recommendation to log first message as early as possible.
/// </para>
/// </remarks>
/// <returns>Log ready for work.</returns>
public static log4net.ILog Create()
{
var method = new StackTrace().GetFrame(1).GetMethod();
var log = log4net.LogManager.GetLogger(method.DeclaringType);
if (log4net.LogManager.GetRepository().Configured == false)
{
try
{
new FileIOPermission(FileIOPermissionAccess.Read,
AppDomain.CurrentDomain.SetupInformation.ConfigurationFile)
.Demand();
var configFile = new FileInfo(AppDomain.CurrentDomain.SetupInformation.ConfigurationFile);
log4net.Config.XmlConfigurator.ConfigureAndWatch(configFile);
log.DebugFormat("Log4net configured and watching {0}", configFile.FullName);
}
catch (System.Security.SecurityException e)
{
log.DebugFormat("Unable to watch config file due to security permissions. {0}", e.ToString());
}
}
log.DebugFormat("Logging {0}", log.Logger.Name);
return log;
}
}