3 ms·
Good point! Log levels are pretty useless most of the time. I would add that there can be value in having 2 log levels: verbose and non-verbose. It is helpful
by alexdowad 4y ago
Good point! Log levels are pretty useless most of the time.
I would add that there can be value in having 2 log levels: verbose and non-verbose. It is helpful if you can selectively switch on verbose logging by user or by API endpoint.
In one application which I maintain, when verbose logging is switched on for a particular user, TCP/UDP socket objects are automatically wrapped and packet captures are logged, only for packets sent/received while servicing that particular user's requests. This has been a lifesaver when debugging things like weird, transient authentication problems stemming from upstream providers.
- chriswarbo 4y ago> It is helpful if you can selectively switch on verbose logging by user or by API endpoint. We currently use two log levels: - When 'debug = true', debug logs are printed immediately (like a DEBUG log level) - When 'debug = false', debug logs go into a buffer: if the request-handler succeeds, its debug buffer gets discarded. If it catches an exception, the buffer gets printed. This avoids the main problem of log levels, which is having to guess up-front which level we might want (and inevitably get it wrong, and have to try re-creating a problem with more verbose logging!)
- alexdowad 4y agoNice! It sounds like you would do well to capture the debug output if a request handler takes an unusually long time to return (not just if an uncaught exception occurs).