Re: Is it possible to monitor the fair proxy balancer?

Server NGINX
1

On Sat, June 28, 2008 13:51, Grzegorz N. wrote:

slightly overkill.
I think we could all (I mean mainly module authors) benefits from an
nginx
API (like the configuration system) to declare centrally
counters/variables of each module that in turn could be displayed by the
status module. If I have some spare time soon, I’ll try to produce an
nginx patch to implement this.

2

status module. If I have some spare time soon, I’ll try
to produce an
nginx patch to implement this.

Excellent indeed! At the most basic level it would be extremely useful
if nginx could signal an external process once it declared one of the
upstream servers offline (based on the timeout configs in its main conf
file).

My intention from such a thing would be to receive an email letting me
know ‘oh no upstream xyz is down!!’ and ‘oh good, upstream xyz is back
online’.

Some people have argued that such a thing should be left to external
monitoring tools like heartbeat etc. However such monitoring is no where
near the same IMO. For instance, heartbeat could see the upstream as up
because it is alive and pingable, but it wouldn’t be aware if nginx
declared it as offline due to timeouts or 500 errors (again, based on
settings in its conf file)!!

Thanks!

3

Hi,

On sob, cze 28, 2008 at 11:36:51 +0200, Brice F. wrote:

I think we could all (I mean mainly module authors) benefits from an nginx
API (like the configuration system) to declare centrally
counters/variables of each module that in turn could be displayed by the
status module. If I have some spare time soon, I’ll try to produce an
nginx patch to implement this.

I have attached an experimental patchset for pluggable status reports
for nginx HTTP modules plus initial upstream_fair support.

The patchset is rather ugly because it requires adding a field to every
HTTP
module definition, thus breaking 3rd party modules. However, the
required changes are trivial (as you can see in the patch).

I considered adding support for all modules (not only HTTP ones) and
changing the ngx_module_t structure instead (which has some room to
spare and would only require a few macro changes) but I think it’s up to
Igor to decide.

Please have a look and let me know what you think.

Best regards,
Grzegorz N.