Having started out in the telecom industry (back when it was different from datacom – yes, I know, I’m old) I was always a fan of Fluke test gear, so I find it kind of amusing that they’ve decided to pick on OpenNMS to promote their latest commercial network management tool, OptiView.
I didn’t even know Fluke was in the network management business, so I was surprised when someone sent me a link to their website in which they feature part of an OpenNMS screenshot as their “wrong way” example.
I’m pretty certain they just grabbed this image off of the web because the text of the page could read as an advertisement for OpenNMS. They obviously didn’t do their homework. I thought it would be a fun exercise to examine their claims in the context of our project.
Lack of Proper Perspective
In this paragraph they state “Central polling misses performance from the user’s perspective”. This is true, and it is why OpenNMS has a remote poller that performs synthetic transactions from the point of view of remote end users and integrates with most popular mapping software so that engineers can easily pinpoint problems. This is in use at nearly 3000 sites worldwide for Papa Johns Pizza – it would be interesting to know if Fluke has an install on that scale, and if so, how much it would cost.
A False Sense of Security
They lost me a little on this one, but they seem to be saying “our monitoring is better than your monitoring”. OpenNMS has multiple levels of monitors, from simple ping/port checks up to capturing the full user experience with the Page Sequence Monitor and the Mail Transport Monitor. When OpenNMS polls for service assurance, it is, for all practical purposes, a user of network services and it reports back what a user would experience.
Lack Troubleshooting and In-depth Analysis
This section states the need for root cause analysis and “packet-level ‘on-the-wire’ visibility.
Well, as for root cause, OpenNMS duplicates the functionality of such classic management products as Netcool/Omnibus and Netcool/Impact, so I’m pretty certain it can address whatever it is OptiView claims to do.
As for packet-level inspection, this is one area that OpenNMS does not cover. One of the reasons is that with today’s large and distributed networks, it is not feasible to monitor every single packet on the network. What OpenNMS does do is indicate areas where there are problems, and then engineers can take their packet sniffer and investigate further. We often use Wireshark in diagnosing customer issues, once OpenNMS determines the part of the network needing attention.
Risks of an Incomplete Picture
This list of bullet points is pretty valid, but the assumption that tools like OpenNMS provide “an incomplete picture” is patently false. I tried to download their “NMS Risks & Shortcomings” white paper but got an error message “This area of the site is temporarily unavailable.” Heh.
This is typical FUD from a commercial company trying, and failing, to differentiate itself from other underpowered and overpriced commercial software tools.
But I must say I’m somewhat flattered by this since our goal with the OpenNMS project is to make every decision about a network management solution to include the question “Why aren’t you using OpenNMS?”
I’m hoping than everyone who might find this site asks themselves the same thing.
Perhaps they should be monitoring that page with a tool that like the PSM to let them know that their website is in “maintenance mode” (clever language for “Page not Found”). I’m pretty certain “deep packet inspection” is *not* going to indicate anything other than TCP/IP is working just fine.
Well, you caught us… and glad that we got your attention. It’s true, we did not realize that OpenNMS had remote polling, but the screenshot was used to illustrate the “typical” NMS ‘green is good’ screen (not to call out ONMS specifically) – and precious few NMS have the ability to measure from the point of view of the user. So I guess we’re in agreement on the point.
Scalability is determined by the balance of breadth vs. depth, and the cost of deployment (both $ and time for install and maintenance), but even more important are the needs of the IT organization: how mission-critical specific aspects of the network are, and the breadth/depth/capabilities of the network support team. Open source should indeed be considered, and IT shops should carefully weigh the pros/cons of open source via the typical build-vs-buy factors (time to set up and maintain vs. out-of-the-box functionality, support, etc.)
I’ll clarify the point about ‘a false sense of security’… What we saw at a recent visit to the network engineering team at a large hospital is a case-in-point. As is typical in most IT departments, they had the big screen up on the wall showing their monitoring system – a map of all of the key sites throughout the metro area. Status? Every site was “green.” Later in our meeting, we come to hear that they were having consistent problems with one particular application from one clinic, among other issues. But…everything was green!?! Point being, the public-facing NMS screen shouts to everyone (and hence projecting the false perception) “We’re good!” (Hmmm… perhaps it’s just a good “deflection tool” to keep Upper Management away.) Far from being an isolated incident, we often find this to be the case.
In our experience, organizations that put too much reliance on their NMS usually in time come to realize the lack of depth to solve tough performance problems, and they come to us for that visibility. Synthetic measurements are great (we use them, too) and can function as a cost-effective way to monitor performance. But make no mistake – they’re not the REAL application, not real user transactions. So, as you point out, the information in an NMS can be used to identify that a problem exists, who is affected and where you’ll need to do deeper analysis – with another tool. Wireshark is fine – for some. Fewer engineers entering the market have learned the skills to interpret cryptic decodes; commercial products like our ClearSight Analyzer do the heavy lifting for them, giving answers, not just data. Also, many IT organizations are looking to consolidate their tools and vendors, we’re pointing out that Fluke Networks has a way to do that.
So while helpful and even necessary, an NMS is just not enough. We stand by our statement that tools like OpenNMS are indeed an incomplete picture. The need to replace or complement their NMS is one of the main factors that have driven our customers to purchase of hundreds of millions of dollars of OptiView in the past ten years.
As to the website being down, we were indeed in ‘maintenance mode’ (typical weekend scheduled maintenance – wouldn’t you know it!) so try us again here http://bit.ly/93jQDQ.
@fnet_danklimke
I too have had a long standing admiration for FLUKE. Back when I was a bench technician, aligning 5.25 floppy drives on an oscilloscope, the “real” technologists used the FLUKE gear.
I think they are a great brand. I think their equipment is widely admired in the technology community. And it makes sense they are aligning with OpenNMS…