Який найкращий спосіб керувати реєстрацією помилок за винятками?

Вступ

Якщо на веб-сайті або в системі з’являється помилка, звичайно, корисно її зареєструвати та показати користувачеві ввічливе повідомлення з посилальним кодом на помилку.

І якщо у вас багато систем, ви не хочете, щоб ця інформація була пунктированою навколо - добре мати єдине централізоване місце для неї.

На найпростішому рівні, все, що потрібно, - це приріст ідентифікатора та серіалізований дамп даних про помилку. (І, можливо, "централізоване місце" - це поштова скринька.)

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

Я маю на увазі тут реєстрацію помилок / винятків на рівні коду за допомогою віддаленої системи, а не відстеження проблем на основі "людини", таких як Jira, Trac тощо.

Запитання

Я шукаю думки розробників, які використовували цей тип системи, зокрема стосовно:

• Які найважливіші риси, без яких ви не могли б обійтися?
• Які корисні функції, які дійсно заощаджують ваш час?
• Які функції можуть здатися гарною ідеєю, але насправді вони не такі корисні?

Наприклад, я б сказав, що функція "показати дублікати", яка визначає багаторазове виникнення помилки (не турбуючись про "неважливі" деталі, які можуть відрізнятися) є досить важливою.
Кнопка "створити проблему в [Jira / тощо] для цієї помилки" звучить як непогана економія часу.

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

Я брав участь у проекті, де зафіксовано помилки клієнта за допомогою бібліотеки Microsoft Enterprise . Усі винятки, де надсилаємо на нашу поштову скриньку. У тему пошти ми додали хеш-код серіалізованої помилки для уникнення дублювання повідомлень. Звичайно, можна зберігати серіалізовані повідомлення в базі даних тощо.

Рекомендую переглянути бібліотеку Microsoft Enterprise та Log4Net .

Деякі особливості Log4Net

• Підтримка декількох фреймворків
• Виведення на кілька цілей реєстрації
• Ієрархічна архітектура журналів
• Конфігурація XML
• Динамічна конфігурація
• Контекст журналу
• Перевірена архітектура
• Модульна та розтяжна конструкція • Висока продуктивність та гнучкість

Що стосується програм для баз даних, якийсь ідентифікатор (подібний <TABLE>:<PrimaryKeyID>), який дозволяє відслідковувати записи в базі даних, пов'язані з областю, де було вилучено виняток.

Я робив це за допомогою Oracle і PL / SQL, записуючи ідентифікатор у таблицю бази даних в рамках програми, від обробника винятків.

Значна частина того, що ви описуєте (тобто конкретні частини ведення журналу), реалізовано в бібліотеці підприємств, як зазначив Амір Резай. Все інше, здається, є більшою частиною аналітики (тобто що робити з журналами згодом).

У моєму випадку я створив невеликі програми та сценарії sql, які полегшили деякі речі. Ось деякі речі, які мені дуже сподобалися:

• Згрупування однакових помилок разом (тобто 100 користувачів усі відчували одну і ту ж помилку за один і той же час - 1 звіт про помилку із зазначенням кількості випадків)
• Автоматична подача квитка у трекер справи (ніколи не вдавалося зробити це "одним натисканням кнопки", але завжди хотіла)
• Ім'я користувача користувача програмного забезпечення (не лише машини, яка доступна у більшості реєстраторів). У деяких випадках автоматизовані облікові записи користувачів викликали проблеми, тоді як в інших конкретні користувачі були причиною проблем. "Мені потрібно спостерігати, як Майк виконує якусь роботу, він продовжує викликати конкретну помилку".
• "Дії користувача" - у мене був глобальний стек, який би відслідковував кожне дійсне натискання / натискання кнопки, як це робив користувач, і це було застосовано до журналів помилок. Повторення помилки часто було випадком проходження цього сліду та виконання тих же кроків, що і користувач (я сподівався створити тестовий генератор CodedUI, який би проаналізував трасування і виконав кроки автоматично, але ніколи не робив)

Іноді інформація журналу є занадто об'ємною, щоб зберігати її на диску. Я бачив один із підходів - написати свої записи в реєстрації до 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: $!";
    }
}

тоді аналітик може схопитися на те, що він / хто хоче подивитися.

Ось які речі я дізнався з моніторингу помилок у наших програмах:

• Можливість підключення файлу журналу, що перекочується (я зазвичай використовую log4net / log4j для входу в додатки, а BareTail - для того, щоб слідкувати за журналом) - це дуже корисно для того, щоб можна було перевірити поточний стан системи
• Щоб побачити, коли були введені проблеми та швидкість, з якою виникають проблеми, непогано мати їх у базі даних із часовими позначками, до яких можна запускати звіти.
• Можливість надсилати електронну пошту / sms / голосові сповіщення дуже корисна для забезпечення того, щоб системи залишалися в режимі роботи, але ви повинні мати можливість легко налаштувати типи помилок, які вас попереджають. Якщо ви отримуєте 800 електронних листів із помилками в день, ви обов'язково пропустите "О, центр обробки даних не працює".

Я мав чудові результати для log4net, тому що він дуже просто реєструється в декількох місцях і легко змінює конфігурацію журналу.

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 помилок з журналу ...