Network reporting tools are a necessary evil for the SME. We unravel the mysteries of Syslog
There’s a point when running your own small business network where all the monitors start to get you down. At the outset, with just one PC acting as a server, leaving a monitor on it seems natural. But once you have three or four machines doing some part of the continuous duty roster typical in a modern small network, four redundant monitors look awful – they’re always the spares, and the screens are burned deeply with the images of your most frequently repeated, least critical error.
When the time comes to tidy up that nasty pile of monitors, several home truths tend to hit home all in one shot. The first is that many functions can now be undertaken very nicely by small headless special-purpose boxes. Furthermore, the days of errors being all about fatal crashes and blue screens are largely behind us, and much of what happens in your LAN can only really be dealt with once you have more than just one dialog box’s worth of data about it. Lastly, the Event Viewer is a bit of a desert island: not every application uses it, and not every error-reporting collector analyses what happens inside it (plus, those little boxes like routers, print spoolers and firewalls don’t speak Event Viewer anyway).
This brings us neatly to the subject at hand here. You’re probably already running more than four or five services (for example, a firewall, an email server, and some dedicated single-purpose black boxes like NAS storage or proxy servers), and all of them have moved on from failing every week to sitting in the midst of a stream of traffic that you need to analyse over a period of time. In the case of a set of servers monitored by an IT professional in an outsourced support relationship, this can be over a very long period of time.
This is where, in smaller networks, Syslog comes into its own. It’s another one of those 30-year-old monsters that has its own internal logic, and a rich variety of impenetrable customs and standards that have to be unearthed in order to be useful. Despite an early start at the turn of the 1980s for the utility, the IETF (Internet Engineering Task Force) has only recently, in 2005, attempted to hold the chaos of different Syslog formats to some form of standard.
Never mind that lengthy gestation period, the blossoming of boxes able
to spout Syslog messages onto your network raises the problem of what to
do with them. A complete standard is a way off yet, but there are some utilities that will at least make it easier for you to contemplate your role as the Sorcerer’s Apprentice with perfect reliability.
Options
Before we discuss those utilities and their use, there are a few other contenders for this role that should be identified, if only to reject them. One is SNMP (Simple Network Management Protocol). This too falls under the ambit of the IETF and, in fact, the group has had a good few bites at refining what’s in it and why it should interest you. The problem is, it was developed to run on devices even smaller than the ones we’re likely to see in a modern network today. Cisco, the guru of the router marketplace, is very big on SNMP – which you should take as a sign that it’s generally used and found in much larger, centrally planned networks.
Alongside SNMP (and, in some cases, actually making use of it for inter-machine interrogation) are the giant network management suites from IBM, Computer Associates, HP and their competitors. In this field, names like Tivoli, Insight Manager and CA IMS signify whole universes of software, spread across workstations and servers, reporting every last collectable statistic and foolishly erased application – and, most importantly for our purposes, also responding to queries sent out by a central management workstation.
This is the opposite philosophy to Syslog. In a Syslog world, the central logging machine does the listening and the satellites do the talking: there’s
no live query process to go back to something that’s fallen silent or might have been interfered with. A Syslog source just fires its one-liner reports at an IP address, which it’s been assured hosts a Syslog server.
There’s also one missing link in the picture here: I mentioned that the Windows Event Log is a bit of an island in a network with a lot of other platforms. In fact, it’s a bit of an island even in a homogenous network, because you get to it through the Event Viewer and there’s no immediate consolidation – you can read events on another server well enough, but you can’t sort together all the events of the same type or from the same source. Even though I’ve been talking about design concepts and constructions, there’s one plug-in without which the idea of getting intimate with Syslog seems somewhat pointless, and that’s NTSyslog (ntsyslog.sourceforge.net): this service reads Event Viewer entries and fires them at a designated Syslog server. Snare (www.intersectalliance.com/projects/SnareWindows),
is a little bit more of the same.
Now we have all our error messages from all our devices arriving in the
same place and subject to the same manipulation.