Share your experience using Opsview

The easiest route - we'll conduct a 15 minute phone interview and write up the review for you.

Use our online form to submit your review. It's quick and you can post anonymously.

Your review helps others learn about this solution
The PeerSpot community is built upon trust and sharing with peers.
It's good for your career
In today's digital world, your review shows you have valuable expertise.
You can influence the market
Vendors read their reviews and make improvements based on your feedback.
Examples of the 83,000+ reviews on PeerSpot:

Network Engineering and Operations at a manufacturing company with 1,001-5,000 employees
Real User
Responsive and easy to customize alerts for, while being priced similarly to its competition
Pros and Cons
  • "What was very compelling about OpsView was that we could dial out the noise and have meaningful and actionable alerts."
  • "Customized reporting can be improved."

What is our primary use case?

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.

How has it helped my organization?

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.

What is most valuable?

We had a lot of noise with other monitoring tools. What was very compelling about OpsView was that we could dial out the noise and have meaningful and actionable alerts. For example, if other monitoring tools saw something, they immediately generated alerts. With Opsview, we could say, "If you see this for x minutes, then give us this type of alert." Because maybe it's a yellow alert that is not an email. "If you see this condition for more than x minutes, generate a red alert and email us." That way, we weren't getting flooded with all kinds of non-actionable alerts. That's the term I used with my team, and they embraced it. "Every alert should be actionable."

What needs improvement?

Customized reporting can be improved. Opsview has a lot of canned reports, and though we were getting a lot of them, the reports we wanted to generate would say what the usage rate during their working day was. Many tools say, "You're at 50% utilization of the network for the week." But those reports are useless because they are looking at a 24-hour day. If you're 100% utilized during the day and zero at night, the week would show 50% utilization. We needed to see the reports to show what Opsview did very well and what the usage is for their business day from 7:00 AM to 7:00 PM, local standard time. Those reports were standard.

However, it required another level of expertise when we wanted to look at creating custom reports that would go outside of those canned reports. We had it, but it just meant we had to put our thinking caps on. If the other teams, such as the server or the web team, wanted to do the same custom reports, their people would need to get trained on that because my team didn't have time to generate custom reports for other teams. The custom porting was very good, but it took an extra level of expertise that we needed to be trained on. An area of improvement would be to make the custom reports a little bit more intuitive and less scripting.

For how long have I used the solution?

I've worked with Opsview for less than a year.

What do I think about the stability of the solution?

Opsview is incredibly stable. We only had one maintenance window, where people said, "It's going to be offline for two hours while we update the backend." But the good thing is we did not do the updates. They did all the care and feeding of the OS, the apps, and the databases.

What do I think about the scalability of the solution?

We didn't see any scaling issues with Opsview. We may not have used it with thousands of sites, so I can't say how it would run on thousands of sites as opposed to our deployment. We had maybe less than a thousand things that it was collecting on day one, and we're gonna add another 2,000 or 3,000 devices or endpoints at the end of year one. From our standpoint, being an enterprise that needs less than 5,000 devices, Opsview was very scalable.

Between 25 to 50 users in my company have access to Opsview. Still, in each domain on the network side, there are maybe a dozen people in the server team and a dozen people in the server desk, so 25 to 50 people easily access the solution at different levels. The service desk has access to the network and the servers, but they only have read access. They can't go in and do any admin work. The network team does admin work on the network, and the server team does admin work on servers.

We plan to increase the usage since our goal was to start the network and add web services later.

How are customer service and support?

They are very responsive, but they're not perfect.

How would you rate customer service and support?

Positive

Which solution did I use previously and why did I switch?

We used several other monitoring tools that didn't give us all the details, the visibility, and the reporting we were looking for in a single pane of glass, and OpsView gave us that.

There are other tools out there designed for scalability, such as Zoho. When we started loading up different sites on other tools with the same environments we had in Opsview, Opsview was much faster. If I wanted to pull a NetFlow report on the other tool, I had to sit there and wait minutes for it to go through and churn through a more legacy, SQL-type database. It was incredibly slow and painful, and you'd miss the window to easily capture stuff. Collecting NetFlow information on Opsview was wonderful and quick in contrast to other tools that we had that were just lethargic with 5,000 devices.

Opsview gave much better visibility than the other tools. We also ensured the service desk has visibility so people don't start calling us and saying that there's something wrong with the network or the server farm when it is something else. When we look at Opsview and the site, we see nothing wrong with that site. No errors are being reported, no outages, no service degradation, and no slowness. We could easily call root cause analysis or troubleshooting because we could rule out what was working and not working, what was slow, not slow, or impaired.

By contrast, other tools had lots of noise/alerts that were not actionable. And we were spending an inordinate amount of time trying to dial out the noise on the other tools, which was incredibly painful. At some point, we had to stop fighting with the tool and just throw it out the back door and start over, which we did with Opsview.

How was the initial setup?

An SME from the UK set up a few sites in Opsview, then reached out to different team members and showed them how to add other sites. Certain people were assigned to creating sites in Asia so they would learn how to do it and be able to better support it. Other people were tasked with building up the sites in Europe. And in about two weeks, we added all the sites. This included the training and the one-on-one between the SME and the other engineers assigned to help load it. I had two people in Europe and Asia who collectively learned how to roll stuff out. If they rolled it out, they understood the chemistry of how and what made it work. And then, we did group training on how to dial in certain parameters, which dialed out the noise. We didn't have one person say, "Okay. It's ready to go," we had half a dozen people actively involved in rolling it out. The workload was shared, and knowledge transfer also occurred. We got all this done within a matter of a month. We had all of our sites up and running on it. Even with the training and the segmentation of two people working in Europe, Asia, and the US, it came together very quickly.

We had six people, and it took a month to deploy Opsview, but one person could do it in two weeks. But we chose to cross-train and use about six resources scattered across the globe so that they would all be a part of rolling it out and, therefore, understand it to be able to tweak it where it needs to be tweaked and generate custom reports. That part of it took an extra couple of weeks, but it was because we made it a directive that not one person would be responsible for this. It was supposed to be the team that would be responsible for this.

What about the implementation team?

When deploying Opsview, we had an SME in the UK, and I used the term "each one teach one." Even though he had much more experience with it, I wanted the entire team to be familiar with it.

What was our ROI?

If you factor in the time people spend on a tool to get it working right and perform optimally, the ROI on Opsview is very high. When you look at the service's labor and cost per month, it's hard to do an ROI. If you say, "Hey, I've freed up 40 hours a month of network resources, and we have to fiddle with the other tools to get them to do what we needed to do," that creates an ROI that's hard to calculate. But it's very meaningful because you've allowed those resources to work on other more strategic things rather than fighting with a monitoring tool, which we didn't have to do with Opsview. Once we got up and running, it was fine-tuning and spending a couple of hours here and there, whereas the other tools would take days per month of effort.

What's my experience with pricing, setup cost, and licensing?

The solution is priced similarly to other tools offering similar features. I rate their retail price a ten out of ten, a five out of ten after we've negotiated based on the number of licenses we need.

For example, if you call Microsoft, they might say it's $199 per year for something. That's retail. Then we call up and say we need 5,000, and then it's $99, which is much more market competitive. Here, their retail price was not competitive, but their volume price was competitive.

Opsview is a bundled solution, so everything we needed was in the pricing model. We weren't nickel and dimed to death for other things.

What other advice do I have?

When management saw Opsview running and what it was doing and delivering, there was one word from them: "Wow!" Some said, "We trusted your judgment, but we were still scratching our heads as to why we would change monitoring platforms." They respected the fact that it was a team-based conversation. It wasn't us managers or directors saying, "We're gonna put this in." It was kind of grassroots, and the comments were, "Wow, this thing is a lot better than we ever thought it could be. And now we understand why the team wanted to deploy and use this instead of other tools we had."

To anyone considering implementing this solution, I would say that, if they're global, they should add additional collectors in those regions rather than having one collector in the US that's reaching out to Asia and Europe. In our case, we had three collectors: US, Asia, and Europe. That's one thing I would recommend is that you have collectors for your global footprint in that region, which will improve its speed. You're accessing it locally, not sending a packet across the pond to the US and back.

The other thing I would recommend is that they cross-train more than one person to roll it out and cross-train more than one team to use it because using it improves visibility.

I rate Opsview a nine out of ten.

Which deployment model are you using for this solution?

Public Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Amazon Web Services (AWS)
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
Jeff Cronstrom - PeerSpot reviewer
Senior Director, DNS Engineering & Network Operations at CloudfloorDNS
Real User
Top 20
A highly stable solution that can be used to monitor system availability
Pros and Cons
  • "The most valuable feature of Opsview is the ability to clone the services when you're monitoring something out of the test setup."
  • "Some of the graphics on Opsview could be improved."

What is our primary use case?

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

How has it helped my organization?

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

What is most valuable?

The most valuable feature of Opsview is the ability to clone the services when you're monitoring something out of the test setup. You can clone that service, and it allows you to add new services quickly. You can bring up new servers, and you can easily add them. Also, there's an API to be able to add services as well.

We don't use the API. We mostly use the cloning function because it stores everything in a back-end database. The underlying monitoring platform for our version is Nagios. That's where we upgraded from Nagios to Opsview.

What needs improvement?

Some of the graphics on Opsview could be improved.

For how long have I used the solution?

I have been using Opsview for eight years.

What do I think about the stability of the solution?

Opsview is a very stable solution.

I rate Opsview nine and a half out of ten for stability.

What do I think about the scalability of the solution?

I rate Opsview an eight out of ten for scalability.

Which solution did I use previously and why did I switch?

The extensibility of Opsview is via the underlying agents or plugins. With Nagios, you have the ability to write your own. Those you can instantly plugin, and it's extremely extensible depending on your knowledge of how to create plugins for it.

How was the initial setup?

The initial setup of Opsview is straightforward.

What was our ROI?

We have seen a return on investment with Opsview.

What other advice do I have?

I use an older version of Opsview. Opsview is deployed on-cloud in our organization.

I would recommend Opsview to other users.

Overall, I rate Opsview an eight out of ten.

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