14 messages in ru.sysoev.nginxRe: Feature requestED: monitoring Ngi...| From | Sent On | Attachments |
|---|---|---|
| François Battail | Apr 30, 2008 12:29 pm | |
| Manlio Perillo | Apr 30, 2008 1:16 pm | |
| François Battail | Apr 30, 2008 1:39 pm | |
| Manlio Perillo | May 1, 2008 1:30 am | |
| François Battail | May 1, 2008 1:58 am | |
| Manlio Perillo | May 1, 2008 2:39 am | |
| François Battail | May 1, 2008 5:42 am | |
| Rt Ibmer | May 1, 2008 9:59 am | |
| Grzegorz Nosek | May 1, 2008 11:35 am | |
| Manlio Perillo | May 1, 2008 11:57 am | |
| François Battail | May 1, 2008 1:25 pm | |
| Manlio Perillo | May 2, 2008 1:52 am | |
| François Battail | May 2, 2008 6:50 am | |
| Rt Ibmer | May 2, 2008 10:31 am |
| Subject: | Re: Feature requestED: monitoring Nginx from the outside | |
|---|---|---|
| From: | François Battail (fb-f...@public.gmane.org) | |
| Date: | May 1, 2008 5:42:13 am | |
| List: | ru.sysoev.nginx | |
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.