Use log level management rather than debug boolean

[mwarkentin]

After running into some issues pushing metrics to Librato, and not seeing any issues in our logs, we discovered that certain errors (specifically 40X level errors) are only written while debug=true.

It would be great if this was determined using a real log level system (WARN, ERROR, INFO, DEBUG, VERBOSE). Running production services in debug mode is usually frowned upon in my experience.

[mheffner]

We should leverage the new statsd logger to support this: https://github.com/etsy/statsd/blob/master/lib/logger.js

[till]

@mheffner I just wanted to open an issue about it, because this has bitten me a couple times now.

Do you know if there's any progress on this?

[mheffner]

@till No, sorry I don't think there's been progress on this issue so far. We did a large rollout of new features in statsd-librato-backend 0.1.0, but sadly this didn't make the cut.

[till]

cc @mrtazz

Seems like injecting the logger into the backend would be the best option.

So bear with me, because I just learned that in JavaScript it doesn't matter how many parameters you supply to a method call. =) This is exciting and scary at the same time, but what I am getting at is, I might get away adding this and not break all the other backends.

So there's this line: https://github.com/etsy/statsd/blob/master/stats.js#L42

I'd change that too:

var ret = backendmod.init(startup_time, config, backendEvents, logger);

Means backends could update if they want the logger, but no one is forced to and everything breaks. =)

For this backend, it could use the logger when available or fallback to util.

I'll work up a PR for this first, and you guys can let me know what you think.

[mrtazz]

I think passing in a logger makes sense so there is a common API for how to use it.

[mheffner]

34 now uses @till's logger support to add log levels to the messages.