Comments 10
Есть метод проще
https://github.com/vescon/MethodBoundaryAspect.Fody
Делаешь атрибут Log или WithLogging
В OnException вызываешь логирование.
В чем плюс Fody -
Навешиваешь атрибут Log на методы,
Бери все сервисы прямо из контейнера\откуда угодно,
Не нужно создавать никаких оберток для классов.
Единственное, что можно улучшить - сделать свой Weaver для оборачивания всех public методов по атрибуту уже на классе. (для тех кто любит писать код на C# как есть - Класс с логированием, Интерфейс с регистрацией реализаций в контейнере вот так, и т.д)
Вы не работаете с БД? Текстовые файлы парсить чтобы что-то там найти... Ну такое себе.
Есть ли у вас уровни логирования?
У нас есть отдельный сервис логирования. Поскольку вся работа у нас идет с БД, то и лог - это отдельная таблица в БД.
Каждая запись содержит
т.н. "узел логирования" - некий литерал, означающий к какому модулю (или части модуля) относится эта строка,
временную метку,
служебную информацию (это уже платформо-специфическое - номер задания, пользователь задания...)
уровень логирования (сейчас три уровня - ошибка, бизнес-сообщение, трейс)
ключ - произвольная информация для быстрого поиска. Например, идентификатор клиента - можно сделать выборку по узлу логирования и идентификатору клиента чтобы понять что было при его обработке
точка вызова - произвольный литерал, позволяющий идентифицировать в каком именно месте случилось событие.
собственно блок логируемой информации
Это основная таблица. Есть еще дополнительная таблица дополнительной информации для каких-то объемных данных. Она не обязательная, но, к примеру, если нужно скинуть в лог полный образ записи, то в основную таблицу пойдет запись с ключевой информацией, а полный образ обрабатываемой записи где случилась ошибка пойдет в дополнительную таблицу.
Плюс есть настроечная таблица где каждому узлу логирования сопоставляется допустимый уровень. Например, если для узла 'ABC' прописан уровень 'E', то в лог будут записываться только сообщения с уровнем 'E' - ошибки. Все остальное будет игнорироваться. А если поменять 'E' на 'T', то будут писаться все сообщения - ошибки, бизнес-сообщения, трейсы... Это позволяет "на лету" включать или выключать вывод в лог нужной информации. Т.е. когда в коде прописано логирование и ошибок, и бизнес-сообщений и трейсов, через настройки можно управлять что реально будет писаться в лог, а что нет.
Там же в настройках хранится глубина хранения для каждого узла логирования и каждого типа сообщений. Скажем, для узла 'ABC' ошибки хранятся неделю, бизнес - три дня, трейсы один день. Это для модуля прочистки логов который запускается раз в сутки.
Ну и поскольку все это хранится в БД, то не нужен никакой парсер - вся работа с логами делается скулем.
И лог - не на один какой-то модуль, а на "проект" содержащий сотни если не тысячи модулей (выборка нужной информации делается по узлу логирования, времени, полю ключевой информации...). И выборку можно сразу делать как по основной, так и по дополнительной таблице.
Все, что вы описали - крайне избыточно.
Большинство так называемых логгеров сами кладут все в БД.
Поиск обычно осуществляется ElasticSearch и подобными.
Хранение логов - ну сделать джоб - удалять Warning-и и Info раз в месяц\неделю.
(А Exception-ы мониторит DevOps, и заводит тикеты)
Сейчас HDD дешевые, можно логи вообще не чистить.
Хотя я видел команды, которые зачем-то заводят отдельную таблицу логов чуть ли не на каждый модуль(со своими таблицами), чтобы смотреть ошибки. (А не просто используют ChangeTracking для записи изменений обьектов в журнал, и отдельный журнал для событий).
Ага. Сколько может стоить 400Tb SSD Array?
И где его можно купить?
И глубина хранения для разных типов сообщений может быть разная. Тут еще требования бизнеса могут быть. Сталкивался с тем, что бизнес говорит что им какая-то история по какому-то конкретному модулю нужна год. В том и дело, что лог - это не только ошибки.
По ошибкам с прода идет рассылка ежедневная типа:
Но бывают ситуации когда нужно попросить сопровождение чтобы на короткий период времени для какого-то узла включили трейсинг, а потом сделали выгрузку (или сами на тестах можем использовать трейсинг, а в пром выкатывать с уровнем логирования "только ошибки"). Чтобы понять что там происходит (если вдруг происходит что-то не то). А потом выключили обратно чтобы не раздувать лог (чем больше таблица, тем выше накладные расходы на поддержание ее индексов - неоправданно большие таблицы могут производительность системы в целом снижать).
И ошибка - это не обязательно падение всего и вся. И не обязательно ошибка в коде.
Это может быть ошибка в данных вследствие которой они не проходят через соответствующий модуль валидации. Например. Это тоже требует внимания.
И каждая команда обычно делает свой лог, со структурой, соответствующей своей специфике того, с чем они работают. Когда-то была идея универсального сервиса логирования, но изжила себя когда попытались свести воедино требования всех команд (которых не один десяток).
А БД избавляет от необходимости 400 Tb SSD?
Вы же сами показали - у Вас один текст, и события - раз в два часа.
Текст в таблице и текст в JSON - разница процентов 10.
Раз в два часа - это то, что залогировалось когда все хорошо и ошибок мало.
А если что-то случается ("дефект промсреды"), то там может быт сразу тысячи записей. Или если трейс потребовалось включить. Когда трейсится все подряд практически чтобы понимать где именно что пошло не так (в штатном режиме это не нужно - только производительность снижает - я потому и спрашивал - поддерживаются ли уровни логирования и управление ими в реальном времени).
JSON - это вообще для тех приложений где не требуется высокая производительность. Слишком большие накладные расходы на кодирование-декодирование. У нас практически не используется в принципе.
А если надо - есть таблица допинфо куда можно просто сбросить образ записи или какой-то дамп as is. Правда, извлекать его оттуда уже потребуется специальным образом - это фактически BLOB. Но это в особо тяжелых случаях используется. В 99% случаев для расследований инцидентов хватает текста.
А для повышения производительности есть в модуле логирования AllowLog которая проверяет разрешен ли данный уровень для данного узла - нужно ли тратить время на формирование сложного текста.
Как альтернатива еще есть возможность выводить трейсы в очередь сообщений (*msgq - есть у нас на платформе такие системные объекты). Там вообще в реальном времени видно что происходит. В одном задании работает модуль, в другом мониторим соответствующую очередь сообщений и сразу видим что туда летит. Но это скорее отладочное, когда отладчиком сложно или невозможно подлезть (например, не доступа для отладки в нужном юните или есть какие-то таймауты которые под отладчиком не соблюдаются).
Вообще, принципы логирования которые используем, формировались не один год методом проб и ошибок. Есть общие требования, но формат логов в разных случаях может быть разный. Где-то хватает общего, а где-то приходится делать что-то особенное т.к. общий уже не подходит.
Я советую ElasticSearch потому что там есть шардинг - поднял на нескольких серверах и хоть 20 Гб\сек ошибок пиши.
Это - идеальный случай для 1 системы (пусть даже с сайтом/WPF и еще командами по шине).
Для локального логирования простых приложений - обычно все в таблицу\файл (или что там у логгера есть).
Проблема в том, что поиск что по БД, что в ElasticSearch скорее всего по скорости одинаковый. Последний разворачивается просто и поддерживает горизонтальное масштабирование.
авторизация\аутентификация - есть в ElasticSearch.
А вот специфических проверок и интерфейсов для логирования - нет.
Тут клиент-серверное приложение, как у вас.
grep/tail -f/less. По удобству до этого ни эластик, ничего, не добрались до этой тройки).
При записи в файл есть такая вещь как контекст, в бд поиск работает совсем не так, не говоря уже о накладных расходах.
Ну и вполне себе нормальная практика - писать логи в файл, а потом асинхронно качать их уже куда надо.
C#, Логи которые пишут себя сами