NetSensory has a fairly simple purpose: to enable the system manager to track down the cause of application performance issues. Although you can buy it as a “virtual appliance” that runs under a VMware instance, you’d most likely buy one of the physical appliances in the range.
There are two types of appliance: the “probe” and the “director”. There are three models of probe: the NP-500 (a 1U device with two copper “traffic ports”, which is rated at 12,000pps), the NP-2000 (again 1U, but with a tenfold throughput increase and two fibre Gigabit ports added) and the NP-3000 (25 percent faster, but with double the storage of the NP-2000). The director is an aggregation device - it interfaces to the probes and co-ordinates their operation, so you can work with distributed data via a central unit.
The appliances are commercially-available servers rather than custom-built; according to the vendors this was a deliberate choice since mass-market servers are less likely to have problems than niche-market appliances. The applications themselves run on a BSD-based Unix-like kernel, with heavy use of Java for the GUI applications.
The first interesting point about the probes is that they’re passive. That is, they don’t sit in-line with the network but simply monitor packets as they fly past, either via a cable tap or, more likely, courtesy of a mirror or span port on an appropriate switch. This is an excellent idea, because it means you’re not slowing down the network by putting the monitor in the way – and it also means that if the probe dies for some reason, it won’t break your operation.
Once the probes (and, optionally, the director) are up and running, you can use a simple browser-based interface to set up the basic parameters - IP addresses, backups and the like. There’s also an interface into the results of scheduled reports, so that users without the GUI installed on their workstations can easily get at them. On the whole, though, you interact with the devices via NetSensory Console, the Java GUI. You download and launch it from the browser-based interface – a very simple process.
When you log into the system it can take a few seconds for the console application to get started if, like us, you’re the other end of a WAN link from the device you’re talking to. If you’re on a faster network, it loads in no time at all. Once everything has come to life, you simply select the device whose data you’re interested in (a probe or a director) and you can start digging into data. The data can be displayed in either tabular or graphical form, and you can look at things from pretty well any angle – by application, by address, by business group (i.e. collections of devices you define yourself), by protocol, and so on.
The system also incorporates the concept of “insights”; these are basically customised views onto collections of data that you deem particularly relevant – useful because it gives you a very quick way of getting to the stuff you commonly want to see without having to dig through the standard menus which, by necessity, work on the entire universe of data stored within the system. There are loads of different options for insights: so as well as basic data tables you could have a dashboard of top-talker applications, or a graphical view that shows the trend of a particular data item over time. There’s even a “worm hunt” insight, which watches for behaviour typical of worms (basically lots of half-made connections – common for a worm that’s scanning to see what’s around).
Drilling down into data is very, very simple; just click on the expand box beside an item and it’ll explode the list into its constituent parts. Performance is pretty speedy, too: even with the time-scale set to a month, it takes only a couple of seconds to expand the detail and re-draw the list.
The system works by storing the packet header information for everything it sees flying down the wire, but quite sensibly it only stores the complete detail for the most recent data. So the past two weeks’ data is stored as a minute-by-minute average; from 14-30 days old it’s stored on a five-minute average; from 30 days to six months it’s a 60-minute average, and from 6-12 months on a 24-hour average. Nothing more than a year old is stored, but since the main aim is to look at what’s going on now, and to a lesser extent what happened recently, this lack of ancient data is not a problem.
As well as actively looking at what’s going on, you can of course have the system alert you if it thinks something is wrong. Alert thresholds can be defined quantitatively (ie. if the loading of a network segment goes above a particular number of kbit/s) or relatively (ie. it watches to see what seems to be “normal” operation, and alerts you if things waver too far from the norm). Similarly, reports can be generated on the fly or based on a schedule, and viewed either on the device or by having them emailed around to people.
Although we got to try live NetSensory probes ourselves, we also had a rather unusual invitation from the vendors to visit a customer site and see how they use the package. The customer we visited was the London office of a commodities trading organisation with 50-odd offices around the world, a turnover of about $45bn, and a collection of NetSensory probes with a Director sitting in the middle.
The techie we met was clearly tremendously impressed with the package – and in fact they don’t really use many of the features at all, since what they’re mainly interested in is the ability to start at the overview level and then drill quickly into the detail to find why something’s particularly busy, or seeing a particular number of connection failures, or whatever. It was clear that he hadn’t been primed by the vendor to say nice things (it’s worth mentioning at this point that there wasn’t a Network Physics person there to make sure he said the right things!!) – he was simply really happy with what it did for him, and how easily he could find out what had been happening on the network without farting about delving into RMON data and suchlike. It’s a proper 24x7 company where time literally is money, and he couldn’t emphasise enough that taking time to figure out what’s gone wrong simply wasn’t an option.
NetSensory is, then, a very nice piece of kit. Its passive nature eliminates the usual “will it break my network?” concerns, the data storage is sensibly done, drilling down into the data is blindingly fast, and it has a good range of customisability (the Insights feature) and reporting. The GUI’s excellent, and any complexity in using the various screens will undoubtedly be down to the sheer magnitude of the data, and certainly not any drawback with the design of the interface.
With this kind of system you can start with just one or two probes as stand-alone entities and then add a director later to provide an overview if you so wish.