Up.Time 4 is a cross-platform, client-server server monitoring product. The vendor, Uptime Software, labels it as: "Enterprise monitoring and planning software that just works", so we decided to see if its claim was true.

There are two components to the system: the monitoring server, which sits on a central machine and collates information from the various agents on the network, and the agent software component that you put on each monitored device and which passes information back to the server. The server runs on Windows XP Pro, Windows Server 2003, Red Hat ES/AS 4.0, SuSE Enterprise Server 9, and Solaris 8, 9 and 10. The agent platform list is more extensive – as well as all of the above, it'll work with Windows 2000 Server (SP4), a load more Red Hat and SuSE incarnations, Fedora Core 1-4, Debian Linux 3.0+, AIX, IRIX, HP-UX, FreeBSD, Tru64 and VMware ESX Server.

We tried the product using a Windows XP Pro server and an agent running on Windows Server 2003. Installation is done via the usual wizard on both ends; on the agent you get a new applet in the Start menu that lets you configure the basic details such as the IP port to listen on. Firing up the server presents you with a login screen, then you paste in the licence key (which, unsurprisingly, dictates how many servers and/or VMware processors can be monitored) and you're off.

First thing to do is configure your archive policy (ie. how long it keeps data before chucking it away), tell it what mail server to use for sending you alerts, define any custom monitoring periods (you probably care about your Web server enough to monitor it 24x7, but you might choose only to be told about problems with the print server during working hours). You can also configure a remote reporting server if you've installed one.

Once you've got the basics done, you can point the server at its agents. Adding an agent is a doddle – enter a name and an IP address, and hit the button, and so long as the agent is visible (which in this day and age means "remember not to let Windows Firewall get in the way") it'll connect to it and start monitoring. Alternatively you can let the package scan the network in an auto-discovery mode. Even in manual mode, it takes only a few seconds per agent to tell the server about its remote colleagues.

Once you've got your agents connected (and you can collect them into groups for ease of reference, if you wish) you can click on their entries in the device list in order to see basic information – what disks and CPUs they have, their various network interfaces, OS version, swapfile size, and so on. The clever bit is that you can monitor the various services running on each machine.

Now, when we talk about "services", we don't mean it in the context of the things that appear in the Services control panel under Windows, or in the Unix daemon startup list. Although Windows services can indeed be monitored, think of "services" in an Up.Time context more as "applications" – DBMSs, email server programs and the like. Up.Time is pretty clever at spotting what's running on a particular machine (it noticed the MySQL instance running on one of our machines, for instance), but you can manually add things you'd like to monitor as well.

So there's basic stuff like file system capacity, but then you're into things like making sure your Oracle instances are OK (you can do basic or more in-depth checks), or do the same for MySQL, SQL Server or Sybase. Then there's Exchange, IIS and VMware on the application front, plus more than a dozen more general network services such as POP, IMAP, LDAP, SMTP and SSH. And if you have home-built or bespoke applications, you can build your own monitoring logic as a "custom" service.

As well as defining the services to monitor, you can also define what to do with regard to alerting you to problems. Alerting methods range from popping up a window on the screen through to email/pager alerts or alternatively running an external script (which you could use, for instance, to chuck an alert into your helpdesk system). Along with alerts, you can also define actions that the system will take when a problem happens; this could be an SNMP trap but it could equally be a script that tries to (say) stop and restart the email server process – and on Windows machines, it can be to stop, start or restart a service.

The precise behaviour of alerts and actions can be pretty finely tuned; you can tell it, for instance, to alert you only the first time a problem arises, so that you don't get bombarded by repeated problem reports. And because services and user IDs can be collected into groups, you can control who gets alerted, at what stage, for what service problems.

And there's more. You can define topological relationships between items on the network. Say, for instance, that your Web servers rely on your database servers, and that when the database dies, the Web server won't work properly – well, you can tell Up.Time about these dependencies so that when the database server keels over, you don't get hammered with zillions of error reports from the Web servers. Then you can define "maintenance profiles", which define when hosts and services are "allowed" to be down for scheduled maintenance – and so alerts will be suspended for the given entities during this period. Additionally, there's an extensive reporting mechanism for you to examine the behaviour of your various systems over time. Finally, add in a very nice Java-based help system that works just like Windows HTML-based help even though the system is running entirely within a browser.

Up.Time is, frankly, superb. It's exactly what a network manager wants, it has a vast set of capabilities, and yet even a relative beginner could use it.


If you want a piece of software to monitor your servers and the services they run, don’t bother looking at any alternatives: buy this one.