Opsview Reviews

Our primary use case is monitoring our deployments.

The most valuable features we find in Opsview are the dashboards, more or less, just the real-time updates on the dashboards.

Opsview's alerting capabilities are very helpful, and they positively impact our incident response times.

There is always room for improvement, and part of the reason we're looking at Grafana is because there are things it can do that Opsview cannot do as well.

Grafana does have features that I think my current solution lacks, such as better performance reporting.

We have been using Opsview for eight years.

I was part of the decision-making for the implementation, but I did not actually do the implementation.

The implementation was simple, and I did not have any issues.

We are still using Opsview, but we are looking more to use Grafana now.

We are consolidating on Grafana because we do not want to have too many platforms.

We are using Opsview ourselves, rather than being a consultant or a reseller.

We do not use its auto-discovery feature.

We do not utilize its API driven architecture.

I do not know what metrics we use to assess the effectiveness of Opsview's hybrid IT monitoring.

Overall, I am pretty satisfied with Opsview as it is good for what it does.

I do not know if Grafana has any other advantages besides better stats, as I am not involved in that side.

Based on my experience, I would still recommend Opsview to others as it is good for what it does. I gave this review a rating of 8.

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.

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."

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.

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

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.

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.

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

Positive

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.

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.

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.

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.

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.

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.

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.

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.

Some of the graphics on Opsview could be improved.

I have been using Opsview for eight years.

Opsview is a very stable solution.

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

I rate Opsview an eight out of ten for scalability.

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.

The initial setup of Opsview is straightforward.

We have seen a return on investment with Opsview.

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.

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 features are the file system process monitoring, CPU memory, jump rate process, uptime monitoring, tail light, and call.

There is room for improvement in terms of pricing and customization. 

Maybe the graphical representation can be improved. It can be enhanced for better visualization. It could be a little better. And the graph center can be improved.

When it comes to additional features, some automation reports should be enabled, like CPU and memory. So I want to generate a report for all the servers. I need to know yesterday's average, minimum, and maximum CPU usage, as well as the minimum utilization on the servers.

I want to automate the report generation. It would be great if any product in our system can provide that functionality. It will be helpful for the customers.

I have been using Opsview for four years now. 

It's working. Sometimes the collector goes off, but it restarts by itself. Occasionally, it happens. During those times, we need to restart the services and investigate what is happening.

I would rate the stability of this solution an eight out of ten. 

Scalability is fair. I would rate it an eight out of ten. There are around 60 users in our organization using this solution. There are no specific job roles. Everybody will be using it to check the enrollment status.

When we moved to the cloud, it was easy. However, we had to seek support, which took some time. But the initial setup on premises is a bit hectic, and the upgrade process is quite extensive. Opsview made it very complex, and I'm not sure why. It should be a little more straightforward, simply put.

I would rate my experience a three out of ten, where one is difficult and ten is easy. 

On-premises deployment takes some time, I believe. Maybe at least three to five days. The same thing happened with the cloud as well, where it can be completed faster. But, we have to go through the lower environment. We need to obtain the necessary resources from them.

In general, for the deployment process, you just need to download the package and run the upgrade command, which fetches the required data from the Internet. We try to download some data files, binaries, and some dummy tools, depending on the packages. It's a complete package dependency. The installation process checks for packaging and proceeds accordingly.

The pricing can be reduced a bit. It's affordable, but still, it's not considered high these days, especially in the retention area.

I would rate it a seven out of ten, where ten is the highest price.

IBM tooling for monitoring. It was the highest. Cost-wise, I think IBM is costlier, and obviously, it provides more in terms of tooling monitoring. It can also perform log monitoring, which Opsview doesn't do. It requires a separate license for that functionality.

Opsview can be used in any environment. It is operable for trials and all. It has settings suitable for enterprise environments.

Overall, I would rate it an eight. As I mentioned earlier, the graphical representation can be improved. The documentation is there, but maybe it needs a bit more streamlining. There should be a separate team to handle new integrations and support customers. A migration team should be in place beforehand to understand the client's expectations and the existing environment, ensuring a smooth migration process. 

Currently, when we are migrating, we face a lot of issues that should be addressed. We have to evaluate everything one by one and provide proper notice of any potential issues that may arise during the migration. This shouldn't happen, especially since it's a paid service. It should be more proactive.

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.

I have been using Opsview for two years. So, my company uses the product, and we are a customer of the solution. Also, I don't remember the version of the solution I am using.

It is a stable solution.

I wouldn't be able to comment on whether it is scalable because we haven't needed to increase its usage at all. It is a solution used only within the support team, which includes just a few people. Overall, I rate the solution an eight out of ten.

Whenever we have contacted the technical support team, they have been helpful.

Previously, we were using Nagios in our company. We are currently using Opsview and Nagios together. Also, I can't comment on which one we will adopt for our company. At the moment, we're using Opsview and Nagios in different ways.

As per my understanding, the deployment process is very straightforward.

The solution is not cheap. I think that the pricing is a little bit on the high side. I won't be able to comment on the exact pricing of the solution since I am not involved in looking after the prices.

I am satisfied with the overall product since it works well.

My recommendation to those planning to use the solution is to ensure that they have a clear idea of what they want to achieve with it. It is important to define everything early on to ensure that all requirements are included in the request. Other than that, I don't think there are any major concerns.

We use this solution for internal monitoring our own cloud platform because we are a public cloud provider. We also use it for monitoring purposes on behalf of our clients.

Going forward, we will be focusing on using the solution for event triggers and to be able to self-heal the platform.

In a future release, we would like to have Observ for AI. Any AI and intelligence it can add to the monitoring is obviously beneficial. We would also like to have automated callouts. 

I have been using this solution for three years. 

We have had some stability issues, but that is largely because we're using an unsupported database. The product itself is stable.

This is a scalable solution. 

The initial setup is not complex, but it's not very straightforward.

I would advise others to use the supported database because we've tried to fit it into one that's not on their list of recommendations and it works, but it's not as stable.

I would rate this solution a seven out of ten. 

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.

Reload time: Although there have been major gains in the time to process reloads, I think that there is still room for improvement in this area.

The major gains are between versions 5.0 and 5.2.. When ever you make a change or addition to to a host/interface you need to manually reload the system for the changes to be seen. The time it takes for the reload process to complete has decreased from about a minute to just over 30 seconds with just a small number of hosts (83) and then acknowledge the changes. You are reminded that you need to perform this action by a change of color of the Reload Menu item from Blue to Orange however you still have to wait for the system to reload before you can proceed to your next task.

My preference would be for this process to happen in the background so that I could move on to another task but still have the option to acknowledge or roll back the changes if need be.

I have used it for almost a year now.

We had a few hiccup's along the way converting from Nagios XI but with the fantastic and timely support at Opsview, those hiccups were easy to swallow.

We have not encountered any stability issues whatsoever, and I was a little concerned with this at first, since we were seeing dropped packets on our heavy SNMP usage before we migrated; have not had a dropped packet since we switched.

We have not encountered any scalability issues at all. With the ease in deploying slaves, we are about to add a couple of slaves to take on some heavy interface-laden equipment and I am confident that Opsview can handle all of it without issue.

Customer service is 10 out of 10. They have always been able to resolve any issue we were having and very fast to respond to questions/tickets when we had them.

Again, technical support is 10 out of 10.

We previously used Nagios then Nagios XI.

The setup was straightforward and easy; the configuration was a little more complex but that was easily rectified with training.

We did this ourselves with the help of Opsview Support.

Determining ROI is above my pay grade.

Compared to other commercial offerings, it is fairly priced and the licensing is so streamlined, it is easy to budget for.

Before choosing this product, we also evaluated Ipswitch and SolarWinds.

As a busy sysadmin that wears many hats, it is a relief to deal with this product and the Opsview staff. I don't think there is a better commercial offering in this category, at least for our implementation.

There are various features in Opsview that our organization finds valuable. We love the accurate alerting, graphs, and customization of alerts.

It has improved our up time and we are better able to identify issues before users find out.

I would like to see a bit more with the Jasper Reporting, but not a major issue.

I've been using it for three years; however, our organization has been using it for over five years.

No deployment issues.

No stability issues.

No scalability issues.

Customer service is great; always responsive, within minutes at times.

Technical support is great; have yet to have an issue that wasn't resolved within a day.

We previously just used plain old Nagios. Opsview did way more of what we needed.

Initial setup was straightforward.

An in-house team implemented it.

Make sure to consider scaling and what features you actually need.

Before choosing this product, we did not evaluate other options.

Great solution.

• Alerting and notification features
• Unlimited users
• Timed notification profiles

Our support team are more responsive to failures and potential problems by using the Opsview Monitoring System.

MySQL

I have used it for 5+ years.

Sometimes Opsview has crashed, but the multiple master/slave solution provides consistent uptime for monitoring.

No scalability problems – we have 300+ devices.

We have received good support.

I did not previously use a different solution.

Initial setup was midway between straightforward and complex.

• ManageEngine
• Big Brother

Take the time during setup to configure all of the services and options for your devices. The new GUI is much improved.

For me, scalability and reliability are the product's most valuable features.

It allows proactive event management for both infrastructure and business services.

Opsview lacks few features. All of the areas we listed for improvement were implemented in version 5.

Nonetheless, if it were to become more than a super monitoring tool, I would wish for an integrated CMDB and call-logging module to create a standalone integrated IT service management system out of it. It has the potential!

I have used this solution for two years.

We did not encounter any issues with stability in our implementation.

We did not encounter any issues with scalability. It easily scaled up to two datacentres when the need arose.

Technical support was professional and knowledgeable.

We used Nagios Core Open Source, so we had no certifiable support.

Setup was straightforward. Population of checked hosts was automated, thanks to the RESTful Web API. We added multiple hosts and check configurations this way.

I feel that the pricing is fair and well worth it for the value extracted from it.

Before choosing this product, we evaluated Icinga.

Plan carefully and use the wiki!