Unicorn logging in production env

Unicorn logging in production env

[Serg Podtynnyi]

Hi All, as I can see on
https://github.com/defunkt/unicorn/blob/master/lib/unicorn.rb#L53
the Rack::CommonLogger used only in development env and in weird evn
called "deployment".
Any chance to add  "production" to this case?

Serg Podtynnyi
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: Unicorn logging in production env

[Eric Wong]

Serg Podtynnyi <serg@podtynnyi.com> wrote:
> Hi All, as I can see on
> https://github.com/defunkt/unicorn/blob/master/lib/unicorn.rb#L53
> the Rack::CommonLogger used only in development env and in weird evn
> called "deployment".
> Any chance to add  "production" to this case?

Not unless Rack does it, Rack doesn't recognize "production" in any
special way.

If you really want it, you can add Rack::CommonLogger to config.ru
yourself.

Since I was never satisfied with the Rack::CommonLogger logging format,
I wrote clogger[1] which offers nginx-like formatting options.



[1] http://clogger.rubyforge.org/ - configurable logger for Rack

-- 
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: Unicorn logging in production env

[John Fieber]

On Aug 16, 2011, at 8:45 AM, Serg Podtynnyi wrote:

> Hi All, as I can see on
> https://github.com/defunkt/unicorn/blob/master/lib/unicorn.rb#L53
> the Rack::CommonLogger used only in development env and in weird evn
> called "deployment".
> Any chance to add  "production" to this case?

My wish would be to remove all of the magically added middlewares.  Leave the middleware assembly to config.ru.  Failing that, my next wish would be to have the magic opt-in.  Failing that, my next wish would be for an easy opt-out.  It is maddening to debug an error in your app that causes the ShowExceptions middleware to crash, masking your actual problem.

-john

_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: Unicorn logging in production env

[Eric Wong]

John Fieber <jfieber@adobe.com> wrote:
> On Aug 16, 2011, at 8:45 AM, Serg Podtynnyi wrote:
> > Hi All, as I can see on
> > https://github.com/defunkt/unicorn/blob/master/lib/unicorn.rb#L53
> > the Rack::CommonLogger used only in development env and in weird evn
> > called "deployment".
> > Any chance to add  "production" to this case?
> 
> My wish would be to remove all of the magically added middlewares.
> Leave the middleware assembly to config.ru.

If you can convince Rack upstream, Unicorn will follow.  I dislike
magic middlewares, too, but I try to follow Rack to minimize the
differences for people using unicorn (and also switching between
"rackup" and unicorn).

> Failing that, my next wish would be to have the magic opt-in.  Failing
> that, my next wish would be for an easy opt-out.  It is maddening to
> debug an error in your app that causes the ShowExceptions middleware
> to crash, masking your actual problem.

I always set RACK_ENV=none for any services I run so nothing
gets added automatically.

-- 
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: Unicorn logging in production env

[Serg Podtynnyi]

On Tue, Aug 16, 2011 at 9:30 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Serg Podtynnyi <serg@podtynnyi.com> wrote:
>> Hi All, as I can see on
>> https://github.com/defunkt/unicorn/blob/master/lib/unicorn.rb#L53
>> the Rack::CommonLogger used only in development env and in weird evn
>> called "deployment".
>> Any chance to add  "production" to this case?
>
> Not unless Rack does it, Rack doesn't recognize "production" in any
> special way.
>
> If you really want it, you can add Rack::CommonLogger to config.ru
> yourself.
>
> Since I was never satisfied with the Rack::CommonLogger logging format,
> I wrote clogger[1] which offers nginx-like formatting options.
>
>
>
> [1] http://clogger.rubyforge.org/ - configurable logger for Rack
>
I am asking about this default values because by the convention
production env is 99% "production", but in the code I see
"deployment", so most of the people that are using unicorn have bogus
logs on production. Thanks for clogger suggestion.
PS
Any idea of how to have some kind of useful information when master
process kills workers by timeout?
We just monkey patched Unicorn::HttpParser read method like this
https://gist.github.com/1151164 to get more info. Is there a better
way to do this?
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: Unicorn logging in production env

[Eric Wong]

Serg Podtynnyi <serg@podtynnyi.com> wrote:
> I am asking about this default values because by the convention
> production env is 99% "production", but in the code I see
> "deployment", so most of the people that are using unicorn have bogus
> logs on production. Thanks for clogger suggestion.

Yeah, as I explained in the other post, I've always tried to base as
many defaults off Rack defaults so people have less trouble switching
from/to Unicorn.

I'm quite happy with how clogger works, hopefully we find more happy
users :)  (I don't like relying on unicorn to promote clogger, though.
clogger should be able to stand on its own since it works with any Rack
server).

> Any idea of how to have some kind of useful information when master
> process kills workers by timeout?

It's not possible to know what a worker is doing since SIGKILL isn't
trappable.  The master killing workers should only be a last resort
that'll let you limp by until you can have a proper fix.  The the rest
of the app should have local timeouts for all non-deterministic calls.

> We just monkey patched Unicorn::HttpParser read method like this
> https://gist.github.com/1151164 to get more info. Is there a better
> way to do this?

There isn't any difference between that and having Rack middleware
at the top of your stack (clogger logs at the end, and if you have
things like $body_bytes_sent it even wraps the response body)

class LogBefore < Struct.new(:app)
  def call(env)
    env["rack.logger"].debug env["REQUEST_PATH"]
  end
end
--------- config.ru ---------
use LogBefore
use ...
use ...
use ...
run YourApp.new
-----------------------------
-- 
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: Unicorn logging in production env

[Eric Wong]

Eric Wong <normalperson@yhbt.net> wrote:
> The the rest of the app should have local timeouts for all
> non-deterministic calls.

If you're lazy, maybe the following middleware works, too, I haven't
ever needed it but wrote (and later rewrote it) as a proof-of-concept:
  http://bogomips.org/rainbows.git/tree/lib/rainbows/thread_timeout.rb

It should work with bare Unicorn if you remove the "Rainbows" references
and the negative threshold handling in "initialize".   If somebody wants
I can split it into it's own gem (should work with WEBrick, Mongrel,
Passenger, and maybe Thin), too).

Unlike the Timeout library in Ruby stdlib, this doesn't allow nested
timeout {} calls so it's simpler/possibly-safer in this regard...

I even posted a request-for-review for the middleware on ruby-talk but
didn't get any responses:
  http://mid.gmane.org/20110421232615.GA27468@dcvr.yhbt.net

-- 
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying