Этот оператор `log 'больше похож на оператор трассировки.
Ведение журнала: показать обычные события и ошибки
Трассировка: показать путь выполнения, а также все события протоколирования
Лично я хочу, чтобы вход в систему определял, какая работа была выполнена моей программой, и хочу, чтобы операторы трассировки проверяли путь выполнения и выясняли, что пошло не так. Я направлю операторы трассировки в отдельный файл, который включает оба типа сообщений журнала для контекста.
Таким образом, вы должны иметь как минимум 2 уровня журнала и иметь возможность отключить трассировку для повышения производительности. Вы должны быть в состоянии направить эти потоки событий в разные места. Это позволяет вам легко сохранять журналы для исторических записей, не загромождая их отладочной информацией, которая нужна только для отслеживания проблем.
Многие ответы здесь сосредоточены на полях, которые вы бы включили в сообщение журнала, но я бы сказал, что уровень размещения и ведения журнала вызовов журнала важнее. Если вы используете log4net, вы сможете по желанию включать / исключать отметку даты через файлы конфигурации, но вы не сможете размещать или удалять операторы журнала без перекомпиляции, поэтому имеет смысл довольно серьезно подумать о том, куда они идут. Помимо стандартных полей, таких как отметка времени, идентификатор потока и т. Д., Вы хотите знать класс и имя метода, из которого был сделан вызов. Log4net и др. Уже позаботятся об имени класса, если вы придерживаетесь их наилучшей практики именования вашего регистратора в соответствии с типом, который вас интересует. Помимо этого, я обычно включаю имя метода. Это особенно необходимо для отслеживания, но я включаю его во все свои сообщения журнала.
Ведение журнала :
Вы хотите знать достаточно информации о том, какое действие должно быть выполнено, чтобы вернуться и покопаться, если что-то пойдет не так. Хорошими кандидатами являются идентификаторы сообщений, адреса электронной почты, то, что однозначно идентифицирует рабочий элемент. Такого рода сообщения должны появиться, как только станут доступны данные такого типа, поэтому, когда вы читаете файл журнала, вы увидите что-то вроде «попытки сделать x с y», а затем, если мы увидим исключение, мы знаем, на какой рабочий элемент нам нужно посмотреть, чтобы понять, почему мы потерпели неудачу.
Ведение журнала исключений должно быть сопряжено с сообщением журнала «попытка», чтобы сообщение об исключении имело смысл в контексте при чтении журнала. Это означает думать о структуре обработки исключений. Если вы используете .net и хотите регистрировать только исключение, а не обрабатывать его, вы хотите сбросить то же самое исключение, а не новое, поэтому просто выполните команду throw, а не throw e, где 'e' - это ваш экземпляр исключения. Посмотрите на это, если это не имеет смысла.
Трассировка
Это на самом деле проще, обычно я получаю сообщение в начале и в конце интересующего нас метода, такого как форзацы. В записи вы можете напечатать критические аргументы метода, которые влияют на ход программы. Регистрация сообщения в конце метода является необязательной, обычно вам будет интересно посмотреть на трассировку, похожую на трассировку стека. Вы можете выяснить путь выполнения без них.
Performance
Для строкового исполнения используйте методы '* Format', если вы используете log4net или что-то подобное. Это внутренне будет использовать StringBuilder, чтобы вы не платили неизменный штраф за строку. Как правило, ключ заключается в том, чтобы иметь возможность отключить трассировку для повышения производительности и вести журнал достаточно кратко, чтобы его можно было включить, даже если сообщение журнала дорогое. Если все сделано правильно, их не должно быть достаточно, чтобы возникла проблема.