Комментарии 12
Да, прикольная библиотека! Пользовался ею ранее. И, наверно воспользуюсь вашей версией в ближайшем будущем.

Мне в старой версии не хватало пары фич:
1. Там есть только ошибки, хотя для анализа часто важно знать последовательность действий пользователя. Т.е. нужна связка подробной информации об ошибке с последовательностью вызов от конкретного пользователя.
2. Часто, при довольно сложной бизнес-логике приложения, важно понимать, каким путём прошла обработка пользовательского запроса и, желательно так, чтобы отслеживался вызов всех методов, да ещё и с параметрами.

Как итог, у нас на прошлой работе было так:
— NLog пишет обычный лог, который можно отфильтровать по логину пользователя
— в Elmah пишется куча всего про ошибку
— Interceptor, встроенный в DI-контейнер, умеет записывать цепочку вызовов и писать в отдельный лог в виде, похожем на код (полное имя метода + ключевые параметры + отступы). Этот лог пишется при ошибке или при активации расширенной трассировки для конкретного пользователя.
Эта связка очень помогала разбираться со сложными кейсами, когда ошибка возникает из-за нестыковок в данных, пришедших от внешних систем.

И ещё, про доступность логов на веб-сайте. Когда я увидел, что эти логи как-то слишком доступны, мы перенастроили все пром-сервера так, чтобы лог elmah был доступен на отдельном сайте с доступностью только из внутренней сети и авторизацией через доменные группы.
В новой версии все что журналируется через ILogger будет доступно на вкладке «Log» у каждой ошибки. Там будут только записи, которые относятся к HTTP сессии в которой произошла ошибка.
Про Interceptor — интересна идея, попробую добавить в следующей версии
Про лог текущего HTTP-запроса я увидел. Это уже лучше, чем было ранее.
С Interceptor есть одна, но большая сложность — его надо отдельно встраивать в DI-контейнер (мы, помимо самого перехватчика, размечали методы атрибутами, через которые определялось и логгирование, и запись в лог значений параметров). И, наверно, это не дело библиотеки. Cтоит оставить эту функцию разработчикам приложений.
А вот в библиотеке пригодится возможность регистрировать другие поставщики логов, данные с которых забираются при записи ошибки.
А можно, пожалуйста, больше технических деталей про DI+Interceptor +разметку аттрибутами? Может быть небольшую статью напишите? С удовольствием почитал бы.
Может и напишу. Надо только старый код привести в порядок…
Distributed Tracing — это про другое (про связь логов нескольких взаимодействующих приложений).
Мы делали подробный лог внутренних вызовов в приложении.

Интересный вариант для случаев, когда нет ресурсов на ELK+Sentry.
А в структурированные логи эта штука умеет?

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.