Як мені впоратися з відмовами реєстратора?

У кількох програмах нашої компанії ми використовуємо користувальницький реєстратор. Він досить надійний, хоча ми можемо замінити його чимось на зразок NLog у майбутньому. Одне з завдань реєстратора - реєструвати будь-які винятки, що зустрічаються в програмі.

Одно з проблем, які я завжди мав, - це те, що обробка винятків у лісорубіжчику забезпечує беззвучний збій. Тобто, якщо журнал не записується за певним винятком (через помилку в реєстраторі), як я повинен обробляти його та (якось) реєструвати виняток у самому реєстраторі ?

Скажімо, функція WriteLog кидає виняток. Чи варто спробувати викликати функцію кілька разів або поки виняток не буде кинутий? Чи варто спробувати написати викинутий виняток за допомогою реєстратора (що, швидше за все, призведе до виключень у всьому напрямку вниз ...)? Мені пощастило не стикатися з цією ситуацією, за винятком випадків, коли ми вперше впроваджували користувальницький реєстратор. З іншого боку, на даний момент я не можу знати, чи не вдалося реєструвати винятки програми (через власні винятки).

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

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

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

• Ви можете застрягти у тимчасовій петлі, генеруючи тисячі винятків за секунду. Уявіть, що ви повідомляєте про винятки на віддалений сервер. Проблема з сервером спричиняє ще одне виключення, яке спричиняє ще одне тощо, поки з'єднання не повернеться.

Що замість цього потрібно зробити, це відмовитися до безпечнішого способу реєстрації винятків. Наприклад, якщо ваш реєстратор надсилає винятки на віддалений сервер, надішліть винятки всередині журналу syslog. Якщо ваш реєстратор записує винятки в Windows Events і ця дія виходить з ладу, зберігайте виняток відмови у простому текстовому файлі.

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

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

Якщо ведення журналу є критичним для вашої програми, слід зупинити програму, якщо ведення журналу не вдається.

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

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

В ідеалі краще відмовитись від беззвучності, оскільки це зробить додаток менш складним.

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