What is most valuable?
The most valuable feature for us is the flexible alert framework, which allows us to use a variety of alert methods, some custom to my employer. Also important to us is the ability to use the Nagios community to supply monitoring plugins for a wide variety of software and situations, freeing us from having to create them ourselves. Also, the API allows us to control Opsview as a part of other business processes.
How has it helped my organization?
Using the Opsview API, we can put a server in downtime programmatically as a part of our regular patching schedule, and even restore monitoring after the patching script has determined the target server is once again up and running.
What needs improvement?
In Opsview 4.6.3, there is no provision for making bulk changes to monitored servers via the GUI, though it is possible to custom-script bulk changes via the API. Some of this has been remedied in Opsview 5, released last Fall. I would also like to see the ability to export charts in graphic format, either PNG or JPG. Finally, the Keyword feature (renamed Hashtag in version 5) would be improved if it did not cascade from Service Check to Server and back--greater granularity would provide even more flexibility in assigning alerts to application owners.
For how long have I used the solution?
I've used it for 17 months.
What was my experience with deployment of the solution?
No, we had no problems deploying either the server or the agents.
What do I think about the stability of the solution?
No, we have had no stability issues.
What do I think about the scalability of the solution?
We have not yet had to scale up our Opsview installation; it was sized to allow for significant growth in agents.
How are customer service and technical support?
Our service representatives have been polite and responsive. My interaction with our other support staff has been very positive, informative and helpful. Opsview has a well informed, talented staff and discussions with them have led to useful insights. Using the earlier scale: 9. Technical Support
We have not had much reason to open support calls, but those few have been answered quickly and to our satisfaction. Using the earlier scale: 9.
Which solution did I use previously and why did I switch?
We previously used ITM, and the primary reason for switching was cost savings, but the increased scope of monitoring by the base Opsview product and the larger number of supported OS's were also factors.
How was the initial setup?
The initial setup was straightforward. We found the installation guides provided on the Opsview website clear, and after some additional discussion of our plans with the Opsview staff, we established a master/slave high-availability configuration without any particular problem. We incorporated the Opsview Agent RPMs into our patching and new-server-build channels and populated our entire monitored-server base quickly and without problem.
What about the implementation team?
We implemented ourselves, because we believe that's a critical step in fully understanding a product.
What was our ROI?
It costs 1/10 as much as the product it replaced.
What's my experience with pricing, setup cost, and licensing?
Opsview, though not the least expensive Nagios-based commercial monitoring product offers excellent value for performance which rivals expensive commercial products from the major IT vendors; it is well worth the money paid for it.
Which other solutions did I evaluate?
Yes, we evaluated a host of both major vendor and open-source based products, including ITM, BEA, NetIQ, Nagios XI, Groundwork Opensource and more than a dozen others.
What other advice do I have?
Do it yourself. Opsview support staff, both incident support and technical liaisons are knowledgeable and responsive, but you will find the greatest utility in the long term by understanding Opsview internals and UI by doing the work yourself. The Opsview installation guides are well-written and provide trustworthy sizing information.