- Cloud monitoring
- Easily skinnable
- SAP monitoring
- Reporting Tools
- Probe packages and probe deployment
Through action automation (using NAS and robot actions) we got reduced operational effort, improved operative tasks, and optimization of resources.
I would like to see improvements in the maintenance mode area. I would like to set only a probe from a robot or group in maintenance or place profiles from probes in maintenance. Making a GUI with criteria such as selection by robot/hub/probe etc.
I've been using it for five years.
No deployment issues encountered.
No stability issues encountered.
No scalability issues encountered.
We didn't use customer service.
Technical Support:10/10 CA Support team is excellent we get from them issue resolution within a single interaction and anchoring alternative solution.
Previously we had multiples tools to monitor IT infrastructure and other apps e.g ManageEngine to monitor databases, Nagios to monitor telco devices (switches, and routers, etc.) We switched to CA UIM because we had a lot of issues when we tried to correlate events and get unified metrics from our monitoring tools databases, in the same way we had maintain multiple tools and open tickets with multiples vendors.
Initial setup was straightforward. Installing and deploying software was very quick and easy. We have experience with similar tools implementation.
We did the full implementation in house.
Licensing model and packaging:
Server pack - Charged per server.
Server and application pack - Charged per server.
Service response time advanced pack - charged per site.
Ping pack - Charged per device.
Network advanced pack - Charged per device.
Flow analysis - Charged per device.
Storage pack - Charged per terabyte.
Ecometer pack - Charged per device.
We also looked at OpsView and SCOM.
Monitor governance and solution sizing are key topics to start solution implementation.
Basically, the most valuable feature for us is that the dashboard if easy to use as it aggregates all data.
It's really been beneficial to the applications teams in their ability to see CPUs and disc memory. It monitors memory on the servers associated with our applications.
One of the things I would like to see an improvement on is the ability to do mass deployment. Also, I'd like a federated identity feature, where I can give our users a login and they can choose whatever thresholds they wish to have.
Even better, I would like to see a synthetic transaction report from the reporting feature that our business unites can use to record their transactions and provide it back to us. That would save us a lot of time.
Finally, I'd like some self-service functionality out-of-the-box, so that you can assign probes, or deploy with thresholds, or whatever you want to do. You just put it in a server and let it self-service.
There's been no issues with deployment on my end.
It's been very stable for me as an end-user. We haven't had any problems yet.
No scalability issues so far. That's been fine.
I don't use tech support for anything. I rely on our in-house team for that.
I wasn't involved in the setup.
If I had to choose all over again, I'd probably look more into the mobile function of it.
Monitoring infrastructure and business applications are the most valuable features.
By getting an early warning about problems, services can have high availability and perform well. In addition, we can respond automatically to failures so services can be recovered immediately.
It would be good to implement views showing the aggregated status graphically. For example, they could use colors reflecting the status, and the possibility to drill down to detailed information. The views should be configurable so the administrator can organize them the way he wants. Dynamic views should be supported. That means the members of the views changes based on conditions defined by the administrator.
I have been using this solution for over five years.
We have not had stability issues.
We have not had scalability issues.
Technical support is good.
We were using HPE Operations Manager and SCOM. We switched because it's less resource demanding and has more functionality out of the box. Especially when it comes to support for different monitoring techniques, so that fewer custom-made solutions (scripting, etc.) are required. There are probes available for most kinds of monitoring metrics, applications, and operating systems.
Setup was very straightforward. It's possible to have a fully functional monitoring system up and running within one day by use of the easy-to-use setup procedures and the automatic robot deployment functionality.
The license cost depends on the number of probes and robots. I advise customers to be selective with which probes to deploy on the different servers.
We looked at SCOM and HPE Operations Manager (OpenView).
Be aware of your exact needs so you can ensure the product will meet your needs.
The main feature for us is its flexibility with their message bus and their API to make it do what you need it to do, since everyone's different. There is flexibility in the SDKs to customize it.
It really depends on where you're coming from. In 2009, we were working with Nagios -- before it was UIM and called Nimbus -- and weren't particularly unhappy, but there was an executive decision to go in a different direction. We were out-of-date and weren't taking advantage of some of the new features to see whether they would make a different for us. There were new capabilities, such as analytics and machine baselines versus static thresholds.
That said, it does provide us with a reduction in signal noise levels. It gives an alarm when there's something going on, not just when there's an expected spike that happens every night on a server.
Although this may not work based on our environment, but topology discovery and root cause analysis would be nice to have. Right now, we don't have the RCA and rootcon topology awareness. It may be in the new version, but based on our architecture, it may not work. It would be a big win, however, if we had it.
Another useful feature to have would be automatic configuration per standard by new robots that check in for any particular customer. This could help us decrease the configuration time.
We've had the same version since the install in 2009. We're looking to upgrade, and we do have the latest version in our lab, but I'm anxious to have it available in prime time.
We've had no issues with deployment.
We've had some issues that may to do with versioning, though not completely. In our backend, the database structure and message bus are on the really old version, though the hub is the newest version. There's a point when new features on the hub may no longer be possible. This may be where our version is hurting us.
Sometimes our hubs get choked up and support has never been able to isolate the cause.
We do have times where the hubs get choked up and we've never been able to isolate why with support. Is it something in our environment or is it something they see from other customers? Is it hubs that are too busy? Is it our REX infrastructure? We've never been able to isolate the cause. I've had several support cases over the years about a scenario where the hub gets into a partially functioning state and so all the robots have realized it's not working normally and have moved over to their backup hub. That hub itself still expects to hear from all those robots and so we'll get a flood of hundreds of alarms saying, "Robot inactive. These robots are not checking into me." It's really that they're just checking into the other hub.
That's the issue -- there's no intelligence at that layer. And because of that, one of our most common alarm floods is from the hub itself.
I had an escalation one time to double check that the hub failed-over okay and was back online because they got a hundred tickets opened all at the same time. That's the main point that we've had in terms of instability, is on the hub. We have hubs at other sites that don't have as many robots or aren't doing as many ping checks and they have much fewer issues. It could be that some of these hubs are just too busy and they're more likely to get choked up.
There's also the issue of portal performance. We have UMP released and it's not awful for our customers. If a customer logs in, from a security stand point, they're only seeing their data. If they have 10 servers that we manage for them, the performance isn't awful in that scenario. As an internal employee, when we log in and we have the permission to see all of our data from thousands of devices, the performance is a lot slower and a lot more painful and that's something that we're several versions behind on the portal.
We've had no issues with scalability.
We've had some concerns, especially since CA's acquisition and re-branding of Nimsoft. For a while, there was a dedicated support center just for the monitoring product. But now, there's a more standardized support structure where Tier 1 is not as specialized. I haven't, however, had a lot of cases to claim that it's worse than before, but we have had tickets that have dragged on for a long time.
There was an instance where they fixed a bug after 6-8 months, but it was the wrong bug. There are a couple of threads on their forum about comical support interactions where they get told, "Oh, that's an enhancement. Go type it and we'll vote on whether to fix it. Go type it out on the forum." I don't think that's always the experience in every case, but we have had some challenges like that, where it's like, "How are you calling this an enhancement? This is just basic core functionality that's not working" and getting agreement on that. At times that's been a challenge.
When we first implemented Nimbus in 2009, it wasn't fully vetted by the technical staff because management pushed it on them. For what we pay, I know many executives don't think we're getting enough ROI. We doing basic monitoring -- CPU memory, disk space, SQL responses, URL's, pings, and custom probes we've written using their SDK. Writing our own probes is one of the perks with something like Nagios.
The licensing cost is several hundred thousand dollars a year, and we're only getting several hundred dollars' worth of value since we're doing basic stuff. That's the challenge.
And we're hamstrung because we're still using the older version, and we're not getting great ROI. There's a lack of clarity on where we want to go, but we could do a whole lot more than we're doing.
There are things that are nice in just covering the basics for us, but then we have pain points on some of the more advanced stuff.
These features are very valuable as they allow productivity to be supported by blocking and monitoring websites accessed by collaborators, as well as controlling the levels of access to the various services we have in our operation, in addition to functionalities such as Load Balancing and Multiple WAN connections to help us in business continuity.
I think it has helped in different ways:
We have used this solution for four years.
I did not find problems with stability. I think the advice we got at the beginning helped us to get the correct dimensioning of the equipment and the functionalities of the product. Once it came into operation, the product always performed the expected functionality.
We have not encountered any scalability issues.
I would rate the technical support as 9/10, since the support provider always showed knowledge and was able to solve the problems. The only negative point is the availability as they are usually late in responding.
We did not previously use a different solution.
The installation process was simple, especially because the installer was guided by an expert and her way of communicating was always clear and concise. From the first day, the solution came into operation and the tuning process was given progressively.
I think the price of licensing is very accessible, considering the functionalities of the product. The product-price ratio is better than other brands such as Fortinet or SonicWall.
We performed an evaluation on Fortinet, SonicWall, Juniper and Microtik.
The advice I can give you is to first make an assessment of the needs that your company has. Once they have identified the products that offer solutions to their problems, then don't only consider the price but consider also the costs of licensing, support agreements, product functionalities, product positioning etc.
Consider reviewing evaluations made by other technology vendors and if possible ask for a demo to your local IT providers. They will be happy to show you the products and their different advantages.
We are transitioning to a proactive monitoring. By using thresholds and predictive analysis, we are reducing incidents.
Network monitoring beyond SNMP.
I have used this solution for ten months.
We have not had stability issues yet.
We have not had scalability issues yet.
There has been good technical support so far.
We used an open source solution for some time, but decided to get a fully supported solution to improve service availability.
The initial setup was simple. We just had some issues with the initial database setup.
It is not the cheapest solution, but it has competitive prices.
We evaluated SolarWinds.
Check or ask for a compatibility matrix to ensure that your environment (server OS, virtual environments, etc.) is supported.
This product is very flexible for the administrator. We can do whatever we want. It is easily customizable and upgradable.
We are using this product for all my customers and internal stakeholders. We did the following:
We have been using the solution for six years.
We had some issues with stability.
We encountered scalability issues in some areas such as bandwidth monitoring.
The technical support is very good from Europe and Australia, compared to the Indian support office.
The setup is very straightforward and flexible.
The pricing and licensing is acceptable. This is a very good product for small and medium size organizations.
We evaluated BMC and ManageEngine IT360.
Go ahead and choose this product.
The features valuable for me are scalability, redundancy, and the wide range of probes available for just about any platform.
Another major advantage is the easy configuration management. When you define standard “base” monitoring templates and on top of those, define “differential” templates, having a tool that allows you to manage these hundreds (and even thousands) of templates in an organized manner is an absolute necessity.
CA UIM not only allows you to manage the templates, but the new MCS module allows you to dynamically assign them to groups. This means that any node/probe belonging to that group will automatically receive the templates.
Note: At this time, MCS does not yet support differential templates, but it is on the roadmap.
When this customer did the PoC, the competition clearly failed in this area. Furthermore, the event management part (alarm server and alert console) is feature-rich. It allows for some advanced, alert processing and correlation.
Nodes are now monitored in a standardized way, thanks to configuration management. We are a lot more pro-active to solve potential issues, thanks to event management.
Different teams are using different dashboards according to their requirements. For example, the end-user service desk uses a high-level dashboard with the state of the most important applications, printer malfunctions, etc.
A lot of the functionality is available out-of-the-box without having to script it, although scripting it is still needed from time to time. This means new objects/metrics are effectively getting monitored quickly without a lengthy development period.
I would like to see the retirement of the heavy client (infrastructure manager) in favor of the web-based admin console. It is close, but it is not there yet.
Support for the PostgreSQL database platform would be nice. At this time, you can only choose between Oracle and MySQL when running CA UIM on Linux.
As a DBA, I prefer PostgreSQL over MySQL. (This is my personal preference. By no means do I find MySQL a bad product.)
For this customer, it’s their first implementation. However, I have been using CA UIM since 2014 and its predecessor, Unicenter NSM, since 2004.
We had no stability issues. The built-in redundancy allows for maintenance windows for patching.
Scalability is one of its strong points. A manager server (hub) can manage a lot of nodes. Adding another hub is really straightforward. You just need to make sure you have plenty of storage for both the database and the primary hub.
The technical support is very good. You still need access to the old support.nimsoft.com site for downloading new versions of probes. Overall, it is very good.
CA support did have a bad reputation 10-15 years ago, but they made a lot of effort to improve it.
The customer was using Nagios, and still is for the network part.
The main issues were:
The actual installation was very quick and straightforward. Of course, you can spend ages configuring/tweaking as the product has endless options. It all depends what you have defined and how complex your environment is.
Most of the time was spent defining the architecture: What probes go where, redundancy, tunnels for the DMZ networks, and capacity planning. I recommend spending as much time as required on this, as you will benefit from it later.
It is definitely not the cheapest on the market, but you can save a lot of money by carefully making a list of which probes you actually need and how many of them are required.
Often probes can monitor multiple instances or are included in other packs, so you don’t have to purchase them separately. Make sure to be precise. Your CA representative can assist you with that.
The customer did a PoC with two contenders: CA UIM and Microsoft SCOM.
Try to look beyond the price tag. You really do get a lot in return, especially when you have a highly heterogeneous environment.