Jul 19, 2011 3:15 AM
Distributed setup
-
Like (0)
Hi all,
I have 2 questions on how to best do a distributed setup.
We build several customer networks, where we need to monitor devices (usually switches).
The networks are usually private and we have some device/gw to access them. This could be a firewall or a (very) limited server.
For the sake of this example I will let all networks be the same (say 192.168.10.0/24).
What is best practice for setups like these?
- Do we install a distributed zenoss collector on the limited servers (they are very limited!)?
- Do we do some fancy mappings in the firewall?
We are moving from Nagios to Zenoss and today these setups are built with a Nagios agent on the limited servers. Installing a Zenoss collector on the existing setups is not really an option. We can live with the Ping monitoring of Nagios - SNMP isn't required.
How do we integrate them into Zenoss?
- Can Zenoss receive information from the Nagios agents?
/Marcus
I don't know enough about how a Nagios agent works, but my guess is it would at the least require some fun with command datasources. The distributed Zenoss instances are pretty much the same as the central installed Zenoss server, just in a "slave" mode. So a very limited server wouldn't work.
I think you'd need some coding here, or to drop a full *nix server with open ports back to the Zenoss central server. . .
--
James Pulver
Information Technology Area Supervisor
LEPP Computer Group
Cornell University
So for future setups I need a full blown Zenoss capable server running a collector. Is there an issue with having the same private subnet on all networks?
Zenoss has required unique IPs in Core - there was a feature in 3 I think that changed that, but to be honest, I don't recall if it was an enterprise only feature or not. Maybe another forum member can comment.
--
James Pulver
Information Technology Area Supervisor
LEPP Computer Group
Cornell University
Anyone got an answer for that?
Can I have the same private IPs in multiple subnets (using a distributed collector setup)?
No you cannot do this with Core.
So...is the only the only solution to this is to use NAT, with a public IP for every private one?
Even with remote collectors, the devices will still have same IPs. We have solved this in the Enterprise product with our Multirealm ip ZenPack, though it goes generally unsolved in Core.
You could, as a workaround, create dummy devices and do everything via command-based (ssh) monitoring. You can create a datasource that runs a command to ssh over to the remote machine, and run something there. The data that SSH commands spit out, can then be parsed with either a) the delivered nagios parser (aka delivered in zenoss core) or b) you can write a custom parser. This would not allow general stats to be enabled - you would need to create your own datasource for anything you wanted to monitor on it.
I dont quite understand your NAT comment.... if you can somehow get each IP to be different in zenoss's eyes, that will work.
Hi Nick,
I will give the Nagios parser a go. Is there a guide somewhere on how to do that?
I havn't been able to find one.
My comment on NAT was about wasting public IPs using NAT to the devices we need to monitor on the customers private network.
Take a look around the Extended Monitoring guide, and also the dev guide. They are pretty in depth and I believe have some info on command/ssh monitoring. You might have to hunt and peck a lil - paruse the tables of contents and then delve in. Ive not seen one specific guide on how to make your own command datasource and parse it with a nagios parser, though maybe someone else has?
Thanks for the advice. I had a look and this was more work then I had hoped for.
But I think I have found a completly different and more elegant solution for this - will test it our lab soon.
What were your findings?
Hi Nick,
I havn't had the time to test it, but I think it will work.
We use Juniper SRXs for all our customers. They can act as a syslog server, so all devices on the LAN can forward theri syslog to them, who in turn foreward their syslog to zenoss (under their own IP).
They also come with several probe, including ping probes. The results of these probes can trigger SNMP traps to Zenoss. So, They ping the LAN and send a trap when something is down.
I'll update when I've tested it.
Why not cheat? Use a point to point VPN tunnel between your collectors and your core instance. You could use a unique IP schema then.
Apart from the security issues of interconnecting all our customers networks - which can be delt with. We don't get a say in the IP plan of these LANs.
Follow Us On Twitter »
|
Latest from the Zenoss Blog » | Community | Products | Services Resources | Customers Partners | About Us | ||
Copyright © 2005-2011 Zenoss, Inc.
|
||||||||