Network Monitoring Software » SolarWinds NPM Reviews » Review

SolarWinds NPM Review

Strengths include steady development and strong focus on Windows but don't install it on a multi purpose server

Solar Winds Orion is a strong contender in network monitoring up to (at least) mid size enterprises. It’s particular strengths are steady development and a strong focus on Windows. This focus gives it the ability to drill deeper into application monitoring with less effort than most of it’s competitors through WMI. SNMP is also supported for non windows devices to round out the mix. The interface is primarily the web console, which is highly configurable and can display completely different options for different users/groups. However, building maps and setting most alerts require a separate installed application for the former and console access to the Orion server for the latter. Orion uses MS SQL on the back end, and with more than a small network requires a separate DB server from the web server and agent server(s). Yes, you can use multiple monitoring servers for large networks. Pricing is tiered, both for the type of monitoring (straight network, application, and specialty items like VMWare are separate SKUs) and # of monitored objects.

Competitors - quite a few. Whatsup Gold was purchased by Solar Winds a couple years ago but is still a separate product. Others include Nagios, MRTG, Cacti, on the open source side, and a host of ‘monitoring’ systems on the paid product side. Keep in mind that some of these are less monitoring than ‘is it up’ ICMP pings, but there is a good range of monitoring. I’ll let you inspect the field - this review is pretty good: http://www.networkmanagementsoftware.com/network-management-software-smackdown . Orion was selected as winner by the site, but keep in mind your needs and resources may vary.

Resist the urge to install monitoring on a multi purpose server, and think very hard before using a ‘spare workstation’ or old server. It benefits from lots of memory, and the DB needs adequate disk performance. Database activity is greater than you’d think from the size (especially when opening a graph or running a report). Also keep in mind the aphorism that when problems occur it’s impossible to always self-monitor; the very tool used may be the problem.

Disclosure: I am a real user, and this review is based on my own experience and opinions.

Feb 05 2014

Next Review: With an easy-to-use interface for…

2 Comments

Head of Data Center at a university with 1,001-5,000 employees

View Profile |

Hi Randy,

Thank you for the thorough review. You have mentioned about it requiring a fairly decent server. In our case, it's fully virtualized but still just a single VM to monitor 500 elements at most.

I'd like to focus on this since we will be adding additional devices for monitoring this year. My question is, should you go for unlimited elements ( we are seriously contemplating about this), what type of system requirements are we looking at? I'm also wondering about the 2000-element requirements, as budget might constrain us to just that.

Any advice would be highly appreciated.

Kind Regards,

Francis

11 February 14

Systems Engineer at a healthcare company with 1,001-5,000 employees

View Profile |

First, I hope you've updated - the current release (10.6) of NPM has some really neat features, like instant access to server error logs and process monitors. Second, if you're just using the Network Performance Module (NPM) you're missing a lot. Application monitoring gives a much better picture of what's going on with your servers; the two together are pretty impressive.
As for sizing, we found that the newer capabilities a couple years ago added so much load we had to move the database to a separate server. Even then we were dropping data (empty space on the graphs) and replaced the monitor server last fall with a virtual system. We were on an older 32 bit server with 4 GB of RAM, moving to a 64 bit system gave us plenty of power and we no longer drop data. However our database server should be replaced; some reports and screens run slow when a lot of data is requested. It's a user experience issue, not a failure, so your milage may vary. Again, older hardware and 32 bit processors. Approach this in a stepwise fashion (separate the database first, etc) and you'll be fine.
Last point - be careful when adding monitors. It's easy to monitor too much; separate what is 'must have' from 'nice to have', add the 'must have' first and check system performance. That includes slow or saturated WAN links; it is possible to overload these with the extra traffic.
Let us know how the project goes!

12 February 14

Guest