-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Util.logger log messages level logic is total mess #11
Comments
I agree with that first one, for sure. The others I don't, though I'd be curious to hear what @raskchanky thinks. Gearman is designed to propagate failures and exceptions back to the server, so their occurrence is not indicative of an error -- at least, not of an error in gearman-ruby. This fits with Alex Miller's logging philosophy, which I think is quite sound. Are there any other examples you've noticed? This is one area of many that really ought to be cleaned up, and I'm glad you started the discussion! |
In general, my opinion is that if the client or worker is sending a valid gearman message, even if that message is work_fail or work_exception, then "error" is not the correct log level to use: "info" is probably most appropriate for those cases. "debug" should be reserved for excessively verbose logging that's not necessary unless the person viewing it is a developer trying to debug the library itself. Ruby exceptions should be logged as "error". |
Well I did check only the worker.rb code since this is where i needed to look in order to check exceptions handling, where exceptions sent back to gearmand server were never recieved on the clients runing foreground jobs - and thus never knew a job had failed. In the following code of handle_job_assign exception = nil
begin
ret = ability.run(data, Job.new(sock, handle))
rescue Exception => e
exception = e
Util.logger.debug "GearmanRuby: Exception: #{e}\n#{e.backtrace.join("\n")}\n"
end
cmd = if ret && exception.nil?
Util.logger.debug "GearmanRuby: Sending work_complete for #{handle} with #{ret.to_s.size} byte(s) " +
"to #{hostport}"
[ Util.pack_request(:work_complete, "#{handle}\0#{ret.to_s}") ]
elsif exception.nil?
Util.logger.debug "GearmanRuby: Sending work_fail for #{handle} to #{hostport}"
[ Util.pack_request(:work_fail, handle) ]
elsif exception
Util.logger.debug "GearmanRuby: Sending work_exception for #{handle} to #{hostport}"
[ Util.pack_request(:work_exception, "#{handle}\0#{exception.message}") ]
end it catches an exception at writes at debug level not error. Still I think that cases 2) & 3) should logged at higher level than "info" - since I have a monitoring of the logs and want to receive alerts then there are "warnings" or "errors" so that I know there was a problem in worker doing some job. Of course if the client this a foreground jobs it can discover that there was a problem by a client itself, then it receives work_fail or work_exception (again which are never actually received from gearmand) , but for background jobs there is not simple way to get alerted then job fails. Now regarding client not receiving work_exception there is an old invalid bug |
Some logger messages log level do not make any sense
just a few examples from Worker class implementation:
Util.logger.error "GearmanRuby: Got job_assign with handle #{handle} and #{data.size} byte(s) " + ...
It should probably be debug or info, but certainly not and error.
Util.logger.debug "GearmanRuby: Sending work_fail for #{handle} to #{hostport}"
Util.logger.debug "GearmanRuby: Sending work_exception for #{handle} to #{hostport}"
Util.logger.debug "GearmanRuby: Exception: #{e}\n#{e.backtrace.join("\n")}\n"
Those should be error and certainly not debug
There are many more
do I get something wrong here?
Thanks
The text was updated successfully, but these errors were encountered: