643 Words. Plan about 4 minute(s) to read this.
Until quite recently, Fluke Networks has meant one thing to me: beautiful, handheld network analysis tools used by network engineers to troubleshoot Ethernet LANs. I’ve used various Fluke meters off and on throughout my networking career. Reassuringly expensive and eminently capable, a Fluke meter in my toolkit was a crown jewel. Given a good reason – or even a mediocre excuse – I was happy to head into the data center, plug the Fluke in, and start diagnosing issues.
Fancy handheld meters are not all Fluke offers at this point. At Cisco Live US 2014 as part of a Tech Field Day delegation, I learned that Fluke has been offering network analysis appliances under the product name TruView. Fluke made the point that TruView replaces 5 other tools network engineers might use when diagnosing various network issues. Via an all-in-one interface, TruView offers the following major features:
- Response time analysis
- Retrospective packet analysis
- Network traffic analysis
- Device performance monitoring
- VoIP quality of experience
The Fluke folks also made the point (repeatedly) that all of these features were tightly integrated, such that the interface felt like a single tool to the user. To me, this was an implied poke at SolarWinds, which offers a very similar set of products via add-on modules to their core NPM product. SolarWinds can feel a bit disjointed at times. Observing the TruView interface in the demo, I felt the look and feel was both uniform and unified.
TruView is offered as an appliance that accepts input from various sources (SPAN, NetFlow, etc.) and streams data to disk where it lives in one of a variety of SQL databases that TruView uses. Nearly all of the TruView software running on the appliances was built in-house and not acquired, another point in favor of uniformity.
I made the following observations of the interface while watching Fluke demonstrate TruView:
- One of the better presentations of complex network data that I’ve seen in an NMS.
- The interface was clean.
- Web pages populated data at sub-second rates; the console seemed “snappy” to me for most queries demonstrated. Fluke claimed the level of responsiveness seen in the demo might have been slightly slower that a typical production environment due to hotel wireless negatively impacting the front-end interface access.
- Fluke stated that as the dataset grows or if the data being queried is spread across a multi-appliance Fluke infrastructure, then screen loads could take longer.
- Fluke showed drilling into transactional HTTP detail during a timeslice. The idea was to observe a timeslice showing an abnormality for a particular type of traffic, double-click that timeslice, and then get back list of all individual (and decoded) HTTP transactions flowing to that socket during that time.
I can summarize the Fluke presentation and demo in this way: TruView is optimized to help IT departments solve those awkward “the network is slow” reports. “The network is slow” is a clear statement of user experience, but maddeningly unhelpful in diagnosis. Tools are required to figure out the root cause of perceived slowness. Is the issue one of network congestion? A link with errors? Or an application level problem? Or something else? TruView hopes to get engineers to heart of the matter.
I blog this post about Fluke not just because they presented, but also because I had placed Fluke into this little box of “those folks that make the awesome meters, and I’ll call them next time I need one.” Companies grow, change, and adapt to the market. Don’t get me wrong. Fluke still offers handheld devices, such as the Optiview XG tablet that integrates with TruView, which they also talked about. But Fluke is more than handhelds these days. Anyone looking for a NMS that can do historical traffic analysis should include Fluke TruView in their evaluation process. From what I saw in an admittedly brief session, they are worth investigating.
about | subscribe | @ecbanks