Чтобы ответить на ваш вопрос, мне нужно знать, какова цель журналов. Я собираюсь сделать некоторые догадки, но если бы вы могли расширить свой вопрос, это помогло бы.
Как правило, есть две причины для включения регистрации в приложении.
Мониторинг приложений
С этими автоматическими процессами вы должны быть уверены, что они все еще работают, и что кто-то уведомляется, если они этого не делают. Конечно, здесь есть одна загвоздка - если приложение не запускается, как оно может что-то записать?
Большинство ИТ-отделов имеют инструмент мониторинга, который позволяет им следить за своими системами издалека - у Microsoft есть Operations Manager . Таким образом, ваши журналы "сердцебиения" должны хорошо играть с инструментом мониторинга; лучшее место для такого рода журналов - журнал событий Windows. Журнал событий не умирает от вас (как это может делать база данных), его можно прочитать с других компьютеров без необходимости настройки общих файловых ресурсов и т. Д., И он интегрируется из коробки со всеми видами инструментов мониторинга.
Мониторинг сердцебиения может включать:
- Работа началась.
- Работа выполнена, x записей обработано, y квалифицировано, z неквалифицировано
- Исключения и ошибки
Ваш инструмент мониторинга может следить за работой и следить за тем, чтобы "x, y и z" находились в ожидаемых границах.
Также регистрируйте исключения в журнале событий - ваш инструмент мониторинга может сообщить вам, когда что-то пошло не так, без необходимости анализировать файлы журнала каждый день.
Debugging
Конечно, вы также захотите узнать, что происходит, когда что-то идет не так. Обычно это не входит в журнал событий - журналы отладки могут содержать конфиденциальную информацию, и операционная группа редко их использует.
Обычно я записываю журналы отладки на диск, используя скользящий аппендер, чтобы убедиться, что они не занимают слишком много места на диске.
Я обычно регистрирую эти файлы на уровне "INFO", с возможностью переключения на DEBUG через конфигурацию.
То, что вы регистрируете, во многом определяется дизайном приложения. Вы обязательно должны записать «входные» данные, чтобы разработчик мог повторно запустить код с вводом, который вы пытаетесь отладить. Если для запуска процесса требуются внешние данные, также зарегистрируйте эти данные (например, если вы используете веб-сервис для получения информации, которая определяет результат). Я бы не записывал каждый шаг в дереве решений на уровне «ИНФО» - он слишком многословен и его трудно отследить.
Аудит
Если у вас есть требования к аудиту, журнал событий является подходящим местом - вы можете установить безопасность, чтобы данные не могли быть обработаны неавторизованным персоналом.
Я предполагаю, что вы уже используете одну из многих сред ведения журналов - Log4Net - мой любимый.
В комментариях вы упоминаете, что основная цель требования к ведению журнала состоит в том, чтобы иметь возможность отслеживать и объяснять результаты процесса. Я бы не назвал эту «регистрацию» честной - это звучит как первоклассное требование бизнес-сферы, в то время как регистрация обычно выполняется для удовлетворения технических требований. Файлы журналов предназначены для технических специалистов и, как правило, остаются на (защищенной) машине, на которой выполняются задания - ваше требование звучит так, как будто оно обращено к клиенту.
Я бы еще раз посетил дизайн приложения и увидел, как лучше всего удовлетворить требования бизнеса. Существует несколько шаблонов проектирования, которые могут помочь - «Цепочка ответственности» - это удобный способ моделирования дерева решений такого типа, и вы можете легко расширить его, включив в него журнал цепочки.