DX Unified Infrastructure Management Reviews

We install and configure UIM to replace other products like OmniVision, InfoVista, and open source products like Nagios and Cacti with a standardized product, with the new capabilities for the market, like virtualization technology, topology, analysis. It's too difficult for non-technical users, non-software developers, to develop their own monitoring tools.

Scalability and flexibility. The product can grow with your infrastructure so you don't have to install other products. Just add components. It's very simple.

The second major feature is the user-friendly interface. It's the best feature for our customers, because we are the implementers of the software. It's easy for us to install and configure the product, but our customers want a simple interface with only the options they need to run and monitor their environment. 

Recently, important features introduced were the Discovery capability, Auto-Deploy profile manager, and alarms.

Another feature is reporting. We discovered new ways to generate new reports.

This is a very complex question, because it depends on the customer's needs. Some customers need more network capabilities, but UIM is all about IT monitoring. It's an all-inclusive software. 

It's difficult to become the best in monitoring all of the parameters in technology. Some customers want extended capability in the network, or the system overall. But it's difficult to ask the vendor to integrate all of capabilities in one product. We prefer to capitalize on the synergy of products, and not to add features, and features. 

Three or four years in the future, there will be a product with a lot of capabilities, but if one of our customers wants a simple product, not expensive, we can't provide them a product with thousands of capabilities when he will only use ten.

We prefer to follow the market standards, and use a product with a simple and user-friendly interface. That's what we want.

The major problem we have when we sell CA UIM is that we need to sell additional products because it doesn't cover cover all the features. The problem comes down to price. That's the major problem for us. When you have to sell many products, the customer will say, "Oh, it's too expensive," and he won't purchase all the products. So, we think when you have to sell many, many products, they have to do better on pricing.

We would also like to see automatic network topology.

With the new release, the new version, it is more stable. The last releases were less stable than the new one. We think version 8.3 wasn't that stable. But with the 8.5.2, it's alright. It's really stable now.

We make ourselves available on call to our clients and it's now maybe one or two nights per month that there is downtime.

The scalability of the product has not evolved because it has been very good from the start. It's a very important point. CA UIM has a history of a lot of customers with successful ventures, so scalability is important for its customers. 

When a customer starts with a new product, they want to know it has scalability. They won't use all of the capabilities but scalability has to be there.

Even ten years ago, if a large bank or transport or trading company used UIM, they knew the product was scalable, flexible.

Scalability is good.

I had to call them one time at 4am, and I think they saved my life, because they called me back about five minutes after I opened the case. It was a high-impact incident, and they resolved it after about 10 or 15 minutes. So I'm really happy with the technical support. They are nice guys and technically good.

We are partners for CA but we also partner with other providers, like small French providers for the local market, not the worldwide market. we can use UIM for the best monitoring and use features from other products as well. CA lets partners work with other products. We are honest about the futures of the CA products. Most of the time, it is stronger than the other products.

We have implemented it for three or four customers in the last two years, a bank, an insurance company, among other smaller companies only known in France.

For us, the implementation is really easy.

With version 9 of CA UIM arriving soon, we think we will rate it even better, at nine out of 10. With the current version of the product it's a seven. CA UIM has a long history, but as a result, it's difficult for CA to follow market standards. The new version will arrive on the market with beautiful capabilities and very nice interfaces. The new version will enable CA to catch up to market standards. It's a great choice.

Be sure to correctly plan what you need, it's very important. In a lot of cases, the customer asks for a monitoring product with some needs. When we arrive for the workshop, we discover they have other needs. It's important for the customers to not only ask partners to make a proposal, but they should go to the market, got to the forums and community, and see what exists on the market. Ask partners detailed questions. Not, "I need system monitoring," but why. What more do you need? That's important.

Secondly, don't forget that proprietary products like CA have a price. This price is justified by the capabilities. Don't compare open source products with a proprietary product. It's not the same. We look very expensive because they compare us with Aegis or Centurion, but it's not the same product. It's not the same team. It's not the same methodology of work or technical support.

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.

We use CA UIM and CA APM. The most valuable features are trending and analysis. I also like the predictability of the systems, baselines, and that it is can prevent an outage before it happens.

It has allowed us to catch issues before they get to a point where there's an outage.

I would like to see more configuration around best practices and recommendations because the software that is being monitored and APIs are becoming more complex. It's just overwhelming what you can monitor. Having something out of the box that would allow you to at least monitor the most important things would be nice.

I would like to see a pack that just installs the things that need to be monitored. And this may not be where I know enough about it and it may not be configured correctly so I may not be getting everything I can get out of it. That's why I need my vendors to tell me how to get more out of the software that I bought. I know who my people are, and I don't think they understand how to configure it properly. My team doesn't know what to do with it, so I don’t think that is a problem of CA. But it is a business partner issue. I need to find out if it a problem on my side, theirs, or both.   It might not have been turned over, there may not have been best practices. It could be completely on my side where my people just don't do their homework. I have to stop right there because that could be the case.

I haven’t had issues with stability.

Since this solution is new to me, I don't know if it was properly scaled out for our environment to be as efficient and effective as it needs to be. A lot of the solution we have are single points of failure. I don't really have an answer about scalability. I would assume since we only have single points of failure, I guess scalability is something that wasn't taken into account.

I don't know who the vendors were. I know that I probably would have looked at SolarWinds. I don't really know a whole lot of vendors in this area.

In terms of selecting a vendor, it is just like any business. Either companies monitor in-house with a custom built solution and they need a better solution and support ability, or you have a product that wasn't performing and you want to get another one. Since our company was very small over 10 years has grown very fast to be one of the largest corporate travel company in the world, my guess is they didn't have anything and they needed something. Or maybe they did it all in- house previous to the solution, and what they had was probably very immature.

When selecting a vendor, look at the relationship, look for dependability and get references. Make sure the solution works. Look for a vendor who will be a good business partner. Make sure they offer a proof of concept and make sure that you dig everything out of the vendor that you can. Not from a purchase point of view, but from a knowledge perspective and best practices. That's what's missing in IT. It’s just not a lot of people adhering to best practices and things like that. You get workers that just aren't skilled in doing this, so they rely a lot on other people and recommendations. They rely especially on the people that built the software. I would rely on them. That's what I've done my whole career.

• Server reporting
• Server monitoring

These are the most valuable features for us, but I think this is probably the wrong way to talk about it. There's some depth into what we can watch from processes, logs, as well as URLs, and synthetics. So, we have the overall ability to manage everything with UIM.

I don't think that at this stage it's mature enough to have improved the way our organization functions. It's going to get there, but right now there's scalability, performance, and ease-of-use issues that need to be addressed. It will eventually provide us with what we want, but right now we have some challenges with these issues.

One of the things I would like to see an improvement on is the ability to do mass deployment with this solution.

Also, it should allow for federation where I can give our users their login and they can choose whatever thresholds they wish to have.

Even better, I would like to see from synthetic transaction reports the ability for our business units to record their transactions and then provide it back to us. That would save us a lot of time.

We've had no issues with deployment.

The stability is great, but I just find the ease-of-use to be lacking.

There are potential issues with the flexibility for the number of devices that we have because the scalability-performance issue is not fully vetted. CA needs to work on a better API model for us to manage those devices in a larger enterprise.

We have over 20,000 servers, and I don't believe that the ease-of-use to deliver 20,000 should requires a lot of manual processing. Nevertheless, we've wasted a lot of hours doing manual processes to deliver the solution. So, there's an issue with scalability from that perspective.

Technical support has been challenging. I have to go create a new login in MSoft so that I can start opening tickets, instead of going through the traditional CA support. So it causes delays, and I'm hopefully looking for a better response from that team. I can give 9's and 10's throughout the rest of the CA, but there I'd probably give them a 2.

I would suggest that you verify the growth, basically the scalability that you're planning, to utilize its solution. Make sure that's within the grasp of the solution when you're purchasing UIM.

Flexibility – in the sense that it allows me to monitor our IT infrastructure and application in a very holistic manner. It checks everything, there’s a lot of probes -over 150- to handle various monitoring needs. If it's not already there, you can build a probe.

Single solution between Windows, AIX, Solaris, HPUX, and Linux servers, and there are many. The logmon (log monitoring) probe is especially useful, particularly because it offers such flexibility. It also allows for a number of customizations – in terms of both infrastructure and application monitoring.

Very specifically, we want HTML 5 web administration instead of Flash for UMP. HTML 5 web admin is essential for a lightweight web-client administration solution.

Additionally, an HTML 5 web-based alarm console would be a must-have feature as it would allow me to manage it from anywhere.

It still needs a lot of work. An HTML 5 web admin solution is needed badly. Also, the thick client administration tool is archaic, slow, and cumbersome.

It's been around a year since we started as a proof of concept, with implementation in March.

It's pretty stable. Haven't had any problems.

We're monitoring our entire server environment using UIM, so that’s 5000+ servers, and over 300 applications, across the world.

We couldn’t have survived without them. They’ve helped with technical problems. They don’t help with feature requests because they’re tech support; however, they've directed us to the right people. We haven't had a lot of issues though.

We were using IBM Tivoli solutions that did not meet monitoring requirements for numerous reasons, like the lack of scalability and technology.

It’s straightforward. We followed the documentation closely and that helped. Also, we had the help of CA services for implementation. The only issues we had were related to our Oracle database, but it was resolved.

We looked for two things: meeting monitoring requirements and meeting support requirements. We also looked at solutions from BMC and IBM, and although the tools are fairly similar, CA's support and partnership made a difference.

You should nail down your requirements and understand that input from outside teams is important because your monitoring the whole environment. Also, ask CA for help as they’ve done this before.

We mainly use the solution for infrastructure monitoring on our customers' in-house systems. 

This solution allows us to have an overview of the infrastructure and identify areas where the performance isn't optimal, or where upgrades could be carried out.

We would like the navigation of this solution to be more user-friendly for our system administrators.

Also, the solution is quite complicated, so we would like there to be better documentation on the processes, in order to ensure we know exactly how it works.

We have been working with this solution for around 10 years.

We have found this to be a stable solution.

It is an easily scalable product.

The technical support for this solution could be improved. 

Neutral

The initial setup of the solution was straightforward.

We have found that the ROI with this solution, is that the features available allow for us to spot potential issues, before they occur and cause problems for our customers.

We would advise any organization implementing this product, to ensure that there are good training materials available for their users, as it is a complicated solution and requires some specific knowledge prior to use.

I would rate this solution a nine out of ten.

We use it for monitoring our infrastructure. 

I think it's a great product. It really brings it into the 21st century of Web UI. This latest version, version 9, that is supposed to be announced here at CA World, brings more of that HTML5 interface in and really steps it up to be a great UI. Easy to use, quick.

It's the probes. They have probes for all different types of technology. Whether it's WebSphere, JBoss, or you want to do JVM monitoring, you want to monitor just CPU usage, even Docker, they have probes for that. If you have a technology out there, there's a probe. And if there's not a probe somebody's creating a probe already. The probe library it pretty extensive.

The improvement is because we can deploy agents (they call them "robots," most people know them as "agents"). As most people know, agents are bloated, they can do whatever you want. With UIM, you put that robot out there and you place the probes you need, only the probes you need. So you have a base agent and here, for example, I only want to monitor server CPU, memory, storage, and maybe I want to monitor JBoss on this box. I just put the CDM probe out there, I put the JBoss probe out, and that's all you need. You don't need the load and probes for Docker or something else that you don't need to use.

More HTML5, more flexibility, and reducing the number of screens, fewer mouse clicks, fewer mouse movements. They should really take advantage of the features that the newer web technologies allow for. We're administrators, we're doing thousands of things every day, lots of clicks. Automation, automation, automation is what we want.

It's been a great product compared to some previous monitoring tools we had in place. Every time there were software updates for the server for security, from Microsoft or any other vendors, that would require reboots. A lot of the times we would have crashes or we'd have to do some recovery to bring them back up. With UIM, we've been running it for about nine or 10 months now and I think I've had to go and reboot the servers once.

Scalability seems great because they use hubs, so if your hub is hitting capacity on a number of servers, devices it's talking to, you can just add another hub. And it's a message-based system.

They've been great. Actually the guys that are doing the UIM product really know their stuff.

We have SolarWinds and we had some older Spectrum products that CA had, as well. But, the user interface was not as modernized as UIM.

The product we had was just nearing it's end of lifecycle for us, and we needed to move on to something else that the users would be more comfortable with using.

I think it was pretty straightforward. We did have, just as a disclaimer, a CA person on site helping, one of their sales engineers, just in case anything came up. The process went smoothly. Honestly, we probably didn't even need him there.

Our criteria when looking to switch to a different product include the user's ability, their willingness, to use it. And another main consideration, you can get data in but can you get data out in the formats you need? If you can only get data in, but you can't get data out, it's of no use.

I give it an eight out of 10 because, as I said, I think it needs a little bit more improvement around the UX, but it's getting there. And they're making a concerted effort to make that happen.

I would tell a colleague who is researching this type of solution to really look at your feature functionality. What do you need? Does it meed 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.