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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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