Comments 17
Если же у вас происходит какая-то ошибка, то не удобнее ли использовать отладчик? Ну или натыкать несколько console.log, которые сразу же удалить после отладки?
С помощью декоратора Log мы явно помечаем какие именно методы должны быть залоггированы. Никто не обязывает логгировать все, как вы подметили это имеет мало смысла.
Как вы будете использовать отладчик с продакшне? Для того, чтобы понять, что поломалась и при каких условиях, надо какие-то основные моменты жизни того же хттп запроса залоггировать. Эта библиотека призвана сделать именно это. Только вместо того, чтобы писать каждый раз ручками само сообщение, позаботившись о правильном форматировании и сериализации, вы можете делегировать это class-logger
Не очень понятно как это будет работать для того же речь сервера на NodeJS.
Зачастую просто трейса не хватает. Видно, что пришел undefined, но чтобы понять почему пришел undefined, а не ожидаемый объект, зачастую, надо знать как данные менялись в ключевых моментах обработки запроса.
Плюс, в PHP есть проверка типов, которая обычно такие случаи отлавливает рядом с местом возникновения. В JS, кстати, тоже Typescript и Flow есть. Даже если ее нет, вместо малополезного логгирования вы можете проверять, что вернула та или иная функция и выбрасывать исключение, если что-то не так. Чтобы сразу увидеть проблему.
Логгирование, по моему, бесполезная идея. Если у вас на продакшене идет 10 запросов в секунду, у вас же лог будет гигабайт весить к концу дня. Какой смысл записывать столько информации, и кто ее будет разгребать, непонятно.
Единственное, что мне приходит в голову — это отладка взаимодействия с внешними сервисами, которые могут не соответствовать собственной документации и присылать кривые данные. Ну не знаю, все равно тут лучше найти время и разобраться с тем, что они присылают. а не писать гигабайты логов, которые никто не прочтет.
Можно логгировать с разным уровнем, чтобы в той же кибане это удобно фильтровать. Так же можно добавить к запросу traсe ID, чтобы по этому самому trace ID удобно отследить его жизненный цикл. Я и не предлагаю логгировать все, ровно необходимый минимум. Да и если даже логгировать много, при наличии trace ID логи фильтруются на раз.
Дело в том, что если есть касакад из сервисов, которые каким-либо образом данные меняют и передают друг другу, то одного стек трейса может быть мало. Вот сервис №10 плюнул мне ошибкой, что, мол, ждли строку, а пришел undefined. А толку, если у меня до этого данные прошли через 9 других сервисов? Где именно они поломались?
Согласен, reflect-metadata — огромный пакет. Можно заменить его на более легкую альтернативу: https://github.com/abraham/reflection
Дык особо ничего и не поменяется. Просто будем свои навелосепедированные символы в property descriptor добавлять :)
оч удобно когда большое количество асинхроных вызово и не понятно когда что дергается
Круто былобы добавить еще нейм спейсы чтобы легко отключать части прложения от логирования как сделоано вот тут www.npmjs.com/package/debug и крутая фича с треконем времени
Трек времени добавить думаю.
Насчет неймспейсов пока не уверен. Если они вам нужны и нравится как оно работает в debug, то почему бы не использовать debug в качестве логгера более никого уровня вместе с class-logger?
// logger.service.ts
import debug from 'debug'
export const loggerNamespaceA = debug('NamespaceA')
export const loggerNamespaceB = debug('NamespaceB')
...
// cats.service.ts
import { LogClass } from 'class-logger'
import { loggerNamespaceA } from './logger.service'
@LogClass({
log: loggerNamespaceA,
logError: loggerNamespaceA
})
class CatsService {}
github.com/keenondrums/class-logger#formatting
Логгрование ошибок есть.
Сериализованная ошибка включает в себя следующие свойства:
— Имя класса (функции), которая была использована для создания ошибки (error.constructor.name).
— Код (error.code).
— Сообщение (error.message).
— Имя (error.name).
— Стек трейс (error.stack).
Сверхпростое логгирование в Javascript — два декоратора, и готово