Server Status ?

[Host DL]

Me too, I am looking forward for this extension for 1.4.x

current branch which is not working for recent versions:

https://github.com/zealot83/ngx_http_extended_status_module

it would be greatly appreciated if one of geeks to do it

Regards



============================================


On Thu, Jun 20, 2013 at 8:28 PM, Julien Decrouy <julien at pwal.fr> wrote:

> Thanks for the feed back Reinis
>
> I agree that the extended module (
> http://wiki.nginx.org/Extended_status_module) is doing things right but
> it is no more supported with nginx 1.3 or later and i think that patching
> nginx core is not a good thing.
>
> This way, the php-fpm status is a good alternative but we miss some
> metrics like the client ip,Vhost (i can get it with the script path but i
> won't get it if it's an alias), the status (reading, writting...)  and as
> you said the list of current active request URLs. This is pretty important
> to debug and apache serverstatus helped us several times so it will be
> great to have the same on nginx.
>
> Finally, i know that many admins (friends) don't use nginx for dynamic
> content because of this miss and getting it will be a way to gain some more
> percentage points of market share.
>
> I will be interested to contribute but i haven't found anything about a
> TODO list, do you have a link or something like this please?
>
> regards
>
>
>
> 2013/6/20 Reinis Rozitis <r at roze.lv>
>
>>  But according to me and my team (and many other admins as far as i can
>>> see), something important is really missing to push it in production. This
>>> is the "extended status" (i mean something like the apache server-status)
>>>
>>
>> What are the "important" things in the "extended status" that you miss
>> for the production use?
>>
>> Combined with the php-fpm own status ( pm.status_path ) you can get
>> pretty much all the vital metrics the only exception being the list of
>> current active request URLs and even then the problematic ones can be
>> logged with the php-fpm's slow log (request_slowlog_timeout).
>>
>>
>>
>>
>>  So my question is: Do you think that nginx dev team could do something
>>> in that way? i think it will be a much better improvment than getting stuff
>>> like SPDY or other experimental things.
>>>
>>
>> So to answer your question - while the dev team of nginx could probably
>> work on more visually appealing status page (as far as I know it's on TODO
>> list and you can always speed up theese things by either contributing the
>> code yourself or using the nginx commercial support (nginx.com)) these
>> "experimental things" are what have made nginx one of the fastest and
>> feature richest webserver.
>>
>>
>> rr
>>
>>
>>
>> rr
>> ______________________________**_________________
>> nginx mailing list
>> nginx at nginx.org
>> http://mailman.nginx.org/**mailman/listinfo/nginx<http://mailman.nginx.org/mailman/listinfo/nginx>
>>
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20130620/38d52f52/attachment.html>