DX Unified Infrastructure Management Reviews

The valuable features are that it monitors our infrastructure, our servers, network devices, and applications proactively. It helps us to prevent problems and UIM tells us how to do that.

We use it for capacity planning and capacity management.

A would like to see a little deeper application monitoring and maybe some of the capabilities of CA Spectrum.

CA UIM is very stable. We don't have a lot of problems with it.

The scalability is very easy. We just went global and we scaled up to another about 2000 devices.

Once you get to the right person, you get your problem fixed pretty quickly. Now that we have had CA UIM for a little over 4 years, we have worked through those issues so we know exactly who to go to, who to contact to work on our cases, so it's not that big of deal anymore.

We had and older version Microsoft SCOM and it did not monitor Linux servers at that time. We needed a solution that could handle that. We had solo wins for network and we needed a solution that was scalable and a solution that we could migrate to our global infrastructure. In a previous company, I worked with CA products before, (Spectrum, eHealth, and Live Health), so I trusted CA and knew CA was a good product so I came back to them again.

My team was involved with the initial setup. The setup was was probably in the middle between straightforward and complex. We did have some initial problems such as getting our network to be monitored. We had some SNP collector problems. We got them all worked out. CA was very good and they did multiple hours over there over the Statement of Work (SoW) because we had problems. They stuck with us and got us going.

We did a POC with approximately 6 vendors. Microsoft SCOM was one of them. We were looking at cost, reliability, scalability, and the ability to monitor all our infrastructure and provide dashboard reporting at a high service level. All of that was very important to us. CA passed. We went out to Gartner consultants, and at that time four years ago, they selected CA UIM as the number one product for the price. To choose a vendor, make sure you know what requirements you want. CA UIM can do a lot of things. You really need to know what you want from CA UIM, or there is a potential of failing. I think one additional criteria is your statement of work needs to be very precise.

It has a wide breadth of monitors and probes. It enables us to monitor just about anything we come across. That's its strength: it's got a wide variety.

It's allowed us to narrow our footprint. We're getting ready now to retire some legacy apps that we use for monitoring, so it's allowed us to narrow our footprint.

• They need to work on the user interface. I know they are, but to me, that's one of the big things that is holding them back. It's not with the times. It's not real intuitive. You really need to work with it to figure out where things are.
• We need to be able to group servers and deploy different packages to them.
• You should be able to better organize the grouping and deployment. That's kind of where they struggle. They need to work on that area. I know they are, but that's our pain point. The organization is lacking.

I think it needs a little work in terms of stability. We've had issues with some probes crashing. It seems like there are really more bugs in a release when it comes out than there should be. I would think they should be caught in QA. That's what I've seen so far.

It seems to be very scalable. We have 6,000 servers, and we really haven't run into any scalability issues. We have thousands and thousands of monitors. But the number of alarms for event handling can be a little better. I know they're working on that. They may have another solution coming out that will help us with that.

Technical support has been fair, medium, or whatever the middle of the road is. I wish they were a little more responsive on some items, and be a little more knowledgeable on some items. It seems like we need to go through several layers before we get to someone who really can help us with our problem.

We're not just opening a, "Hey, how do you do this?" It's more like, "Okay. This is broken. How do we go about fixing it?" It seems like it takes multiple conversations to get what we need out of that, to get a fix.

We had many solutions and this one came down from management. "You're going to narrow your footprint," and the powers that be picked it for us. We had to go with that. It was already in. Other products were already in house, so this kind of lent itself to, "Well, here's another solution from CA, so deploy that."

The initial setup was straightforward for the complex tool that it is. There is complexity in terms of the more you deploy it, the bigger you get; and when you start to add layers, it can be complex. Overall, though, it was fairly straightforward.

I would do a proof of concept and go through all the use cases to make sure it's going to fit your needs. You should also work with the user interface first. Ask yourself whether it is going to be too cumbersome for you, given the type of environment that you have.

Knowing now what I didn't know then, having really good and responsive technical support is very important. It is not something you really think about when you are looking for a better tool, but you have to live with the decision for years. It's hard to evaluate, I know, when you're first deploying or first looking at new tools, but being able to evaluate that would be good. The scalability and the ability to cover the range of our different requirements is also important.

The decrease in time to resolution on problems, also a reduction on finger pointing of teams, "It's the network, or it's the application." Things like that, the ability to pinpoint those problems very, very quickly.

We use it to monitor all of our infrastructure, so servers, telecom devices, all our applications, to try and get a true End 2 End experience, and understand the user's experience.

We primarily chose CA UIM because we had a bunch of disparate systems. We had some network monitoring, we had infrastructure monitoring, it was siloed off into our different environments. We needed to pull it into a single tool, and we needed the flexibility to gain some more insight into the end user experience through synthetic transactions.

The ability to be able to pull data out of multiple data sources and surface it all into a single tool. Some of the other tools that we had were very limited, with UIM you can scrape virtually any data source. The synthetic transactions were a big deal because we really are having this shift to trying to understand the users' experience from their point of view, being able to dashboard and visualize the products and the information on the alarms that we have. Our previous tools didn't give us much of that capability.

Continuing to mature the SNP collector and the network side of the tools they're still not as strong as they need to be. If you're moving from a different product like Spectrum, or something like that, it's a little bit stronger in the networking area, continuing the development of that area.

It was to unify things and bring more visibility into the monitoring space. We've really tried to move from being reactive to proactive. With the tools that we had, we had lots of alarms, and lots of things that we could react on, bet we didn't have the ability to start getting proactive, so we needed to be able to do that as well.

Stability is very good, we've not really had any major issues at all with it, honestly. In developing a product and moving very quickly with the development, so you're going to have bumps on the road. There are some issues but they're quick to respond to those, they're quick to work through them, so it's okay.

We actually have a close relationship with the tech support team, as well as the development team as well, working through issues and problems as they arise. We have a pretty large infrastructure that we monitor, and we get some of the scalability issues or some other issues that they may not have seen and they're very quick to respond. Tech support has been really great.

I don't remember the numbers off the top of my head, but we've reduced our outages by about 15%. We've reduced time to resolution by about 40%. Lower overhead as far as man hours.

When we initially went through and purchased the product, we started out with a proof of concept and we went in to the proof of concept with the end state of actually turning it into production. We had pre-sales come in and help us work through the problems, getting it all set up and it was very quick to bring online and have collection of data and show value, many times on certain products and certain pieces of products within hours. You've got good data collection, so it was pretty straight forward to set up and configure. We didn't have any issues at all.

It's been a couple of years since we bought them, and I don't remember off the top of my head. We had some other ones we looked through, and the tool just really fit the needs.

The fact that they're still doing a lot of development in the networking space, they're still trying to mature that side of the product to get where it needs to be. That's really the reason, beyond that it's a great product. We really like using the tools, we like all of the things that we've gotten out of the tool set, the ability to visualize, the ability to help our troubleshooting, the in depth analysis for our infrastructure teams and things like that. It's been really great.

Do your research and really compare them side by side, but give CA a chance to put their product against any because it's really one of the best in.

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.

The most valuable features we're taking advantage of today is computer memory disc monitoring and the alerting on it. We're able to predict how close we're approaching our thresholds so we can head off a disaster and we can troubleshoot it before it becomes a big problem.

We have the solution across all the production servers in our operation. We have seen, over the last 4 or 5 years, about a 30% decrease in escalations in crisis management, less severity events because we are trending and tracking against thresholds so we get early warning alerts. Our goal is trigger solutions in escalation resolution before it becomes a critical event.

We monitor SQL databases, we have a lot of servers; Windows servers, we have Linux boxes and we have network equipment.

One of the things we'd like to see is a more streamline and baseline reporting mechanism. We use several CA products and we'd like to see all of the products dump information into a common format so that we can harvest it into multiple dashboards. Right now if you use multiple applications, you need 3 different experts on 3 different reporting structures. We'd like to see them come with a unified database and ability to harvest that data.

We haven't had any issues with downtime with the solution at all. We do have, at times, the robots which are probes that log onto server. Sometimes they'll hang or fall offline and we generally have an auto-restart if that happens. Most the time we find out we caused it ourselves because somebody was performing maintenance.

We've been able to scale it across 20 platforms in 3 different data centers. It doesn't mean it's simple, but once you've got your thresholds down and your methodology, your strategy of what you want to monitor, it works pretty well.

We've used technical support before, especially when we first loaded, our server installed our design. Very responsive, stuck with us on the phone till we resolved our issues and at some points they had to come back a few days later with a solution or a patch to fix us.

We were having system outages, or server outages, or connectivity outages with the network and we weren't able to see it. The tools we had in place weren't robust enough and weren't flexible enough for us to design thresholds and different levels of monitoring. We started researching tools and we decided on UIM.

I think the initial setup was pretty straightforward. It was a little more complex than we thought but it wasn't insurmountable. The biggest challenge we had was that we didn't understand how our applications ran or how our hardware was responding to our applications so we set the thresholds pretty low, generated a lot of alerts, and then had to adjust. That was probably the biggest challenge we had going into the project

We chose CA primarily because of the size of the company and past relationships at other companies I have worked for. Also, we looked at vendors for many different products but we chose CA because of the the flexibility of the product and the supportability of the product.

When selecting a vendor we are first and foremost looking for a partner. We're not interested in a vendor/client relationship. We're not interested in just being a dollar sign at the end of the quarter. We want somebody who will work to understand our business and understand what's unique about us. I'm sure that's a common thread with many customers but it's really important for us to have a partner relationship. The second thing is we want serviceability. We want to be able to call tech support, or talk to a systems engineer, and have them engage with us and work with us through a problem, not just throw us canned solutions and assume we're going to apply those and walk away.

I'd rate it a 9/10. First of all, I don't know that I ever reach a 10 with any vendor, but a 9 because the solution works as advertised, the service is there. The responsiveness of the tech support is very, very pleasing. They come back to you when they schedule, they follow up on their commitments. We've had some challenges expanding our footprint in other data centers. Like I said earlier, it's not perfectly easy, it is complex but once you get it dialed in we're up and running and everything's smooth. Their service teams have been there with us all the way, so that's really important for us.

When it comes to advice to others, I think you should focus on having an understanding of what you want to measure and monitor in your environment. It's more than just saying, "Yeah, we're going to monitor all the servers." What thresholds? What do you expect your CPU utilization to be? What do you expect your memory utilization to be? What's important for you from a customer service responsiveness? Do you have a systems engineer who's willing to put the time in to understand your business before providing you a solution? Those things are really key for us.

The most valuable feature are the data gathering capabilities, metrics, and being able to publish those.

Out of the box, you’ve got reports ready to go which are all useful, especially for an infrastructure group. Server reports cover the basics – CPU, memory, disks – but you can drag and drop servers or whatever you want, ad hoc, and you can get quick and dirty.

We’re getting down to one tool to monitor all of our servers. Right now we’ve got two or three, so we’re trying to reduce the footprint – that allows us to have one skill set rather than multiple. It’s easier to support the business with one toolset.

The UI to me is huge. I really think they ought to step back and redesign it. Look at other tools out there and see how well the UI is working for those. I don’t think they can fix it with the technology they’re using.

The GUI for the infrastructure, to me, is antiquated. We have products that we’re moving away from that have a better GUI and they’re 15 years old. That’s one of my biggest disappointments – I don’t find myself being as productive because the GUI is so sluggish and not user-friendly. Needs a lot of work.

It’s not as stable as I would hope -- we see probes losing contact with the hub, doing a failover. We see failovers and I wouldn’t expect that in this type of product – it just shouldn’t happen.

I would say it’s OK. We’ve got our environment on it, and it seems to be OK, other than the failovers, dropping of probes, and connectivity issues that seems to happen.

With the UI problems, we don’t know if that’s a scalability issue, but as we’ve added more servers, we’re having a harder time seeing all of our alarms.

Tech support is fair. I haven’t dealt with them a lot, but our team has. We’ve opened a number of issues. They respond in a fair amount of time.

One thing that jump to mind is the UIM console as we’ve had an issue with not seeing all of our alarms. It just freezes. That ticket has been open for well over a month and they haven’t come back with an answer which is hampering our progress.

I wouldn’t say it’s easy or complex – it’s pretty average. I think it’s a challenge in getting probes deployed, but some of that is part of our environment. I’ve seen other products that can deploy easier than UIM does.

What really brings it down is the whole user interface, and deploying robots in our environment – it could have gone better. They could have a better solution. They don’t handle custom monitoring well, where you need to customize something – whether it’s an action or needing to correlate alarms easily to take an action. We really had to jump through hoops to fit our environment in that way.

I would suggest you look at what customizations you have. I would do POCs with several different tools as it’s not a one-size-fits-all, especially when it comes to scale. Most tools can do stuff out-of-the-box basically OK. It’s when you’ve got your custom situations that you need to develop, that’s where you run into a lot of time and effort depending on the tool and how well it handles that.

I definitely enjoy the interface and how easy it is to deploy monitoring rules and probes.

It has provided us with faster triage. It is easier to upgrade and work with. It makes my job easier. If I can do my job better, then the organization should benefit.

I would really like to see HTML5. I spoke with a couple of developers about it. I'd also like to see additional monitoring so we can push rules a little bit easier.

I haven't had too many opportunities to expand. We set it up such that I can expand in parallel quite easily. We haven't had the need to do so yet, but I imagine it would work out.

I have used technical support. They are great. I usually interact with them by the web portal, submit a ticket, and then I get a call back. My issues are almost always resolved by them.

We used eHealth, which was another CA product. We noticed that UIM was getting a lot more development than eHealth. UIM was kind of a future product. We spoke with our account representative, and we did a one-to-one swap for licenses.

I was absolutely involved in the setup. I had prior experience with a product similar to UIM, so I was very familiar with the architecture. From that aspect, it was easy.

It is definitely a different architecture than other CA products that we are using. I can see where somebody without this experience would find the setup a little bit complex. For me, I grasped the concepts easier.

I enjoy the product. It has done everything that we expected it to do.

When selecting a vendor, the most important aspect is that their goals are aligned with our goals. I look for a relationship that is symbiotic. I want them to understand that when we do well, they do well.

Centralization and distribution are the most valuable features for us. Those two things are pretty key for our organization.

• Centralization is important because we can manage and view everything from one point.
• Distribution is important because we can manage everything from one point and do it on a mass scale.

We started with nothing, so getting anything was better. But through the years, it's improved stability-wise and is our bread and butter for monitoring. The openness of it means it can accept alarms from anywhere, which is pretty key because we have other systems that that are not CA.

It's too modular in the sense that there is not an awareness of things. If you set up an alarm for 10 different things but the actual host is down, then, in theory, you could get 10 alarms. Going forward, it would be nice if there was some kind of awareness of not just the host, but it knows what a service is and you can define it, it can suppress those kinds of alarms. Thay way, you only really get one alarm that is important instead of getting flooded with 10 or 15.

I would say, too, that I have seen some of their roadmap features and I think they are working towards that, but it is just a little more difficult because of the way they designed the software.

We've used it for about seven years.

We've had no issues with deployment.

There's nothing out of the ordinary with deployment because you're going to have some issues with all products depending on how it fits into your environment. Product iterations get better and better over the years. We've worked with UIM for seven years now, and we've seen a lot of different versions, and they get more and more stable.

I wouldn't say that there has been anything out of the ordinary.

I'd give them 7-8/10 as they're really responsive. CA's acquisition of Nimsoft has not resulted in lower quality support. We have twice-a-month meetings with them to talk about issues. They've helped us out a lot.

When I first started, we used Groundwork, an open-source tool.

It's pretty straightforward and intuitive.

I implemented it in-house, which, as I later found out at a conference, that I had set it up better than most others.

I did the evaluation before we decided to go with Nimsoft.

Look for three main things -- scalability, because you want a platform that will grow; ease of management, because you may have thousands of devices to manage; and single-point data presentation, because you could have hundreds of hosts with all their data.

CA UIM meets all of these at a less expensive price than the other large vendors.