There's not too choice when it comes to open source network management software. Based on the popular Big Brother server monitor (http://bb4.net/), Big Sister has received much publicity since it reached release 0.98c8. Developer Thomas Aeby kicks off Big Sister's documentation by confessing that the documentation is incomplete and out of date. That is a fair warning. We did get Big Sister (mostly) running but here's a list of the hoops we had to jump through just to get it installed on a couple of Red Hat server installs:
  • Use Sourceforge mirror for downloads after downloads from the home site corrupted
  • Abandon attempts to find Red Hat libgd file that documentation says the perl GD module expects to find
  • Abandon attempts to install the rrdtool perl module that enables Big Sister to present graphs of historic data.
These are library issues caused by versioning and the minimal server installs, rather than in Big Sister itself. We mention them to highlight the dependency implications if you want to harness Big Sister's full power. After all that abandoning, what are you left with? You're left with a very fine network monitor. One that is capable of monitoring multiple services on multiple hosts, of paging administrators on trigger events and displaying near real-time and historic data in fast-to-parse, human-friendly formats. The problems listed above are clearly the pain-points for this installation. We recommend the documentation team focus on clarifying these, on the basis that 20 percent effort on the documentation will probably save users 80 percent of their installation pain. To get a testable installation configured and running after losing so much time to initial dependency investigation, we installed all three Big Sister base, server and agent packages on a server. The RPM install went fine but warned that there was no "bigsister" user. We created that user, noting the install had also created user "bigsis". We started Big Sister using the default agent configuration in the /etc/bigsister/uxmon-net config file. Poor documentation triggered our next annoyance right here. There's no obvious path to the URL required to view Big Sister's results. The documentation says Big Sister's install will not write to Apache's httpd.conf, so there is no obvious reason to look for clues there. However, an RPM-based Big Sister installation does write to httpd.conf, where an include to /etc/bigsister/httpd.conf led us to the URL: http:///bigsis/. Our view of the server displayed imitation red warning LEDs that signalled our post-install CPU was maxed out. CPU went green after Big Sister's next 15-minute update. However, two red LEDs warning of maxed out processes and disk space persisted. In our case, the disk space issue was due to this server's role as a CD server. Each CD is an ISO 9660 image file mounted to a loop device partition, which always appear as 100 percent full to disk-space monitoring tools. That gave us a great opportunity to explore how to configure the uxmon-net configuration file to ignore these virtual disks. They key to this lies in Big Sister's comprehensive-looking reference guide to its monitoring tokens. Waste of time
Again, its out-of-date documentation wasted our time. Big Sister's agent reference page discusses how to set up per-partition monitoring for the agent's token: "diskfree". But the installed agent uses the "disk" token. Installers are therefore forced to experiment with combining the documentation's config arguments for the old "diskfree" with the new "disk" token. We got it right second time: apply the old "diskfree" arguments to "disk". Another example, Big Sister's default user does not have read permissions on /var/log/messages but, naturally enough, the server expects to display this key file. Therefore, you will have to a) decide how you want to fix this (we don't recommend adding Big Sister's "bigsis" user to the root group!), and b) hand-tweak each monitor agent's uxmon-net file in order to implement your decision. Red Hat's replacement of inetd with xinetd also triggered persistent warnings on Big Sister's "processes" monitor. The agent reference page contained no reference to inetd or xinetd but we succesfully guessed we could change the token to xinetd in uxmon-net. If you are project managing a big Sister rollout expect to budget for the time that you will lose while discovering these configuration issues. Next, we went to install a Big Sister monitoring agent on a Windows Server 2003 box. The win32 zip expands to a directory, which the documentation suggests should be copied to the Windows server. We were unable to install beyond that copy. The documentation suggested, variously, that Perl was required - or that it wasn't. We found that running the uxmon executable seemed to require Perl. We would not deploy this code on production servers given either the fuzziness of documentation or the need to install Perl. It requires too much time or too much code. As a final test, we installed an agent on a Linux router/firewall/squid proxy in a DSL-connected branch office. This is a common scenario, with a common install challenge, due to the stripped down nature of the server operating system. An RPM-based install on this Red Hat 9 box went fine. We punched out port 1984 in the head-office NAT firewall and forwarded it through to our network management server. A one-line edit to the agent configuration file /etc/bigsister/umon-net on the router set the server IP address it should report to (the external IP address of the firewall. We checked the server's /etc/bigsister/permissions file to ensure it allowed this host agent to call home. It does by default. We then started the bigsister daemon to be greeted with: Agent uxmon: WARNING: your system is set to UTF-8 and your perl version might not support this - this might result in malfunction Agent uxmon: uxmon: WARNING: host router appearing in uxmon config is unresolvable That last line was repeated several times. With any other application we'd check those warnings in the documentation and fix from there. But we had already spent too much time with Big Sister's documentation and not enough time monitoring our servers. We gave up at this point.

OUR VERDICT

A highly configurable agent/server-based network monitor that takes the heterogenous server monitoring concepts popularised by Big Brother and extends them to include SNMP. Use it if you must integrate SNMP monitoring with service/daemon monitoring but if your time costs money, stick with Big Brother until documentation improves.