Какое ведение журнала является хорошим ведением журнала для вашего приложения?

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

Затем упростите настройку уровня ведения журнала, чтобы настроить необходимый уровень детализации. Обычно уровень ведения журнала устанавливается в файле конфигурации, а затем останавливается и перезапускается приложение.

Я бы также сообщил разработчикам, что означает каждый из уровней.

edit: Я бы также установил систему для ротации, сжатия и архивирования файлов журналов на регулярной основе, возможно, каждую ночь.

Для типичного настольного приложения я бы сохранил все в текущем сеансе и, возможно, сохранил бы информационные сообщения за последние n сеансов или размером до x.

Я предполагаю, что ваши сообщения организованы. Мы используем 4 категории; ошибки, предупреждения, информация и трассировка. Мы все еще выясняем, что происходит на каком уровне. Когда я привыкаю к ​​синтаксическому анализу файлов журналов, я обычно говорю «регистрировать больше». Не беспокойтесь о читабельности, вам, вероятно, придется немного обработать файл журнала, прежде чем вы сможете его использовать.

В конце концов, найдите хороший фреймворк для ведения журнала, который позволит вам контролировать использование буфера в течение срока службы и места для хранения, а также подходящий API, который минимизирует влияние на ваш код. В идеале вы просто набираете info("waaah") или warning("waah"), и API делает за вас все причудливые теги.

Главное при ведении журнала - хорошее планирование. Я бы посоветовал вам изучить исключение корпоративной библиотеки и блок приложения для ведения журнала (http://msdn.microsoft.com/en-us/library/cc467894.aspx). Требуется небольшая кривая обучения, но она работает довольно хорошо. Подход, который я предпочитаю на данный момент, заключается в определении 4 уровней приоритета. 4 = необработанное исключение (ошибка в журнале событий), 3 = обработанное исключение (предупреждение в журнале событий), 2 = доступ к внешнему ресурсу, например, к веб-сервису, базе данных или системе мэйнфрейма (информация в журнале событий), 1 = подробный / любой другой представляющих интерес (информация в журнале событий).

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

Обновлять: Для ясности я предлагаю вам войти как в приложение winform / wpf, так и в свои веб-службы. В веб-сценарии у меня в прошлом были проблемы, когда было сложно связать ошибку на клиенте с серверами приложений. В основном потому, что любая ошибка, связанная с веб-сервисами, превращается в исключение SOAP. Я не могу припомнить, но я думаю, что если вы используете настраиваемый обработчик исключений (который является частью корпоративной библиотеки), вы можете добавлять данные в исключения, такие как идентификатор экземпляра обработки исключения с сервера приложений. Это упрощает привязку исключений на клиенте к вашему ящику приложения с помощью LogParser (http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en).

Второе обновление: Мне также нравится давать каждому отдельному событию отдельный идентификатор события и отслеживать его в текстовом файле или электронной таблице в системе управления версиями. Да, это неприятно, но если вам посчастливилось иметь ИТ-команду, которая следит за вашими системами в производстве, я обнаружил, что они склонны ожидать, что разные события будут иметь разные идентификаторы событий.

Is it better to go all the way and log everything across multiple attempts/days, or log only what you need to (given hdd is cheap).

Тот факт, что жесткие диски дешевы, на самом деле не является хорошей причиной для подробного протоколирования всего, что возможно, по нескольким причинам ... Во-первых, с очень загруженным приложением вы действительно не хотите замедлять его и связывать запись на диск журналы (жесткие диски довольно медленные). Второй момент, и более важный: на самом деле очень мало пользы от журналов объемом в терабайты ... Для разработки они могут быть полезны, но вам не нужно хранить их больше, чем несколько минут ..

Некоторое ведение журнала, конечно, полезно, наличие разных уровней - это единственный способ сделать это - например, debug () info () регистрируется только по запросу (в конфигурации или флаге командной строки), затем, возможно, warning () и error () отправляется в файл журнала

Для большинства вещей, которые я написал (небольшие скрипты), у меня обычно просто есть функция debug (), которая проверяет, установлен ли --verbose, и печатает сообщение. Таким образом я могу вставить debug ("some value:% s "% (avar)), когда это необходимо, и вам не нужно беспокоиться о том, чтобы вернуться и удалить отладочные операторы print () где бы то ни было.

Для веб-приложений я обычно использую журналы веб-сервера для статистики и журнал ошибок. Я использую такие вещи, как журнал mod_rewrite, когда это необходимо, но было бы идиотом оставлять это включенным вне разработки (поскольку он создает много строк в каждом запросе страницы)

Я полагаю, это зависит от самого приложения, но обычно для больших приложений используют несколько уровней журналов, которые можно активировать при необходимости. Для более мелких вещей, флаг --verbose или аналогичный, для веб-приложений, журналирование ошибок и (точнее) попаданий в журнал.

По сути, в журнале «производства» только та информация, которую вы можете использовать, в журнале разработки - все, что вам может понадобиться для устранения проблем.

Этот пост на highscalability.com обеспечивает хорошую перспективу ведения журнала в крупномасштабной распределенной системе. (И по совпадению это начинается с упоминания сообщения на JoelOnSoftware).

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

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

Это заставляет меня следить за внешним видом приложения (отвечает ли оно на портах, на которых оно активно, становится ли рабочий набор процессов слишком высоким и т. д.), А не за тем, каково на самом деле состояние приложения.

Пожалуйста, подумайте о людях, которые обслуживают ваше приложение после его развертывания, и предоставьте журналы, которые они могут использовать. Спасибо!

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