Opsview Reviews

We use Opsview's cloud version because we wanted multiple collection points since we have a global network that spans Europe, Asia, and the US.

The false positive alert rates have decreased significantly, probably by 90%. One benefit I saw using Opsview is that the cost model was similar to what we had with other tools. It didn't increase our opex cost. Similarly, Opsview has a single pane of glass, which is nice. We could drill down into a particular site and see everything and the relationships. We could see an alert in the middle of the network, making alerts more actionable. We could see if multiple things were happening simultaneously, which told us something different, like if we lost power or network. The visibility became much more granular because we could see and select a site. If it was yellow, we could drill down and see what was triggering a yellow alert, which might not be necessarily actionable but more cautionary.

Another key thing was we could assign "read access" to other teams. They could be in one of the other countries and be a technology support member, maybe over servers or something else. They might see something unusual in their environment, and they could then go over to Opsview and see if it was reporting anything at that site related to what they saw on their particular environment, which may use the network for whatever access report. Though it's not quite self-service, it is. We allowed other teams access, and the benefit of that was we didn't get many calls about, "The network is x, the network is y, the network is z," because those teams could see the network was up. It was something isolated to their working environment, whether servers, databases, or web services.

The other interesting thing about Opsview, which I call "phase two," was that we were gonna move our server environment onto Opsview, and they would have their pane of glass for their servers, and we would have read access to that. We would have our own pane of glass for the network and give access to the other teams. The biggest point was visibility across different working environments, servers, and networks. And later on, phase three would be web services. Opsview gave us the ability to consolidate some of our monitoring tools. We had a monitoring tool for this, a monitoring tool for that, and the goal over the first year was to consolidate the monitoring tools and have more actionable alerts while allowing everybody to see what was going on in parallel domains.

I would have to choose two features: Investigate Mode and Troubleshooting.

All the useful information is right there in tabs for me to check on graphs; check if and when notifications went out. I can make notes on a particular occurrence, and check the history all of these features. It saves me time when troubleshooting an issue with an interface or service. Speaking of troubleshooting, the ability to test the script or plugin right from this Investigative mode is my second favorite feature.

Opsview is used to monitor system availability, whether its service is running on disk usage, CPU usage, etc.

Opsview provides us visibility within our platform. So, we know what's going on at all times with all servers across the platform.

My company uses the product for monitoring services.

I am not close enough to know what my company's teams require more in the product.

Pricing and a few certain aspects in the solution needs to be improved. I don't know much since I am not involved in it.

It's a good solution. It covers all aspects of monitoring purposes.

It's in good shape for me now. We moved to the cloud, so cloud ops, we're using.

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.

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.

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.