Суть
Фоновые службы аутбокса пишут LogCritical на любой отказ тика, включая транзиентный. Падает при этом один цикл, а не приложение: следующий заход восстанавливается сам. На каждой сетевой икоте БД это будит дежурного на инцидент, которого нет.
Где
Dex.Cap.Outbox.AspNetScheduler/BackgroundServices/OutboxHandlerBackgroundService.cs:67Dex.Cap.Outbox.AspNetScheduler/BackgroundServices/OutboxCleanerBackgroundService.cs:67
Обе ветки ловят catch (Exception ex), пишут LogCritical и продолжают цикл, то есть сами же признают отказ восстановимым.
Почему Error
По определению уровней Microsoft: Error это отказ текущей операции, Critical это отказ, требующий немедленного вмешательства (потеря данных, кончилось место). Отказ одного тика при работающем цикле это первое.
Устойчивый сбой при этом не теряется, и ловит его не уровень лога: пока выборка не доходит до хранилища, признак жизни не обновляется, и health check уходит в Degraded. То есть LogCritical на каждом тике не добавляет сигнала, а только шумит.
Оговорка по чистильщику: у него health check нет, и устойчивый отказ чистки виден только логом. Но и цена его отказа это неприменённый ретеншен (растущая таблица), а не простой: Error тут достаточно.
Как поправлено в инбоксе
LogError с текстом про цикл, а не про приложение: коммит f423389 в PR #230.
Scope
После правки инбокса уровни в двух соседних библиотеках разъехались. Задача заведена в том числе чтобы это расхождение было отслежено, а не осталось незамеченным. Решение «оставить как есть» тоже допустимо, но тогда осознанно и с обратной правкой инбокса.
Суть
Фоновые службы аутбокса пишут
LogCriticalна любой отказ тика, включая транзиентный. Падает при этом один цикл, а не приложение: следующий заход восстанавливается сам. На каждой сетевой икоте БД это будит дежурного на инцидент, которого нет.Где
Dex.Cap.Outbox.AspNetScheduler/BackgroundServices/OutboxHandlerBackgroundService.cs:67Dex.Cap.Outbox.AspNetScheduler/BackgroundServices/OutboxCleanerBackgroundService.cs:67Обе ветки ловят
catch (Exception ex), пишутLogCriticalи продолжают цикл, то есть сами же признают отказ восстановимым.Почему Error
По определению уровней Microsoft:
Errorэто отказ текущей операции,Criticalэто отказ, требующий немедленного вмешательства (потеря данных, кончилось место). Отказ одного тика при работающем цикле это первое.Устойчивый сбой при этом не теряется, и ловит его не уровень лога: пока выборка не доходит до хранилища, признак жизни не обновляется, и health check уходит в
Degraded. То естьLogCriticalна каждом тике не добавляет сигнала, а только шумит.Оговорка по чистильщику: у него health check нет, и устойчивый отказ чистки виден только логом. Но и цена его отказа это неприменённый ретеншен (растущая таблица), а не простой:
Errorтут достаточно.Как поправлено в инбоксе
LogErrorс текстом про цикл, а не про приложение: коммит f423389 в PR #230.Scope
После правки инбокса уровни в двух соседних библиотеках разъехались. Задача заведена в том числе чтобы это расхождение было отслежено, а не осталось незамеченным. Решение «оставить как есть» тоже допустимо, но тогда осознанно и с обратной правкой инбокса.