Feature requestED: monitoring Nginx from the outside

[François Battail]

Le jeudi 01 mai 2008 à 11:39 +0200, Manlio Perillo a écrit :

> Each variable will be correct, but since you are writing the value to a 
> shared memory location not atomically, the variable as read by the 
> client will not be correct.

Yes, I'm aware of this, but at this time I don't know which system calls
to use to be compatible with other OSes, so assume there will be a
critical section (for example a mutex/spin lock in shared memory) and
that the script must use it prior reading data.

> Moreover it really does not make sense to write in a shared memory if 
> you want to support monitoring tools!
> 
> Just write a module like the stub_status module!

Sorry, but I do not understand what you mean. I just want to provide
something like /proc (on Linux) which is used by many monitoring tools.

> Finally there is one last problem.
> Nginx uses only a few shared variables (the one handled the the 
> stub_status module).
> 
> All other variables are private to each worker process.
> This means that probably your shared memory location will contain values 
> not very useful.

I agree. It's why I provide a very simple API to help migrating useful
data to the monitoring area, of course it's not transparent and
variables need to be ngx_atomic_t, not private. But that way it will be
easy to add monitoring support if *needed*.

For example gzip compress ratio can be compared to CPU use in mid/long
term; should I use gzip level 9 or 1 for *my* application?
It could be done if modules provide the possibility to monitor useful
variables if needed. It's a framework with a very low hit on
performance; I can change the API in such way that if monitoring is not
enabled, then the module will know that it should use private variable
instead of ngx_atomic_t, but I agree it's not completly transparent.

Thank you for your input, I'm listening and it's open ;-)

Best regards.