Thank you Francois and everyone for the great input and discussion. It
sounds very promising indeed!
So let’s say that I want to write a shell script that would continuously
monitor nginx to know when an upstream server went down, and if so,
which upstream server it is (IP or name).
With the approach you are proposing, can you explain how I would go
about this? What would my shell script look like? It sounds like I would
still need to modify nginx or write a module to monitor for this and
tell nginx to report such a condition? What would be involved for that?
Thank you!
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Rt Ibmer <rtibmx@…> writes:
So let’s say that I want to write a shell script that would continuously
monitor nginx to know when an upstream server went down, and if so,
which
upstream server it is (IP or name).
With the approach you are proposing, can you explain how I would go
about this?
What would my shell script look like? It sounds like I would still need
to
modify nginx or write a module to monitor for this and tell nginx to
report such
a condition? What would be involved for that?
Well, if module “ngx_http_upstream_round_robin” reports up and down
events it
would be something like this:
upstream-192.168.0.1:0
upstream-192.168.0.2:1
…
The shared memory is just filled with text, so it is up to the module to
name
the variable, in that case using the ip or dns name of servers in the
name seems
obvious.
At this time nothing is really done, it’s just a suggestion, I believe
it could
be interesting for Nginx to have such feature but without any
compromise. It
means code should be portable, not bloated and accepted by Nginx
community
and accepted by Igor.
Why? Because it’s not a standalone module but rather an API, so other
modules
with valuable data for monitoring need to be modified. But it’s not so
easy.
It’s not a matter of simply writing code but to evaluate all
implications. Just
for example: security, portability, support and side effects.
As there’s an ecosystem based on Nginx a modification of this kind may
affect
other softwares (it should not be the case).
So, it takes time to discuss about some things:
- is it really needed?
- what is the impact?
- does it broke something which was working?
- is it blocking the evolution of the software?
- is it clean and maintainable?
…
It is up to this list to answer these questions or to add another
questions (or
suggestions).
Best regards.