refactor all log messages to use same format, overhaul logExtension #190
Conversation
| update.trackSid, | ||
| ); | ||
| log.warn('received subscribed quality update for unknown track', { | ||
| method: 'handleSubscribedQualityUpdate', |
There was a problem hiding this comment.
I see you are using method here as an indicator. I am guessing this log line is unique and does not need context. But, it would be nice to have file/line/function name in some way. Not sure that is even possible with TS.
There was a problem hiding this comment.
when piping out logs we will unfortunately lose native line number indicators.
The workaround to get a stacktrace would be to throw an Error manually and look at its trace.
For file and method names other loggers have the concept of childloggers, which would allow to have an own logger for each file and have that info (e.g. filename) be part of the context object automatically.
For now I didn't swap out the underlying logging library we are using, but we could either just use a different one or provide some functionality like that ourselves
There was a problem hiding this comment.
Thank you @lukasIO . Guess it can be an improvement (or not :-) ) down the line.
motivation:
a more structured approach to logging in order to facilitate sending logs to third party services.
structuring the logs with a message string and an optional context object turned out to be the most flexible approach while not forcing us to rewrite all messages.
some logging implementations that utilize a similar structure:
I opted to go for the ordering of arguments
(msg: string, context?: object)instead of(context?: object, msg: string), but not sure anymore if it's the right bet, as the implementations mentioned above seem to switch things around.