Nagios Support Forum

Hello all


I'm looking for a way to access the nagios status of a series of hosts that live on a one-way restricted network ( lets call it Site A) - i.e. the hosts can send out but nothing is allowed in.

Some ideas that have cropped up is to regularly copy the status.dat to a place where it can be accessed outside Site A - yet I don't know how my external nagios ( on Site B) instance would read that data - Is that even a feasible approach? Site B is also monitoring a separate set of hosts but if needed, we could set up a third nagios instance with the sole purpose of mirroring from Site A if that simplifies anything.

I realize I could have the nagios send passive checks from Site A to Site B but as far as I understand i would have to have a duplicate configuration of all those hosts set up as passive hosts/services on Site B - something we would really want to avoid for the admin overhead.

So - is there any solution that you can think of that fit these requirements? I.e. Distributed monitoring on a one way network without using passive checks..

hbj wrote:the hosts can send out but nothing is allowed in.

Passive checks were designed specifically for this use case. Practically every such network I've seen with federated Nagios Core installations has the single local Core instance shipping to a master Core instance via passive checks coupled to event handlers. Eg, you have your "egress only" network with a dedicated Core machine monitoring all the stuff on that "egress only" network, then shipping the results to the master Core instance as passive checks when needed (or automatically regardless of the check states).

hbj wrote:Some ideas that have cropped up is to regularly copy the status.dat to a place where it can be accessed outside Site A - yet I don't know how my external nagios ( on Site B) instance would read that data - Is that even a feasible approach?

Read that data for what exactly? A centralized location for check definitions? I think that would work, but having some sort of daemon responsible for interacting with the JSON CGIs and pushing results down to some repo accessible on the segmented network seems cleaner.

hbj wrote:something we would really want to avoid for the admin overhead.

The config/plugin management becomes absolutely trivial with something like Chef, Ansible, or Puppet in place.

Alternatively, a Nagios XI license offers a centralized location from which your agents can pull their passive check definitions and plugins from. More info:
https://assets.nagios.com/downloads/nag ... ios-XI.pdf

Not sure how your egress-only networks would retrieve designations from it, but it is a method by which you can have a central authority for all your Nagios passive check dependencies/configurations.

Great answer, @mcapra!
@hbj, Let us know if you have any other questions for us?

Apologies for the late reply.

@mcapra - thanks allot for the writeup - I suspected that the case was as you described so I'll dive deeper into it.
And you're right - this should all be absolutely trivial with proper configuration management which is the path we will be taking.

Our monitored egress-only systems need to be agentless - they are checked with SNMP checks from a nagios-core instance.

So just to be clear - the best way to do this would be to have that nagios-core instance then push out the results from those checks passively to another nagios instance outside the egress-only network? Or is there some other way that I might be overlooking?

Again - thanks allot for your write-up

This is really the best way, you are going to at least need passive configurations for the hotss/services on both systems, but I don't see any way around this.