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

Server NGINX
1

if (fork() == 0)
execl(“/bin/sh”,“/path/to/upstream_down.sh”,“ID of down upsteam
goes here”, NULL);

It’s not as easy to do.

At a high level, what am I missing / oversimplifying?

Perhaps instead, a simpler and more efficient approach may be for me to
write to a log when nginx stops routing requests to an upstream box. I
cannot use the events it logs current, because it doesn’t differentiate
between a failed attempt vs. enough failed attempts based on max_fails
and fail_timeout.

For instance it’ll write to the log saying a connection or timeout
occurred with an upstream, but does not record an entry saying that this
has occurred max_fails times and it is now taking that upstream out of
rotation for fail_timeout duration. I think at a minimum even if
nothing further is done here it should at least report that event in the
logs. Also I may be mistaken but I believe the current logging it does
in this regard is only seen with like “notices” - I would expect those
to get a high level logging priority like error or critical.

Well, from my point of view your solution is not good engineering and not in the

That does not surprise me at all! This is over my head for sure. All I
know is that I disparately need to know when nginx stops routing
requests to an upstream. And the only way to know 100% sure that its
doing so is for nginx to tell us, not to try and determine what nginx
must be seeing based on some external monitoring.

I don’t believe Igor is likely to call fork() to execute a script in response to
an event in its code.

Agree it is lousy! :slight_smile: At the same time, for an event that (hopefully)
happens very rarely I wouldn’t mind the couple of second hit from
inefficiency here. That being said clearly better solutions can be
engineered (just not be my unfortunately).

As I’m not a completely negative guy :wink: I propose a more general solution to
monitor Nginx cleanly and to do whatever your want.

That is an excellent idea! Basically some sort of event / hook system
that nginx can use to report various events (including “upstream down”
and “previously detected downed ppstream now back up”).

The script/agent will just read the shared memory and act according to data.

Perfect! I just need the hook.

Thank you for your consideration and I hope these discussions help make
in incredible product even more robust.

  ____________________________________________________________________________________

Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

2

Rt Ibmer <rtibmx@…> writes:

if (fork() == 0)
execl("/bin/sh","/path/to/upstream_down.sh",“ID of down upsteam
goes here”, NULL);

It’s not as easy to do.

At a high level, what am I missing / oversimplifying?

The problem is not at high level but at low level: you cannot put code
like this
on a server, it’s not a matter of writing two lines but to test
potential
errors, to have clean configuration parameters and to maintain the
software…

Perhaps instead, a simpler and more efficient approach may be for me to write
to a log when nginx stops routing requests to an upstream box. I cannot
use the
events it logs current, because it doesn’t differentiate between a
failed
attempt vs. enough failed attempts based on max_fails and fail_timeout.

Yes, it could be a solution but not good engineering: log is mostly for
post-mortem investigations not for processing live events. It’s
dangerous to
rely on string patterns.

Perfect! I just need the hook.

Some input from the list will be appreciated, I believe that such a
module will
add value to Nginx but some time is needed in order to fully evaluate
the
implications and the best implementation.

Thank you for your consideration and I hope these discussions help make in
incredible product even more robust.

:wink:

3

On Die 29.04.2008 21:27, François Battail wrote:

The problem is not at high level but at low level: you cannot put code
like this on a server, it’s not a matter of writing two lines but to
test potential errors, to have clean configuration parameters and to
maintain the software…

[snipp]

Perfect! I just need the hook.

Some input from the list will be appreciated, I believe that such a
module will add value to Nginx but some time is needed in order to
fully evaluate the implications and the best implementation.

I think for this the embedded script language
(perl/neko/lua/python/your_preferd_lang;-) will be very helpfull :slight_smile:

Brainstorming:

1.) add hook into upstream module, maybe some other modules also :wink:
2.) use this hook in $EMBEDDED_SCRIPT (current only perl) to write into
$OUTPUT_THING (file/shm/…)
3.) use external program which monitor the $OUTPUT_THING

The benefit to use a embedded script language is that the user can write
some infos into the output string and some predefined variables from
nginx.

I know this is a lot of work but it could be a 100% solution :wink:

Cheers

Aleks

4

Aleksandar L. <al-nginx@…> writes:

I think for this the embedded script language
(perl/neko/lua/python/your_preferd_lang will be very helpfull

I’m not too sure. If for writing some bytes on memory we need to
instantiate
an interpretor or a VM and after writing these bytes running a garbage
collector, there’s something wrong.

Brainstorming:

1.) add hook into upstream module, maybe some other modules also
2.) use this hook in $EMBEDDED_SCRIPT (current only perl) to write into
$OUTPUT_THING (file/shm/…)
3.) use external program which monitor the $OUTPUT_THING

The benefit to use a embedded script language is that the user can write
some infos into the output string and some predefined variables from
nginx.

Yes, but it is not the idea. It’s about monitoring indicators like:

counters on connections state (same as sub_status module)
upstream servers statuses
error counters (like out of fd…)
min max avg on resource allocation
…

That way it will be possible to have useful information for tuning or
monitoring
servers running Nginx in an efficient way. It’s not designed to
help debugging an application.

Best regards.