nextstrain / nextstrain.org

The Nextstrain website
https://nextstrain.org
GNU Affero General Public License v3.0
89 stars 48 forks source link

Improve logging #511

Open tsibley opened 2 years ago

tsibley commented 2 years ago

Logging in nextstrain.org is currently ad-hoc and sometimes useful, sometimes not enough. The goal is to make what's logged more systematic and comprehensively useful while at the same time improving our ability to inspect and act on the logs.

Below are some proposed changes to make, spanning both the codebase itself as well as our deployment infra. I expect to break each of these items out into separate issues in due course.

jameshadfield commented 6 months ago

Standardize on debug or bunyan for emitting logs.

We only have 40-50 usages of our utils.{verbose,log,warn,error} functions in the entire server and I'd imagine switching them all to {debug,console.*} calls would be well worth it in the short term. This doesn't rule out a move to some other logging tool in the future, but debug calls are already widely used throughout the server (mostly implicitly).

Is there an agreed standard for general want-to-always-see-this logging when using the 'debug' module? Its docs seem to suggest we'd do something like debug('nextstrain') and then habitually run with at least DEBUG=nextstrain.

tsibley commented 6 months ago

Is there an agreed standard for general want-to-always-see-this logging when using the 'debug' module? Its docs seem to suggest we'd do something like debug('nextstrain') and then habitually run with at least DEBUG=nextstrain.

Not really? I mean, you always have to specify DEBUG at invocation, or modify it programmatically very early at process start (but there be pitfalls). It really is meant for debug logging which defaults to off.

This is why I do think we want a proper logging library beyond debug.

But agreed that ditching utils.{verbose,log,warn,error} for {debug,console.*} in the short-term would probably be worthwhile.