Scrutor: логирование отменённых HTTP-запросов
Habr ·
Представьте клиент-серверную архитектуру, где фронтенд написан на React, бэкенд — на ASP.NET Core, а для логирования на стороне бэкенда используется NLog . Иногда может происходить следующий сценарий: пользователь находится на веб-странице и выполняет какое-то действие (например, нажимает на кнопку «Обновить»). В этот момент фронтенд присылает HTTP запрос на бэкенд, и по какой-то причине этот запрос начинает долго обрабатываться на бэкенде. В это время пользователь уходит со страницы, браузер присылает отмену запроса, бэкенд получает сигнал отмены ( CancellationToken ), выбрасывается OperationCanceledException , и в логи улетает полноценная ошибка. С точки зрения observability такие логи — чистый шум: это штатная ситуация, ошибки бэкенда тут нет, и реагировать на неё технической поддержке или разработчикам не на что. Но сам факт таких логов — это проблема: они засоряют файлы, на основе которых строятся отчёты о работоспособности системы, и приучают команду игнорировать алерты («опять эти отмены»). Рассказываю, почему стандартные фильтры NLog или кастомные Middleware не решают эту проблему системно. Разбираем, как с помощью библиотеки Scrutor динамически декорировать ILoggerProvider и глушить логи отмен на уровне рантайма без размазывания try/catch по контроллерам. Внутри — анализ подводных камней, бенчмарки и ссылка на репозиторий с тестами. Читать далее