Opsview Reviews

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!

The most valuable component of Opsview might be the very good web GUI. It provides a great overview of all hosts and services; furthermore, adding new monitoring targets and modifying existing configuration is possible. The web interface is powered by at least one database which makes it easy to backup. In addition one might take note of the API which at least allows automated configuration.

My company never used Opsview for themselves, but we provided it for many customers. Before using Opsview, they complained about chaotic web interfaces and nonsense monitoring messages in their old solutions. Afterwards, they were impressed by how easy monitoring could be, and they no longer had to edit large text files in order to configure hosts and service checks. Instead, they simply started using the Opsview web GUI which is also very self-explanatory. So no long introduction was needed.

The API provided by Opsview is, compared to other monitoring solutions, not state of the art. It would be great to see that more efforts would be put into this part of the product. Furthermore I would love to see support for more database systems which are needed for storing configuration stuff and data.

I was using it between mid 2012 and the beginning of 2014. The foundation and the architecture haven't changed much since then. I worked with Opsview before the pro version had more features than the free community edition (e.g. Opsview Core 4). It was always running with Ubuntu 12.04.

Since Opsview heavily relies on MySQL and InnoDB, backups or large installations can be slow. You will need to put a lot of time into tning your database in order to keep it performing well.

It was easy since Opsview provided a working Ubuntu package, and a good how-to.

We automated the deployment, and did it ourselves, so no consulting was Needed. When implementing Opsview, one has to make sure that the VM OR hardware beneath IT, is powerful enough, and that MySQL is configured the correct way.

Large Opsview setups come with high licensing fees. I find them to be too expensive, but that is only my opinion. There are not many different licensing models, so if you go for an Opsview installation, make sure to talk to your Opsview partner or the vendor and make sure that you get the best prices possible. Only use the core edition for trial setups, not for production.

Well, if you are ready to spend a lot of money and time in getting a large system view installation up and running (in a performance way), Opsview is THE solution which covers most requirements you can possibly have. But if you want to rely on open source software, which has no license fees or feature limits, I can recommend CheckMK, Shinken and Icinga2. I used CheckMK and Icinga 2 for monitoring projects since the end of 2014 because I prefer limit-free open source software over commercial software.

It is a great product, and if you accept that you have to use MySQL as the database system you will definitely like it. If your installation will cover more than 100 hosts, you should run Opsview on bare-metal.

I like its scalability thanks to slaves. You can add as many slave as you want, which also allows you to reach and monitor devices running on the network that are not accessible by the master. It also has good roles management which is very useful for a service provided to customers. Lastly, it also has a nice GUI.

Before we used Nagios. It's based on Nagios too, but the biggest benefit when compared to it is the simplicity to set up and modify devices.

SNMP traps management to be improved. It's not so easy to use and you have to pay more to get the SMS module.

I've been using it for 30 months.

We have had no issues with the deployment.

There have been no performance issues.

It's been able to scale for our needs.

We used Nagios previously, and it was reliable but hard to configure, and even harder to create a master/slave configuration.

Considering the complexity of our network, it wasn't hard to install. It would be preferable if you have some Linux knowledge prior to the implementation.

We implemented it in-house via our Data Center Team.

As a CSP, we have an MSP agreement so that we can pay for its use. It means that additional customers will pay additional fees, and this is invaluable.

Get a good book so you can get exposed to all the great functionality in PostgreSQL. I would highly recommend looking at the postgresql.conf configuration settings when you are ready to go into production. In order to get a good price, I think that you need to have a commercial process in place.

• Easy setup hosts
• Easy configuring service checks
• Very easy-to-use interface, especially starting from v5 onwards
• Advanced tweaking possibilities
• Netflow

It's helping to actively monitor our systems.

• Easier expansions
• Better documentations
• Having tabs inside, 2F authentication
• Incorrect documentation for version 5.0
• Lack of tabs in Opsview GUI
• Unnecessary configuration and manual setup for slave appliances which can be configured by Opsview inside the VM

I've been using it for seven months.

We haven't had issues with our deployments.

Often the webpage becomes inaccessible and you need to refresh the page.

With the way the service checks work, you need to perform lots of manual setups to create specific service checks and templates for each host.

6/10

I used Icinga in my previous company.

The initial setup is straightforward if the documentation is correct.

Get the silver package for enterprise.

No other options were looked at.

Devise the exact templates you want to create before messing it up.

The dashboard, which gives us real-time monitoring, is the most valuable feature for us.

We are now providing visual representations for our big data solutions. This "ticks the boxes" for our customers who have been asking for Operational Dashboards for years. Because they are so easy to set up, we are able to set them up pretty quickly.

It's probably the priciest option of all its main competitors.

I've used it for two years.

We've haven't had any issues with deployment.

We have had no issues with the stability.

There have been no issues scaling it.

The onsite support we had during the initial implementation was excellent. Their knowledge was excellent and everyone took time to explain the technology as they were working on the solution. I just wish I could have had more time with them.

We are using it alongside Opsview, which we use to monitor our virtual infrastructure.

As with all new products we have had a few teething issues. As we have expanded and gained experience with the product our lessons learned have made things easier.

It is a little more expensive than some of the other options we looked at, but the dashboard features are much better than any other product we looked at, especially when we moved to v5.

We also evaluated Nagios XI and Nagios Core.

Plan your deployment options carefully. The dashboards are the real value add for this product in my opinion and enhance customer experience if done properly. Which in turn builds relationships. Most customers are not too worried that you have a 100 events in the system. They need to know and understand that their service is running and available. Look at automation opportunities to speed up deployment processes -- Puppet, Chef, etc.

The two most valuable features for us are the GUI front end and the centralization of confirmation information in a MySQL backend.

We moved from the NetSaint and Nagios platforms. Opsview provides all the functionality of these but with the simplicity of a GUI front end, using MySQL to centralize configuration. This has moved us away from the multi-configuration file complexity of NetSaint and Nagios.

Some aspects of the GUI functionality need improvement. We've discussed them with Opsview and they plan on making improvements per customer request.

We have been using Opsview Enterprise for approximately four months. Prior to that we were running an earlier version called Opsview Core since 2012.

We've had no issues with deployment.

There were no issues with the stability.

We have had no issues with scaling it for our needs.

10/10

Prior to 2012, we were using Nagios and NetSaint. We moved to Opsview as it gave us GUI flexibility and also allowed us to migrate our Nagios and NetSaint alarms and plugins easily.

The setup of our original CORE version required some thought. However, the use of MySQL as the backend facilitated a very easy upgrade to our current Enterprise version. There was no requirement to reconfigure hosts, services, groups, etc.

It has competitive pricing compared to similar products on the market.

Avail yourself of the limited license core version first. Try it out to ensure that it provides all the functionality you require. It’s free to download and install and gives a good flavor of the product's capability.

The most valuable feature we've found is really just how easy it is to add servers and devices to the monitor. We also like the UI and applications. What we've also found that we like the iOS app which lets us acknowledge issues or see warnings from our mobile phones away from the office.

Our functioning has definitely improved because we previously did not have any monitoring for our servers. We didn't even know when our hard drives were filling up, and the situation has now improved dramatically. With the monitoring capabilities, I can tell when things happen and be proactive about them instead of constantly putting out fires. This is a huge improvement.

There's also a management module that we haven't fully utilized, but it's something that we're looking forward to using.

I wish they'd update the iOS app, which, I think, is the same version I used back in 2012 or so. It's always looked pretty much the same. As for the web version, things like the acknowledgements are better, but I'd rather use the iOS app because it's easier and quicker to acknowledge and schedule downtime.

Also, I took their training for the reporting module, and it's quite complicated. I'd like more functionality than just drag-and-drop to build a report, which we had to do with SQL queries. This is an area of that needs improvement because it requires that we have time for development time in order to do SQL queries.

I think, though, that pretty much everything else is great with the new version 5. We're able to add hosts and do other things so much easier than with the previous version. There's a massive improvement and I'm pretty happy with it.

We've been using since December 2015.

We've had no issues with deployment.

There have been no stability issues since we began running it in December. The only time it's been down was when we were patching the server that it runs on. All the services run, even with out new service watchdog. It monitors itself and I haven't gotten any notes about it going on.

Our department's quite small, but from what I can tell, it's definitely scalable both up and out. We have around 200 servers, but the monitoring service uses only one server that's not clustered, although I'm sure clustering wouldn't be difficult with Opsview.

Technical support is super knowledgable. During our trial period, I ran into some issues and they were very responsive. I never had any issues trying to get them to answer any questions. They didn't make me feel like an idiot.

I used Opsview in my previous job and that's the reason why I went with them here in my current role.

It's straightforward, perhaps because I used it before, but this version is super easy to install. I followed the instructions on the website and the installation was pretty much automated.

Be sure to use the 30-day trial and see if it meets your needs. It fit my needs, my vision, and the price was right.

The system is very robust and very rarely breaks. It just sits there working, doing what's expected. Very little maintenance is needed and the support is very good. I would say stability is the most valuable feature. I'm struggling to think of a time when it actually crashed or when we had a problem.

We use it mainly for networking post-monitoring and service monitoring. We have sites across France, Spain, and the UK with many different production devices on it. We mainly just do service checks to make sure the operation of the company advances if we use a service or house at a particular site.

I think it still has room for improvement to auto discovery. If you put the agent on a house, it has auto discovery. I also think it can be improved with VMware as well. It can be a little bit flaky with the agent on VMware.

It performs all the diversifications, but if you've got a VMware environment, there are some anomalies within the service checks. I don't know if that's because of plugins unfamiliar to VMware or if there's an actual issue with Opsview. Regardless, it's not as strong with VMware as it is with other devices.

We've had it now for seven or eight years.

Other than within the VMware environment, we haven't had any issues with deployment.

It has just sat working forever throughout the last seven years without any problems.

We've had issues with scalability as we ran out of house. We only had a contract for a certain number and ran out. We upscaled to 650 devices, which was a simple yet expensive process.

Both the customer service and technical support are excellent. We've purchased 20 calls per year of support, and I would say we probably use about 3.

We were using a previous solution called NightWatch. It had nowhere near the features of Opsview.

We used the Opsview teams to install the product.

It's not something that I tend to get involved with, obviously, but I believe the proactive monitoring would be significantly cheaper. Obviously, we've got a good rapport with Opsview so we were reluctant to change.

We were toying within the idea of proactive monitoring as well, but because we've been an Opsview shop for quite a number of years, it was just easier at the time just to renew the contract.

I think everything could have a little bit of improvement with monitoring and reporting. It needs improvements with VMware as well as in a few other avenues. On the whole, though, it's exactly what we're looking for.

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.