Использовать более production-ready логгер

[olgaklimenko]

Поресерчить, какой логгер можно использовать вместо co-log и подключить его.

[olgaklimenko]

@stanislav-az предлагает попробовать katip.

[chshersh]

Как одному из авторов co-log, мне было бы интересно узнать, что мешает ему быть production-ready в рамках данного проекта или каких фич не хватает 🙂
Я вижу, что в данном модуле довольно неплохая реализация логики логирования! 👏🏻

• https://github.com/fullstack-development/haskell-starter-kit/blob/master/src/Ext/Logger/Colog.hs

[kelizarov]

@chshersh Привет, классно видеть авторов в обсуждении :)

Мы тут с командой пообсуждали и составили небольшой список из пунтков, которые нас не устроили чтобы мы бы смогли полностью в продакшене дальше продолжать использовать:

1. Не удобно прокидывать контекст. Очень часто приходится логировать вещи, которые не приходят из пустого IO, а например из запроса на сервер. Форматтер, который работает внутри LoggerT, может модифицировать лог только с ByteString, и как-то на-ходу его менять становится трудно. Приходится контекст задавать перед тем как начинаешь его использовать;
2. Хотелось бы иметь совместимость с monad-logger из коробки;
3. Работает только с mtl стиль. На практике выходило так чтобы логгировать несколько подсистем (логи приложения + логи бд от persistent) мы должны были использовать 2 трансформера, просто чтобы делать одно и то же. Возможно мы тут затупили, но для прода у нас не было времени разбираться. К тому же для запуска логов другой подсистемы приходилось таскать контекст руками, из-за чего код становился очень запутанным;
4. Не хватает инстансов по типу instance MonadThrow m => MonadThrow (LoggerT msg m) для LoggerT.
   Констрейнт который мы можем указать вместо MonadThrow, к примеру, это MonadIO, но этот констрейнт иногда дает слишком много свободы, и хотелось бы ограничить возможные эффекты по-другому;
5. Тип LogAction можно использовать только внутри обертки трансформера (создавая свой или используя LoggerT) , иначе можно получить бесконечную рекурсию внутри типа: recursiveM = ReaderT (LogAction recursiveM msg) m a
   
   вот это вызывает бесконечную рекурсию

/home/stanislav/fsd/haskell-starter-kit/src/AppName/Server.hs:76:3: error:
    • Reduction stack overflow; size = 201
      When simplifying the following type:
        LT.LoggerT (Log.Msg Log.Severity) IO
      Use -freduction-depth=0 to disable this check
      (any upper bound you could choose might fail unpredictably with
       minor updates to GHC, so disabling the check is recommended if
       you're sure that type checking should terminate)
    • In the expression:
        hoistServerWithContext
          apiType (Proxy :: ProtectedServantJWTCtx)
          (Handler . ExceptT . try . (( \ x_ -> runReaderT x_ env)))
      In an equation for ‘hoistServerHandler’:
          hoistServerHandler env
            = hoistServerWithContext
                apiType (Proxy :: ProtectedServantJWTCtx)
                (Handler . ExceptT . try . (( \ x_ -> runReaderT x_ env)))
   |
76 |   hoistServerWithContext
   |   ^^^^^^^^^^^^^^^^^^^^^^...

[chshersh]

@kelizarov Спасибо за подробный ответ! Действительно, есть над чем подумать и над какими улучшениями поработать. Я постараюсь прокомментировать каждый отдельный пункт.

1. Трудно что-то конкретное посоветовать без примера кода. Но если у вас есть какие-то улучшения, как сделать форматтер более гибким, то буду рад выслушать 🙂

2. Я вижу, что в monad-logger основная функция имеет следующий тип:

   monadLoggerLog :: ToLogStr msg => Loc -> LogSource -> LogLevel -> msg -> m ()

   Это эквивалентно тому, чтобы просто иметь LogAction из co-log с типом ToLogStr msg => LogAction m (Loc, LogSource, LogLevel, msg). Тогда, если такой LogAction хранится в энвайронменте монады приложения, сделать инстанс monad-logger для своей монады тривиально, и можно пользоваться всеми преимуществами пакета monad-logger. Инстанс MonadLoggerIO может быть сделать сложней, если монада приложения нетривиальная, но я отвечу на этот вопрос ниже в сообщении. Конечно, я понимаю, что иметь все эти утилиты из коробки было бы удобней, чем самому каждый раз в новом проекте писать одни и те же несколько строк. Поэтому создание пакета вроде co-log-monad-logger звучит как неплохое улучшение экосистемы 👍🏻

3. (а также 4 и 5)

   Пожалуй, это идёт из давних времён, когда mtl стиль был доминирующем и было канонично для каждого "эффекта" создавать свой трансформер. На практике же, монаду LoggerT из co-log никогда не стоит использовать (больше проблем, чем бенефитов), и, пожалуй, надо будет добавить очень явную документацию про то, как использовать co-log. Рекомендуемый подход — это использовать co-log с кастомной монадой, как описано в следующем туториале:

   • Использование co-log с кастомной монадой

   По сути, основная монада приложения реализует паттерн RIO. Она является newtype, поэтому окружение можно параметризовать самой же монадой. Реализовать LoggerT как саморекурсивную type family всё равно не получится (но наверное в этом и нет острой необходимости?).

   Можно найти больше примеров архитектуры бекенда в нашем фреймфорке для бекенда веб-приложений cake-slayer:

   • CakeSlayer.Monad: абстракция основной монады приложения
   • CakeSlayer.Error: хэндлинг ошибок с сохранением информации о локации
   • CakeSlayer.Has: Has-паттерн для доступа к элементам окружения

   Логирование нескольких подсистем можно осуществить через алгебраические инстансы для LogAction. Логирование одновременно в несколько разных мест можно сделать при помощи инстанса Semigroup. А логирование в разные подсистемы в зависимости от типа сообщения можно сделать, используя инстанс Decidable (или похожие идеи). Например, следующий gist демонстрирует, как логировать в stdout и в DB одновременно, в зависимости от Severity логируемого сообщения:

   • Логирование в stdout и DB

Надеюсь, мы ответы были полезными, и они помогут вам в улучшении архитектуры вокруг логирования, какую бы библиотеку вы не выбрали в итоге 😊