Opsview Reviews

There are several valuable features for us, including ease of configuration of monitoring of new hosts/services, worker redundancy and load balancing, and the fact that it’s compatible with the plethora of existing Nagios plugins available on the web.

We have been able to drastically scale up and out our monitoring, after coming from a vanilla Nagios monitoring.

We are starting to hit the limits of how we can scale out. While the UI has always been snappy, it can take about 30 minutes from committing a configuration change to when that change is apparent in the UI, for example adding a service check to a host.

We've used it for three years.

During deployment, we were required to perform some database tuning, but there were no show-stopping issues otherwise.

Previously, an upgrade brought about some issues of instability. We were able to work through them, though, with the help of Opsview support.

We are just starting to reach the limits of scalability. We have ~3,500 hosts and ~40,000 services.

Customer service is very good. They're quick to respond and persistent when working through a major issue.

The technical reps know the product well.

We previously used Vanilla and Nagios. We needed a solution that was scalable but still supported our existing plugins.

The initial setup was somewhat complex, particularly importing our existing Nagios configuration into Opsview. We also deployed with several worker nodes.

Deployment and management is done entirely with our in-house team.

I believe we also looked at Nagios XI.

Take the opportunity to review all of your monitoring policies if you decide to migrate to this product.

The multi-tenancy that's available through this is one of the most valuable things. We have a whole lot of people who want to do their own monitoring and we are able to offer it up as a service to them, manage the infrastructure side of everything for them, and then give them their own little slice of this. They can take advantage of the distributed components that we have around the world and let them set up their own hosts. That's one of the big features that we really like about it. That's the number one thing.

We tried to find something else and we really can't find something that has that multi-tenancy that's easy to use, especially from the end user's perspective.

We now have the ability to offer that out as a service. People come to us and say we need to monitor this test bed. We're able to give that to them ,which in the past would have required me or my colleague to work with them and implement that monitoring and then support it going forward too. There was no self-service there at all and we'd always get engaged. It's allowed us to be able to focus on other things while this is providing that service. It's given us some time back, which would be the biggest benefit.

There is one feature that I've been requesting for a while now. Going back to this multi-tenancy thing, right now the tenants can't create their own service checks, so that's still a process they have to get with us. Once we get a check in place, they can then utilize that check across all of their hosts. It's like a one-time thing to set that up with them. It would be nice if they could even implement their own service checks and there was some way to introduce that into the distributed system from a tenant perspective, not just a global admin perspective. That's one feature that I think is missing and I've mentioned it quite a few times to the guys over in their ops unit.

Another thing that we thought would be kind of neat, would be if there was some kind of integrated logging service. We've got this distributed system already in place and I know it's a monitoring service, but it would be kind of cool if there was something that could catch syslogs. It could have a module in there to view the syslogs from all of the different sites and use that as a syslog aggregate or something along those lines. It would be kind of like what Splunk does. If we could get that functionality inside of here, because we've already got all of these things around the world and if we could just leverage that to do this, then that would be kind of neat too.

We've used it for about two years.

For the most part it’s stable. We had some issues when I took the product over from an engineer who left and we were dealing with scalability. We had to address how it was architected. Opsview was pretty good about getting with me and helping me to come up with a plan and correct that. When we rolled out that solution, it's been pretty rock solid ever since. We haven't had many stability issues.

Every once in a while, we'll hit some kind of weird, wonky bug or something like that and we'll get with them, and either there's a fix or there will be a fix and some update or something along those lines.

We had a scalability problem about a year-and-a-half ago where the number of monitored hosts was growing and the database was not able to keep up. But going forward, I don't see any problems with scalability. The downside of continuing to add more sites and distributed slave components at those sites is that reload times increase. I have to continue to use Nagios to prevent this, but it would be nice if it didn't have to be this way.

As we scale, we could set up slave clusters, which has worked.

Nine times out of ten, you put the ticket in, you get with somebody who's very knowledgeable and is able to help. I think maybe once or twice there's been a ticket where we didn't get the attention. But I think that's probably going to happen anywhere.

Overall, I'd say it's been very good and they've been very responsive. Right now, we're going through an upgrade process that requires a big migration. I put a ticket in and they contacted me within 30 minutes. It was not the exact resolution that I needed, but at least they started the conversation.

We have to set it up again because we're migrating and upgrading, which is complex with many moving pieces. We're moving from v4 to v5 and I have to learn the differences and the underlying components.

Without prior experience, setup would be pretty complex. v5, however, offers an auto-installation function, making new installations a whole lot easier. The problem is that we have existing employees still using v4, so the auto-installation doesn't work for them, and we need to get down into the nitty gritty.

As long as you have your expectations on what the system is, then it'll probably meet those expectations. But if you want it to do things that are beyond what it's designed to do, you might need to look at something else.

The most valuable features for us are the modification profiles and the initial dashboard. They're also the two main things we use the most.

We've improved greatly. We previously used another monitoring system, and although it was good as we were able to receive statuses on several hosts, our growth has been exponential the past four years. Because we've been able to use our monitoring system, it's helped us to stabilize and make sure that every single network item that we add is properly monitored. Of course, if there's anything wrong with a device, we'll know right away. That's really the main purpose of the monitoring system. It's helped us and our customers to maintain a good little service.

We're already evaluating v5.0 and to tell the truth, there's a couple of things that we found really useful in previous versions that for some reason they have removed. For example, in the current version, it's pretty easy to go into the host detail just by having a simple click into the host, but for some reason this has been removed in the new version. It was really good that you could just click on the name of the host and it took you to a more detailed view of the host itself or the item, and now that feature is gone in v5.0.

We've used it for close to six years.

We've had no issues with deployment.

Of course, you have to maintain the database. But to tell you the truth, we've put enough pressure on the system itself and it's been pretty reliable so far. It's low maintenance and a very, very reliable system.

Over the past three years, we've grown by about 200%, and the system has been able to manage that growth.

The customer service is good.

They're very knowledgeable and proactive. Whenever we have an issues, we do open up a ticket. There's a really good follow up on the ticket.

The setup is easier now than before, and it looks like v5.0 is more straightforward. There's a definite improvement there.

It was in-house with remote support, tickets, follow-ups, and things of that nature.

Start about growing the system from the start. In other words, when we first started using the Opsview platform, we didn't think about being able to have a redundant environment for the system. We didn't think about that many hosts or that many items that we were going to monitor. My advice would be if you're about to start, think big right from the start. It will save you a lot of headaches, and not necessarily because Opsview is bad or not performing well when you try to escalate the system, no. It will definitely be easier for you to start balancing loads and creating backups and things of that nature. If you're going to start using it, go big.

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.

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.

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.

I've used it for 17 months.

No, we had no problems deploying either the server or the agents.

No, we have had no stability issues.

We have not yet had to scale up our Opsview installation; it was sized to allow for significant growth in agents.

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.

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.

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.

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.

We implemented ourselves, because we believe that's a critical step in fully understanding a product.

It costs 1/10 as much as the product it replaced.

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.

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.

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.

The most important feature is the distributed, highly-available monitoring clusters available in the enterprise editions. As we run multiple sites around the world and every second of service disruption costs us money, this feature is critical.

The second most valuable feature for us is the extendability of the service checks and event handling (auto-correction).

The third most important feature was the single point of configuration.

The fully-extensible event handling has enabled us to reduce on-call incidents by more than 90%. Setting up monitoring of a new site now takes a few hours, when it used to take days.

The graphing feature needs work, although it has been rewritten in release 5.0 and we have yet to deploy it.

We started with Opsview community (which no longer exists), so overall we have been using the Opsview platform for five years. It has been our only monitoring system in production for more than three years.

We have not experienced any significant issues. We have had one slave crash in five years, and due to the redundancy, there was no loss of monitoring. We had the master break once, but due to the independence of the monitoring slave clusters, all we lost was the central management. Each slave can be run with its own web interface.

10/10

10/10

We previously used a combination of Big Brother, Ganglia, Cacti, a Syslog server, and an in-house monitoring solution. We selected Opsview over its competitors primarily due to the distributed full-redundancy. Second on our list was the replacement of many systems with a single configuration point.

The setup of the product itself was quite simple. A great deal of development was needed to recreate the custom checks that had been performed by our previous in-house monitoring system.

I performed all development and implementation for the company. Since Opsview can use all Nagios checks, there is a huge number of scripts available. You can check out some of my stuff at https://github.com/nguttman/Nagios-Checks.

When it comes to monitoring of a real-time product like VoIP, I don't think in terms of ROI, I think in terms of SLA and sleepless nights. The product has significantly improved our effective SLA, while virtually eliminating the dreaded 2 AM call.

While the product is not perfect, it is better than any other product I have seen or worked with. If you need geographically distributed, highly-available monitoring, this product is great. If you do anything remotely real-time, then you should want your monitoring to be highly available.

The ease of automating and scheduling work processes to eliminate manual tasks.

You can group jobs by functional area (Lab and RAD), or by similar output, and results such as scheduling reports for departments. Visual display of successful jobs and failures is easy to see at a glance. You can also automate error reports and email them to your support team.

By grouping jobs into categories such as Lab or RAD, when an end user calls with an issue, it makes it easier to troubleshoot. You can go directly to that functional group and look for failures.

It reduces the need to manually enter jobs, which enables the analyst to focus on other tasks than are more important or which do not have the ability to be automated.

I've been using it for over 10 years.

Excellent customer support from Cerner.

I've never installed Opsview Monitor or Scheduler. I believe these are standard applications that come with implementing Cerner Millennium. Many companies reserve these applications for system administrators as they are normally at a higher technical level of understanding and implementing. These tools are great for monitoring and adding new jobs by an applications analyst.