log4js integration

[hiddentao]

This replaces console.log calls with a log4js integration and adds two command-line flags (--loglevel and --logfile) to be able to customize logging verbosity at runtime.

Benefits:

• Console output is now timestamped and categorized - with the ability to customize the format in a single place (the logger.js file). We could also add a CLI arg to override the pattern if deemed necessary.
• We can now add debug and trace logging in many more parts of the app without automatically clogging up the console output, yet retaining the ability to show these logs by setting the right CLI argument.
• We can set the logging threshold using --loglevel <level>. Possible values are trace, debug, info, warn, error. Default is info.
• We can have log4js log to a file using the --logfile <path to file> arg.
• Log4js output formatter automatically handles things like Error objects well.

I haven't added this logging to the Meteor "interface" app yet but there's no reason we can't do that.

[frozeman]

What does trace, debug, info (default), warn, error mean? do i either/or select? Means if i have trace, i wont see error, or info logs?

Aren't log levels like 0-6 better?

[hiddentao]

They are effectively ordered as such:

1. trace
2. debug
3. info
4. warn
5. error

So if you set the level to debug you will see everything at debug and above.

I think it's better to used labelled logging as it corresponds with console methods + it forces one to consider what type of information is being logged. In the PR I've translated most of the console.log calls into .info but I've made a few low-level items as either debug or trace for this very reason.

[frozeman]

Sounds good, but maybe we should note in the help that trace is all. I would expect trace to contain stack traces at all times.

Apart form that it looks good!

[hiddentao]

Ah, that's a good idea, I'll update the CLI help docs with that info.

[hiddentao]

The Mist Meteor app also has a bunch of console.log calls - I was thinking that we could put that stuff through log4js too so that it's all unified. Since the GUI crashes for some people before they can get to console logs this may give us a way to capture such logs (through the --logfile option). I haven't looked into how easy it would be to make the logging work this way but I imagine it's doable.

Do you think this is a good idea?

[frozeman]

If it adds it also to the log file, this might be useful if it works in the browser.
But i don't think the render view can write to files ;) So you would need to build some kind of internal "IPC send to backend" thing.

Not sure if thats worth the time for now.

Here is a meteor package, but it might only work for the meteor server side, which we don't use: https://atmospherejs.com/adain/log4js

[hiddentao]

Looks like Meteor 1.3 has built-in support for NPM modules -> https://github.com/meteorhacks/npm

So it would be trivial to include log4js into the Meteor app (once we've upgraded Meteor of course) and then we would just need to write a custom appender which sends the log data to the IPC back-end.

I'd like to give this a go - I think it would be very useful.

[lock]

This thread has been automatically locked because it has not had recent activity. Please open a new issue for related bugs and link to relevant comments in this thread.