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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

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

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

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

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

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

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

Ответ 7

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