Какой лучший способ управлять регистрацией ошибок для исключений?

13

Вступление

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

И если у вас много систем, вы не хотите, чтобы эта информация была разбросана по сторонам - хорошо, если бы для нее было единственное централизованное место.

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

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

Здесь я имею в виду регистрацию ошибок / исключений на уровне кода удаленной системой, а не отслеживание проблем «на основе человека», например, с помощью Jira, Trac и т. Д.


Вопросов

Я ищу мысли от разработчиков, которые использовали этот тип системы, особенно в отношении:

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

Например, я бы сказал, что функция «show duplicates», которая идентифицирует многократное возникновение ошибки (не беспокоясь о «неважных» деталях, которые могут отличаться), очень важна.
Кнопка «создать проблему в [Jira / etc] для этой ошибки» звучит как хорошая экономия времени.

Просто повторюсь, что я хочу узнать о практическом опыте людей, которые использовали такие системы, желательно, чтобы они подкреплялись тем, почему функция удивительна / ужасна.
(Если вы все равно собираетесь теоретизировать, по крайней мере отметьте свой ответ как таковой.)

Питер Боутон
источник
2
Помните одну вещь: если вы что-то регистрируете, что-то пошло не так, и может быть не так, как надо. Храните действия регистрации на простой стороне.
Дэвид Торнли
регистрация на уровне отладки или информации не обязательно означает, что что-то не так. Например, он может содержать информацию, необходимую для посмертного анализа.
Я видел регистраторы исключений, которые сами генерируют исключения на String.Format (C #) :). Сохраняйте журнал простым, желательно без риска, НЕ динамическим (например, не анализируйте файл XML, когда вы пытаетесь зарегистрировать исключение). Избегайте динамизма в журнале ошибок, если можете. Если у вас есть файлы, сконфигурированные в XML-файле, я думаю, что лучше генерировать некоторый реальный код на его основе (сплошной), чем анализировать этот конфигурационный файл во время выполнения, пока вы находитесь в процессе сообщения об ошибке (динамический ). Это был мой опыт в любом случае. Возможно, вы захотите иметь план B для ведения журнала - если сложный вывод завершится неудачно, ведите журнал просто
Задание

Ответы:

5

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

Я рекомендую вам проверить библиотеку Microsoft Enterprise и Log4Net .

Некоторые особенности Log4Net

  • Поддержка нескольких фреймворков
  • Вывод на несколько целей регистрации
  • Иерархическая логирование
  • Конфигурация XML
  • Динамическая Конфигурация
  • Контекст ведения журнала
  • Проверенная архитектура
  • Модульная и расширяемая конструкция • Высокая производительность и гибкость
Амир Резаи
источник
1
хороший регистратор позволит вам сохранять ошибки на ваш выбор (электронная почта, БД, файл и т. д.).
Кен Хендерсон
1

В случае приложений базы данных - какой-то идентификатор (например, <TABLE>:<PrimaryKeyID>), который позволяет отслеживать записи в базе данных, относящиеся к области, в которой было отловлено исключение.

Я сделал это с Oracle и PL / SQL, записав идентификатор в таблицу базы данных в приложении, из обработчика исключений.

Мигель Велосо
источник
Определенно хорошо записать хотя бы таблицу и обрабатываемые записи. Еще лучше, конечно, попытаться выполнить оператор SQL (и любые параметры).
Питер Боутон
1

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

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

  • Группировка одних и тех же ошибок (т. Е. 100 пользователей все испытали одну и ту же ошибку в одно и то же время - это 1 отчет об ошибке с указанием количества возникших ошибок)
  • Автоматическая подача заявки в трекер (никогда не удавалось сделать это «одним нажатием кнопки», но всегда хотел)
  • Имя пользователя программного обеспечения (не только машина, которая доступна в большинстве регистраторов). В некоторых случаях автоматические учетные записи пользователей вызывали проблемы, в то время как в других причиной проблем были конкретные пользователи. «Мне нужно посмотреть, как Майк выполняет какую-то работу, он продолжает вызывать конкретную ошибку».
  • «Действия пользователя» - у меня был глобальный стек, который отслеживал бы каждое действие / нажатие кнопки, когда пользователь делал это, и привязывал его к журналам ошибок. Воспроизведение ошибки часто было случаем обхода этой трассы и выполнения тех же шагов, что и пользователь (я надеялся создать тестовый генератор CodedUI, который бы анализировал трассировку и выполнял шаги автоматически, но никогда не делал)
Стивен Эверс
источник
0

Иногда информация журнала слишком объемна для хранения на диске. Один из подходов, которые я видел, состоит в том, чтобы записать ваши записи в журнал в firehose (скажем, в perl) примерно так:

# Create socket.
my $sock = IO::Socket::INET->new(
    Proto       => 'udp',
    PeerAddr    => $bcastaddr,
    Broadcast   => 1,
) or die "Can't create socket ($bcastaddr): $!";

while (<>) {
    chomp;
    unless (/File\ does\ not\ exist:/) {
        $sock->send("$eventtype:$_") or warn "Can't send: $!";
    }
}

тогда аналитик может выяснить, что он / она хочет посмотреть.

leed25d
источник
3
Не уверен, что такое «пожарный шланг»? Учитывая сегодняшнюю емкость дисков, я надеюсь, что ошибки не будут настолько распространены, что размер журнала будет проблемой.
Питер Боутон
0

Вот что я узнал из мониторинга ошибок в наших приложениях:

  • Возможность привязки файла скользящего журнала (я обычно использую log4net / log4j для входа в приложения и BareTail для отслеживания журнала) очень полезна для проверки текущего состояния системы.
  • Чтобы увидеть, когда возникли проблемы и как часто возникают проблемы, было бы неплохо иметь их в базе данных с временными метками, чтобы вы могли запускать отчеты.
  • Возможность отправлять электронные письма / смс / голосовые оповещения очень полезна для обеспечения работоспособности систем, но вы должны иметь возможность легко настроить типы ошибок, которые вас предупреждают. Если вы получаете 800 сообщений об ошибках в день, вы обязательно пропустите сообщение «О, нет, центр обработки данных горит».

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

aubreyrhodes
источник
0

elmah - это система регистрации ошибок с открытым исходным кодом для приложений ASP.NET, которую можно быстро и легко добавить в существующую систему (используя NuGet http://nuget.codeplex.com/ ). Он поддерживает различные бэкэнды и функции уведомлений.

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

http://code.google.com/p/elmah/

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

После того, как ELMAH был добавлен в работающее веб-приложение и настроен соответствующим образом, вы получаете следующие возможности без изменения одной строки кода:

  • Регистрация почти всех необработанных исключений.
  • Веб-страница для удаленного просмотра всего журнала перекодированных исключений.
  • Веб-страница для удаленного просмотра полной информации о любом зарегистрированном исключении, включая цветные следы стека.
  • Во многих случаях вы можете просмотреть исходный желтый экран смерти , созданный ASP.NET для данного исключения, даже с customErrorsвыключенным режимом.
  • Уведомление по электронной почте о каждой ошибке в момент ее возникновения.
  • RSS-лента последних 15 ошибок из журнала ...
Бил Симсер
источник
ELMAH ненадежен. Если httpcontext имеет значение NULL ==> boom
затруднение
@ Задумка Интересно, я что-то упустил? Мы видим ошибку при попытке войти в ELMAH из приложения, и HttpContext имеет значение null, но если у вас есть уловка корневого уровня -> создайте новый регистратор elmah с нулевым контекстом и журналом, тогда он работает нормально. Есть ли места на обычном веб-сайте ASP.NET, в которых он может попытаться войти, и HttpContext имеет значение null?
Ян Грейнджер