Thruk behind reverse proxy?

[Dave Howe]

Hi All.
  I have a situation where we have a number of nagios hosts behind a single reverse proxy - so for hosts nag-1 nag-2 and nag-3 we have a single copy of nagvis showing objects for all three, and server/nag-1 proxies though to nag-1/nagios, server/nag-2 to nag-2/nagios and so forth.

all good so far. However, we are looking to upgrade the nagios hosts to naemon, which of course uses Thruk instead of the classic nagios cgi, and which seems to hardcode the url back to the contents of url_prefix / product_prefix.

how do I get it so if I access via a reverse proxy, relative paths work?

[Sven Nierlein]

What exactly are you trying to solve with the reverse proxy? Nagvis talks livestatus with Naemon, no reverse proxy or thruk required. With Thruk i usually
would setup a single Thruk interface which just connects via livestatus to all you nagios/naemon cores. No need for reverse
proxy either.

Sven

[Dave Howe]

On Tuesday, 17 June 2014 17:58:36 UTC+1, Sven Nierlein wrote:

What exactly are you trying to solve with the reverse proxy?
Nagvis talks livestatus with Naemon, no reverse proxy or thruk
required. With Thruk i usually
would setup a single Thruk interface which just connects via
livestatus to all you nagios/naemon cores. No need for reverse
proxy either.

It solved problems with Nagios 3.x that probably don't exist in
naemon+Thruk - but that infrastructure is what I have to live with for
now, and if I am upgrading it will be a rolling change over several
months - however, switching to just having a central Thruk is
something we are also considering for a future refit, provided Thruk
will scale well enough. We currently have 56 nagios instances, with
about 3500 monitored devices and more than 12000 active service
checks; management have set a goal to triple that over the next two
years. A reverse proxy can handle that with a relatively small vm
running apache, and each "remote" autonomous system handling its own
gui and so forth. I am not sure what the requirement would be if a
single instance of Thruk had to handle that but I suspect the result
would not be pretty.

Principle of least change also applies; what we have now works, and is
proven - moving to something else will need to get past senior
management review, and that seems a thankless task. I would rather get
something off the ground now, and look at an architecture change
later, than try to replace the monitoring solution AND the entire
architecture in one hit, on a live monitoring solution.

[Sven Nierlein]

Hi,

well, Thruk can handle such situations. We are operating a setup
with ~200 cores across europe which are combined in a single
interface. But this won't work out of the box and requires some love
here and there. If you don't want to see everything at once, then
just change the backend selector to "switch" mode and there should
be zero performance penalty.
Reverse Proxy however should work if you change the remote installations
to run on the target path. Ex. /remotename/cgi-bin/...

Sven