OpsView is a Nagios wrapper found here: http://opsview.org/ . It is an impressive add-on for a business wanting a basic monitoring solution. There is a Web gui that allows you to configure Nagios with out touch a config file. They have added a few cool features like categories and the ability to have slave servers with hot failover. This means you can keep one central server that has on the configs. All you need to do is modify this one server and it will push out configs, scripts and what out to all the other servers that are setup in the interface. The interface is simple and easy to use. I was impressed as I started to use this.
Once I started to try and configure things is where I started to see problems or rather things that didn’t have enough polish. One of the biggest thing for me was that the web interface was slow. It took forever (10-15 seconds) to save a changes to a host or a service check. I had 40-50 servers that needed modification from the import of the current config. I got though a handful before I started editing the database directly. I could handle this problem because once you have all the machines setup you don’t need to do a whole lot of changing.
There were a few confusing points to the whole thing. Opsview uses host categories and service groups to figure out the contacts for each alert. I couldn’t find a good way to see how these were setup. It was confusing. It seemed like all the users that are associated with a server category got notified based of what the service was told to notify. Very confusing.
They don’t have support for host templates. We use these a lot in my environment at work. We have a bunch of servers that do the same thing. There are times when I need to make a change to all of them. This is where the Host template comes into play. I can just make the change to the host template and it gets changed on all the servers using that template.
A couple other things were issues for me. The Slave servers had to be setup from the master. You setup ssh keys and push out a script. You can’t install the software and say “you are a slave to X” and tell X that the server is a slave and have it work. In addition, I had to spend a bunch of time trying to get the packaging to work with CentOS 5. I eventually got it and reported what was needed back to the developers. Just frustrating. One last thing that is an annoyance, is that all the nagios scripts have to begin with “check_”. A lot of the custom scripts that we use don’t use that convention, since it makes more sense to call them something else.
One nifty feature that OpsView added to Nagios was the exceptions. You can specify a check with a given parameters and change it for a given host or a given time period. Very nifty feature. Not one that I currently need, but I can see the benefit for it.
Overall, I though this was a great package. I was impressed with the overall layout. I am sure that if you bought the package with the support, it would work a lot better for you. Since I am fairly knowledgeable with Nagios already, it had a few shortcomings. One of the best positives for this program is that the developers are fairly active in the Nagios community. I have seen them respond to people on the user list and submit patches back into the main Nagios line. This is how projects like this should operate.





