Feature request: Run a script when upstream detected down/up

[Mansoor Peerbhoy]

Manlio,

Yes, I see what you're saying. 
It is always going to be a problem if the listener cannot consume the data fast enough. 
In any case, if you really dig deep, you can see that NGINX is asynch in that it always reads from a socket only when it is ready to be read (select/poll/epoll/kevent etc fires). 
But, as you know, NGINX uses non-blocking sockets. 
So when it wants to write to a socket (as far as my limited understanding goes), it doesn't wait for it to be ready-to-write. It just goes and does a write to the socket. If the kernel deems that the write would have blocked, it will return EAGAIN (see send(2)) , rather than block the caller, if that's what you're worried about.

Yes, with the speed and volume of debugging calls, it is likely that NGINX may need a memory buffer to hold the debug logs till the socket can be written to, but then, I guess that is overkill.

As someone pointed out, logging is one thing, profiling is quite another, and monitoring is yet something else. Different needs.

But think about it. Agreed that NGINX is astonishingly fast in every aspect of the game, but the ability to log to a socket can, at the very least, provide centralized logging in cases where maybe several nginx proxies sit behind a load balancer. The value of such a centralized log, IMHO can be a very good argument for extending the support to log to a socket.

And it isn't as if NGINX needs to be configured by default to write to a socket. I'm sure if ppl wish to configure it that way, they should understand that NGINX should expect the log-consumer process to be fast enough.

Also, again off topic, what's NGINX performance when log files reside on an NFS (or CIFS, etc) partition ? Has anyone tested that ? I should imagine that the reliability of the network will affect NGINX ngx_log_* times

Regards,
Mansoor


----- Original Message -----
From: "Manlio Perillo" <manlio_perillo at libero.it>
To: nginx at sysoev.ru
Sent: Wednesday, April 30, 2008 3:07:07 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi
Subject: Re: Feature request: Run a script when upstream detected down/up

Mansoor Peerbhoy ha scritto:
> hello,
> 
> i have a small suggestion to make (slightly off topic):
> 
> i think this problem would be best solvable by having nginx capable of logging to a file-type other than a regular file.
> for instance, if the nginx error_log directive (http://wiki.codemongers.com/NginxMainModule#error_log) could support a TCP/IP or a unix domain socket or a named pipe, then interesting programs can be written around it which may be an easy approach:
> 
> a) for instance, having an external program monitor nginx logs for a particular log message (or "event"), is not so easy when the file in question is a regular file. the reason for that is, regular files are *always* ready to read on linux (even if the FD is at EOF), so you can't use an open file descriptor to a regular file in a select()/poll() system call and expect it to work the way you want. (i.e. ready-to-read)
> it could be done (tail -f does that), but it's rather messy to have a file-change notification, plus seeking to the appropriate offset. -- with sockets/fifos, these problems can go away. you can set up a socket server to listen on the given socket for connections, and when nginx starts up, the error log initialization code can connect to the tcp or unix domain socket or fifo in question, and then all calls to nginx_log_* will naturally be written to the socket, instead of written to a regular file
> 


This is not as easy as it seems.
First of all with the current architecture of Nginx, writing to the 
error log is assumed to be synchronous.

This means that if you want to send log messages to a TCP server the 
performance will be bad.

You can use an UDP connection, but what happens if Nginx sends data more 
quickly then the server is able to read?
UDP has no flow control.


 > [...]



Regards  Manlio Perillo