Feature requestED: monitoring Nginx from the outside
fb at francois.battail.name
Thu May 1 16:42:36 MSD 2008
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 ;-)
More information about the nginx