Feature requestED: monitoring Nginx from the outside

[Manlio Perillo]

Grzegorz Nosek ha scritto:
> On Thu, May 01, 2008 at 11:39:50AM +0200, Manlio Perillo wrote:
>> 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.
> 
> Why? Reading several variables at once will not be atomic (unless
> protected by a lock) but individual reads will, as long as the variables
> in shm will fit into a sig_atomic_t each (e.g. 4 bytes on x86).
> 
>> It can happen that when the client is reading the shared memory, Nginx 
>> concurrently writes this memory.
>>
> 

The problem is not with with Nginx, but with the client that will read 
the variables formatted in the shared memory.


The monitoring module for Nginx will write to the file this data, as an 
example (the numbers are in string format):
accept:00000002
read:000000001
write:000000001
wait:000000001
mybackendserver1status:00000000
mybackendserver2status:00000001


> The worst you can expect is that e.g. "requests ok" + "requests failed"
> won't be equal to "total requests". A sig_atomic_t is effectively atomic
> on most architectures (don't know whether POSIX guarantees it
> everywhere).
> 


>> 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!
> 
> ... which has to get its data from somewhere so it's going to face
> essentially the same problem.
> 

No.
With an HTTP interface the client will just make a request to obtain the 
data.

With shared memory it is a mess, I can't see any good reason to prefer 
this solution.


>> 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.
> 
> You could always add more information to a shared segment (like
> upstream_fair does).
> 

Yes, but this means to change in a not trivial way the existing code in 
Nginx.

> Best regards,
>  Grzegorz Nosek
> 


Regards  Manlio Perillo