Как остановить оповещения об исключениях от перехода в Безерк

Question

Допустим, у вас есть система .NET, которая должна отправлять уведомления по электронной почте системному администратору при возникновении ошибки.Пример:

try
{
    //do something mission critical 
}
catch(Exception ex)
{
    //send ex to the system administrator
    //give the customer a user-friendly explanation
} 

Этот блок кода вызывается различными пользователями сотни раз в секунду.

Теперь допустим, что базовый API / сервис / база данных отключен.Этот код будет много, много раз .Бедный администратор собирается разбудить до нескольких миллионов писем в своем почтовом ящике, а разработчик получит грубый телефонный звонок, не то чтобы такой инцидент (кашель) обязательно произошел сегодня утром.

ЭтоДовольно ясно, что это не тот дизайн, который хорошо масштабируется.

Первые несколько решений, которые приходят на ум, имеют некоторые недостатки:

• Записывают ошибки в базу данных, а затем выставляют большое количество ошибок посредством проверки работоспособности HTTP для внешнего мониторинга.сервис, такой как Pingdom .(Мой любимый кандидат на данный момент. Но что, если база данных выйдет из строя?)
• Имеет статический кэш, который отслеживает недавние исключения, и система оповещения всегда сначала проверяет наличие дубликатов.(Кажется излишне сложным, а во-вторых, многие сообщения об ошибках отличаются очень незначительно - например, если в ошибке есть отметка времени, это бесполезно.)
• Программно отключить нашу систему после определенных ошибок или на основе постоянноймониторинг критических зависимостей (Рискованно! Что, если есть кратковременный ложноположительный результат?)
• Просто не оповещайте об этих ошибках и полагайтесь на другую часть системы, чтобы отслеживать и сообщать о зависимостях.(Не учитывает «неожиданные» ошибки, которых мы не ожидали.)

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

Answer 1

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

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

Answer 2

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

Скажем, есть 1000 исключений типа A, 964 типа B, 120 C и 7 типов D - H.

Это означает, что отправляйте электронное письмо системному администратору каждые 100-е исключение типов A и B, каждое 10-е исключение типа C и любые другие исключения по мере их возникновения.

Pro:
+ Точный
+ Предотвращает системный спам
+ Не так много кода для реализации

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

Answer 3

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

Microsoft добавляет огромное количество информации о шаблонах и архитектуре облачного проектирования - от таких вещей, как микросервисы и служебные шины с очередями сообщений, до мельчайших деталей. Это все на веб-сайте Microsoft Docs , зарегистрированном под Azure Architecture . Конкретным шаблоном, который решает эту проблему, является шаблон Автоматический выключатель .

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

Answer 4

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

Answer 5

Я уже создавал приложения для мониторинга, которые раньше отправляли по электронной почте администраторам, и смущенно признаю, что я был в вашей ситуации.Решением является ограничение вашей электронной почты.Сохраните время последнего сообщения, отправленного куда-либо, и создайте проверку, чтобы проверить, прошло ли минимальное количество времени с момента последнего сообщения до его отправки (скажем, 10 минут или дольше, до вас).Таким образом, максимальное количество писем, которые получит ваш бедный администратор, будет <time issue has been going on> / <period>.В моей предыдущей работе системного администратора это уравновешивало нашу потребность знать, что проблема все еще продолжалась с необходимостью иметь ящик электронной почты, не переполняющийся 1000 электронными письмами в час.