Pull to refresh

Comments 17

Зачем логгировать все вызовы функций? Это же будет генерировать кучу ненужных сообщений. Вам теперь еще придется делать систему сбора и фильтрации логов. Вы в итоге решаете проблемы, которые сами же себе придумали.И так очевидно, что если функцию вызвать, то она будет вызвана. Для этого не требуется лог.

Если же у вас происходит какая-то ошибка, то не удобнее ли использовать отладчик? Ну или натыкать несколько console.log, которые сразу же удалить после отладки?

С помощью декоратора Log мы явно помечаем какие именно методы должны быть залоггированы. Никто не обязывает логгировать все, как вы подметили это имеет мало смысла.
Как вы будете использовать отладчик с продакшне? Для того, чтобы понять, что поломалась и при каких условиях, надо какие-то основные моменты жизни того же хттп запроса залоггировать. Эта библиотека призвана сделать именно это. Только вместо того, чтобы писать каждый раз ручками само сообщение, позаботившись о правильном форматировании и сериализации, вы можете делегировать это class-logger

UFO just landed and posted this here

Не очень понятно как это будет работать для того же речь сервера на NodeJS.
Зачастую просто трейса не хватает. Видно, что пришел undefined, но чтобы понять почему пришел undefined, а не ожидаемый объект, зачастую, надо знать как данные менялись в ключевых моментах обработки запроса.

Я обычно в PHP просто при возникновении исключения пишу в лог не только исключение (и его стектрейс), но и параметры HTTP-запроса. Соответственно, потом мы можем по этим данным элементарно найти, что это был за запрос, какой контроллер этот запрос обрабатывал и посмотреть по коду, что там могло пойти не так. А если исключения не возникло — значит все в порядке, и логи засорять незачем.

Плюс, в PHP есть проверка типов, которая обычно такие случаи отлавливает рядом с местом возникновения. В JS, кстати, тоже Typescript и Flow есть. Даже если ее нет, вместо малополезного логгирования вы можете проверять, что вернула та или иная функция и выбрасывать исключение, если что-то не так. Чтобы сразу увидеть проблему.

Логгирование, по моему, бесполезная идея. Если у вас на продакшене идет 10 запросов в секунду, у вас же лог будет гигабайт весить к концу дня. Какой смысл записывать столько информации, и кто ее будет разгребать, непонятно.

Единственное, что мне приходит в голову — это отладка взаимодействия с внешними сервисами, которые могут не соответствовать собственной документации и присылать кривые данные. Ну не знаю, все равно тут лучше найти время и разобраться с тем, что они присылают. а не писать гигабайты логов, которые никто не прочтет.

Можно логгировать с разным уровнем, чтобы в той же кибане это удобно фильтровать. Так же можно добавить к запросу traсe ID, чтобы по этому самому trace ID удобно отследить его жизненный цикл. Я и не предлагаю логгировать все, ровно необходимый минимум. Да и если даже логгировать много, при наличии trace ID логи фильтруются на раз.
Дело в том, что если есть касакад из сервисов, которые каким-либо образом данные меняют и передают друг другу, то одного стек трейса может быть мало. Вот сервис №10 плюнул мне ошибкой, что, мол, ждли строку, а пришел undefined. А толку, если у меня до этого данные прошли через 9 других сервисов? Где именно они поломались?

А теперь тоже самое, но не использовать в зависимостях 'reflect-metadata'. Думаю для обучение так же будет самое оно. :)

reflect-metadata здесь peer зависимость. По идее можно использовать предложенную вами альтернативу при желании. АПИ у них вроде совместимый.
Из плюсов reflect-metadata — он уже включён в angular. На стороне же NodeJS размер модуля вообще значения не имеет.

Дык особо ничего и не поменяется. Просто будем свои навелосепедированные символы в property descriptor добавлять :)

Почему не поменяет, как раз наоборот. Так как автор собрал пакет, и написал что он это сделал как для обучения, так и для использования, то почему бы не разобраться с reflect-metadata. Понятно что велосипед, но очень полезный для опыта.
Воистину, Java-программист может написать программу на Java на любом языке программирования
UFO just landed and posted this here
Недавно такуюже штуку хотел написать
оч удобно когда большое количество асинхроных вызово и не понятно когда что дергается

Круто былобы добавить еще нейм спейсы чтобы легко отключать части прложения от логирования как сделоано вот тут 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 {}
Вы можете переопределить formatter и логгировать ровно то, что вам нужно
github.com/keenondrums/class-logger#formatting

Логгрование ошибок есть.
Сериализованная ошибка включает в себя следующие свойства:
— Имя класса (функции), которая была использована для создания ошибки (error.constructor.name).
— Код (error.code).
— Сообщение (error.message).
— Имя (error.name).
— Стек трейс (error.stack).
Sign up to leave a comment.

Articles