(Windows) Обработка исключений: в журнал событий или в базу данных?

Question

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

У каждого есть свои достоинства, некоторые из которых я могу выделить на основании своего опыта:

Журнал событий

• Стандартное местоположение для исключений (+)
• Простота регистрации (+)
• Здесь можно регистрировать проблемы с подключением к базе данных (+)
• Может создавать отчеты и просматривать приложения поверх журнала событий (+)
• Нужно часто стирать, если о нем много сообщается (-)
• Не так расширяемо, как ведение журнала SQL [добавить настраиваемые поля, такие как имя метода в SQL] (-)

SQL / баз данных

• Может обрабатывать большие объемы данных (+)
• Может обрабатывать быстрые объемные вставки исключений (+)
• Одно хранилище для исключения в среде с балансировкой нагрузки (+)
• Очень настраиваемый (+)
• Немного проще создавать отчеты / уведомления из хранилища SQL (+)
• Отличается от того, где хранятся типичные исключения (-)

Я что-то упускаю из виду?

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

Answer 1

Необходимо различать ведение журнала и трассировку. В то время как строки немного размыты, я склонен думать о регистрации как о «не разработчике». Такие вещи, как необработанные исключения, поврежденные файлы и т. Д. Это определенно не нормально и должно быть очень редкой проблемой.

Отслеживание - это то, что интересует разработчика. Трассировки стека, параметры метода, что веб-сервер вернул HTTP-статус 401.3 и т. Д. Они действительно шумные и могут за короткое время произвести много данных. , Обычно у нас есть разные уровни трассировки, чтобы уменьшить шум.

Для входа в клиентское приложение я думаю, что журналы событий - это путь (я должен был бы перепроверить, но я думаю, что ASP.NET Health Monitoring также может записывать в журнал событий). Обычные пользователи имеют права на запись в журнал событий, если у вас есть программа установки (которая в любом случае установлена ​​администратором) для создания источника события.

Большинство ваших преимуществ для ведения журнала Sql, хотя и имеют значение true, не применимы к ведению журнала событий:

• Может обрабатывать большие объемы данных: У вас действительно большие объемы необработанных исключений или других сбоев высокого уровня?
• Может обрабатывать быстрые вставки томов исключений: Одно необработанное исключение должно привести к остановке вашего приложения - оно изначально ограничено по скорости. Другие интересные события, не относящиеся к разработчикам, должны быть агрегированы аналогичным образом.
• Очень настраиваемый: Сообщение в журнале событий в значительной степени свободный текст. Если вам нужна дополнительная информация, просто укажите на текстовый или структурированный XML или журнал двоичных файлов
• Немного проще создавать отчеты / уведомления из хранилища SQL: Отчеты встроены с помощью средства просмотра журнала событий, и системы уведомлений либо присущи - из-за сбоя приложения - либо смешаны с другими действительно важными уведомления - есть небольшое оправдание для пропуска сообщения журнала событий. Для корпоративных или других сетевых приложений существует тысяча и 1 другое приложение, которое уже отбирает журналы событий на наличие ошибок ... есть вероятность, что ваш системный администратор уже использует его.

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

90% времени, они вам не нужны, и они установлены на WARN или ERROR. Но когда вы установите для них значение INFO или DEBUG, вы сгенерируете ton данных. СУБД имеет много накладных расходов - на производительность (ACID, параллелизм и т. Д.), Хранение (журналы транзакций, диски SCSI RAID-5 и т. Д.) И администрирование (резервное копирование, обслуживание сервера и т. Д.) - все это не требуется для журналов трассировки.

Answer 2

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

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

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

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

Answer 3

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

Минусом ведения журнала на основе SQL является то, что он добавляет еще один уровень зависимостей в ваше приложение, что может быть или не всегда приемлемым. Я сделал оба в моей карьере. Раз или два я даже использовал очередь сообщений на основе MSMQ, чтобы ставить в очередь события журнала и очищать очередь в базе данных MSSQL, чтобы исключить необходимость подключения моего клиентского программного обеспечения к БД.

Answer 4

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

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