pushing a number of resque logs deeper

[gcoonrod]

Trying to reduce the verbosity of resque logging.

[evantahler]

I'm personally of the opinion that starging/stopping workers should be of the info level, but lets here what others think

comments welcome

[gcoonrod]

When using multiworkers i was seeing workers stopped and started every second. Which really cluttered up the logs. What is the rationale for having those events at the info level?

[evantahler]

The rationale was in production the lowest log level you probably might use would be "info". On production you are likely to be using a log aggression tool like Splunk, Sumologic, etc, and you probably want to know how many of your workers are running at any time. You can then scan for the latest log of this type to see how many are up and running.

[neilstuartcraig]

Info seems like the right choice to me too. It's certainly not higher than that. I guess you could make a case for debug but I'd expect to see it in info.
For reference, you could check what apps like nginx etc do. Not saying they're becessarily right but could be validation.

[gcoonrod]

Any thoughts on making the worker log levels controllable?

[evantahler]

lets see what a PR for that would look like @gcoonrod! Might make sense depending on how much cruft that adds to the config file

[gcoonrod]

@evantahler, I added an attribute to the tasks config and set some of the node-resque messages to use that attribute to determine their logging level. I only applied that option to the messages that have been bugging me.

Are there other messages that this option could/should be applied to?

[evantahler]

Don't commit this

[gcoonrod]

@evantahler Any further comments or suggestions?

[evantahler]

I don't think that I like having a log option outside of the logging config file.

Perhaps the answer is a hash with each event => log level?

{start: "debug", poll: "trace"}

[evantahler]

Lets merge it in for now, although I do expect some future changes.

[evantahler]

Thanks!