Managing Huge Networks with Open Source Tools?

An anonymous reader asks: "I work for a large multinational firm with a network that spans the globe and am responsible for evaluating the software we use to monitor our network. Our department has a lot of money, and we're usually willing and able to spend it on good commercial software. Recently though, I find myself evaluating and approving more and more open source software. We are actually in the process of replacing some of our commercial tools with software like Nagios, LooperNG and syslog-ng. We are also evaluating MRTG, RRDTool, ntop and a host of other tools. The problem is that there's just too many of them, most of which are not maintained anymore. Here's my question: What other open-source tools do you use to monitor your networks? I not just looking for names, but how long you've been using them for, how easy / hard is it to administer and I guess how well it scales as the network grows. More importantly, are their respective projects still alive and kicking?"

Comments

On my large network

[shfted!]

For my large network at home, I have a little device with lights that blink when the network is working. I think the guy at the store called it a switch or something.

JFFNMS

[szysz]

I created and use JFFNMS (Just for Fun Network Management System) to monitor my network at work.
Its also used by a lot of people to monitor big, and medium networks.
Its fully mantained, and customizable.

Gkrellm

[ptaff]

A slick tool is Gkrellm, which has real-time graphical status for memory/temperatures/net/disk. Can be run in "server mode" (so no need for X on the monitored server). Lots of plugins are also available, from SNMP to ping tools. The project is well alive. Don't know if it floats your boat, though, as you're mentioning huge networks.

Feel ready to own one or many Tux stickers?

Forget MRTG

[Judg3]

Well, don't forget it as much as get something better, Cacti. Cacti is a frontend to MRTG & RRDTOOL and offers a lot of awesome improvements, such as a web frontend to add devices, device "profiles" to enable a common monitoring set for things such as Cisco routers, servers, etc and a whole lot more. We used MRTG here at our (Windows only) network, and I'm slowly moving it all over to Cacti for all of the above plus a lot more.

Internode NodeMap

[sr180]

As developed and used by Australian National ISP Internode. They developed it and gave it to the community... Kudos to them: NodeMap

Open Source Network Administration

[mcco7614]

I bought Open Source Network Administration by Kretchmar to answer this question. I was looking for open source tools to be used in a service provider environment and was unpleasantly surprised at what was revealed in this book. However, since it seems you're looking for enterprise-ish stuff, I highly recommend this.

You'll find many of the tools within to be quite useful during both day-to-day operations and troubleshooting as well as long term planning on your network. The author does a fairly decent job of walking you through a basic installation of each tool.

Slashdot reviewed it here.

Here are most of the tools discussed in this book.

Nagios and RRDTool

[Karora]

We're using Nagios (multiple redundant geographically diverse installations) and RRDTool fairly successfully, but that's for maybe 200 machines, tops.

From looking at what we've achieved with these I would say that you will need to be careful trying to scale them to large networks. They can start huge numbers of processes each minute, when monitoring many servers.

It depends what you're monitoring, of course - in our case we are monitoring maybe 20-30 operational parameters on each server. If we were only monitoring a single parameter then we could probably look at around 1-2000 machines from a single P4-based monitoring box, without any real problems. Using a 2.6 kernel on the monitoring box would also dramatically increase the scalability of it all.

Scalability issues bite similarly with rrdtool: numbers of parameters monitored per server can ramp the load on the monitoring machine(s) quite quickly. Again that is process load, not CPU load though, and a 2.6 kernel will be significantly better in this area. It can also be resolved by scripting the collection process better - not just running some collect-the-statistics routine from cron every minute.

If you're looking at monitoring 1000's of systems though, maybe you have enough of a budget to be able to plan around these issues.

I'm sure that ultimately all monitoring apps run into issues with how many (parameters * servers) each monitoring system can monitor too.

Our stuff includes

[harikiri]

We use the following tools:

• Nagios: For availability monitoring. When a service or host goes down, we know about it. Was put in place when we discovered one of our pairs of firewalls (hot standby) had silently failed over because of a faulty hdd, and we hadn't noticed it for 2 days.
• Cacti: For throughput and performance monitoring. Makes pretty little graphs. The best thing about it is that it helps bypass the complex configuration of rrdtool by using templates. Documentation on creating new, non-standard graphs could use some work.

Both tools give us a much better view of our network, and what our various devices are doing.