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

Question

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

Как правило, наш сценарий таков, что вообще не ведется регистрация, и в основном .NET-приложения, winforms / WPF-клиенты общаются через веб-сервисы или напрямую на БД.

Итак, реальный вопрос в том, где или что бы вы регистрировали? В настоящее время у нас есть пользователи, сообщающие об ошибках - так что я бы предположил, что запуск / выключение журнала, исключения ...

Вы принимаете это для звонков на веб-сервисы или дБ? Страница загружается?

Как вы получаете хорошее представление о том, что пользователь пытался сделать в то время?

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

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

Answer 1

Ключевым моментом для ведения журнала является хорошее планирование. Я бы посоветовал вам взглянуть на блок приложения исключений и ведения журналов корпоративной библиотеки (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).

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

Answer 2

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

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

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

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

Answer 3

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

Answer 4

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

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

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

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

Answer 7

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