DX Unified Infrastructure Management Reviews

We do E2E monitoring for service level availability of all of our applications. 

For our service level managers, it's performed a lot better than they expected. It's given them a lot more information than our old tool, which went end-of-life. We brought everything over to UIM. We gave them a tool that can give them everything they wanted, that they never had before.

From what I've seen so far, and what we're using, it's

• the data it collects and 
• the reporting capabilities.

For me, it keeps the service level managers off my back. 

It gives the service level managers, because they work directly with the application owners and the business owners, the ability to provide the metrics and the service level of the applications to the business owners. It's a win for both of us.

Because we have a lot of critical applications and we need to make sure that they're always available, I do scripting and make sure that the Synthetics stay up and are running all the time. It gives the business owners the knowledge that, "Hey, my application is up," and we don't have to wait for the customers to call in saying it's down.

Without deep diving into the infrastructure side, I really can't say because I only work with the Synthetics, end-to-end side of it. Right now there are just minor, little glitches, things that I see, but it's things I'm working with support on.

With the Synthetics it's more or less what a user sees in an application. There are some things that UIM can do and some things that UIM can't do. What it can do is great, and it's done a lot, and I've done a lot with the product that supports what we do. That's why I say it's a 10 across the board. 

The little things are, for example, maybe Windows.frames can't be seen within UIM, or within the side I'm working with. They say, "Oh, we're going to get that fixed in the next feature." Great, so we're in the process of upgrading right now. We're on 8.4.7 and we're getting reading to go to 8.5.1, which is the most current release.

Stability? Works great.

So far scalability is wonderful. We're looking towards broadening the scope of UIM within our company. We're staying with the E2E right now, but I think not too far in the future we're going to broaden it and go with more in-depth features. From what I've heard here at the CA World conference, it seems I'm the only one doing E2E. So we're going to get into the infrastructure side of it, which we're not currently doing.

Technical support is great. They've been wonderful.

The communication has been great. It also helps that, being a support person in my career in the past, I know what to fill out in the ticket and to help them. So we jive on what's needed and what's not. Putting things in the ticket that help them, up front, shortens the life of the ticket.

We were using a different vendor, different product and it went end-of-life. I call it "TM-ART" some people call it TMART, it is from BMC. 

We had to find another product.

It was straightforward, but we implemented about two weeks prior to CA World last year, when we got here and they asked, "How do you like it?" "Um, we just implemented, so we don't know." 

But for the past year it's worked great. We're still learning because we didn't fully implement UIM. The architect came in and said, "Hey, this is how you do it, this is what you need," and we took over. So, we're learning still.

We did a lot of research but UIM had everything that we needed. 

When selecting a vendor what's most important to us is:

• Does it do what we need? 
• Does it do what we want? 
• Do we have to do a lot of out-of-the-box modifications?

I give it a 10 out of 10 because it's doing everything we expected and looked for. Like I said, we haven't gotten into infrastructure, so I can't really rate it that way yet. But what I've seen in the pre-conference classes, it's going to work just as well. So, I would probably give it a 10 across the board.

Definitely PoC UIM. It is worth it. 

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.

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

What I like about DX Unified Infrastructure Management is that it's a very good product. The feature I found most valuable in the solution is the MCS feature, which is the automatic deployment of the objects you want to monitor. You can set up a system, for example, if it's a Windows machine and I want to test specific devices on it, I could do that through DX Unified Infrastructure Management. That type of deployment is very good because it means you won't miss any monitoring aspect on any server.

I'm very happy with DX Unified Infrastructure Management, but what could be improved is its user interface because currently, it has many wide spaces. All the information you need is in DX Unified Infrastructure Management, and it's a reliable tool, and though that's more important than the gaps in the user interface being smaller or wider, those gaps still need some improvement. I know the team is working on it. My company had some backend problems with DX Unified Infrastructure Management in the past that have now been solved.

The setup for the tool also needs improvement because it's complex.

Another room for improvement in DX Unified Infrastructure Management is its technical support because it's sometimes not as knowledgeable or responsive.

What I'm suggesting to be added to the tool is an open-standard ELK Elastic-based database where you can put in all data, so that you can use the data in other systems as well.

I've been working with DX Unified Infrastructure Management for a total of six or seven years now.

DX Unified Infrastructure Management is a very stable tool.

My team finds DX Unified Infrastructure Management scalable. It's good enough in terms of scalability.

The technical support for DX Unified Infrastructure Management could be better because the quality of support fluctuates.

On a scale of one to five, I'm rating support a three.

Sometimes, half of the year, support is perfect, and then for some reason, in the other half of the year, support becomes less responsive and less knowledgeable.

My company asked for improvement from the support team and mentioned the areas my team is unhappy with, and now I see support for DX Unified Infrastructure Management improving again.

I found the initial setup for DX Unified Infrastructure Management complex, but the environment in my company is rather complex. It's a complex setup for every tool, and I doubt other tools would be able to match the requirements of my company.

Pricing for DX Unified Infrastructure Management isn't cheap at all. It's a complex tool, so you have to pay more. No one is happy with a large bill to pay, but if it's a complex product and you designed a complex solution to be monitored, it'll be your fault that you need to buy an expensive product, and that would be implicit in the design of DX Unified Infrastructure Management. Monitoring is just a small part of it. Sometimes you have to pay a significant amount of money for a complex yet very good solution.

We'll be comparing DX Unified Infrastructure Management against another product, so we still don't know the outcome. Scalability and advanced features are the main reasons people choose DX Unified Infrastructure Management over other tools.

I'm using the latest version of DX Unified Infrastructure Management.

Within the company of nine thousand people, about four hundred people use DX Unified Infrastructure Management, and department-wise, there's a total of sixty user accounts.

My rating for DX Unified Infrastructure Management, in general, is eight out of ten. If the price could be lower and functionality could be higher, I'd give it a ten.

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 most valuable feature is that it allows me to do systemic and additional levels of probe automation on every VM we have in the cloud. We just recently moved from VMware to OpenStack. Our internal cloud infrastructure has changed drastically over the last year. Right now we are scrambling to integrate a lot of other components into OpenStack for cloud.

It's given us the ability to define and isolate where issues are occurring. We went from a vCenter cloud to OpenStack for all seven systems and our control hosts. A lot of it is a retooling and relearning for us. We're going to an agile development platform. A lot of that is coming through as we're using different development tools. We are going from JS to a Docker component. A lot of things are changing right now. At the ground level, we're reengineering everything.

The UIM product is playing catch-up. They are not there yet to do a lot of the next-level things that we need them to do. The auto on-boarding, the customer self-service pieces of it. We are hoping to meet with them in about two weeks to start looking at ways we can get that done. Also, High Availability, the failover capability. For their product, we were going to go with a hardware platform for HA. Two separate blades with a bootable SAN piece. They got a software-driven HA position. I'll take a look at it and see what it has to do. I think there may be a lot more moving parts there than what I want. We will see.

Also, since we went to OpenStack, we have to integrate storage and networking to a certain extent in there. Each of the probes that we use has to be specifically built in the system. Right now, CA is pretty much at ground level with it. I think the next release in Q2 well probably be much more enhanced towards that end.

There are the two more things I want. First, customer self-service where they can go in and make whatever changes they want to make, absent giving them admin access to my consoles, so long as it affects only their applications. You want to make modifications on threshold limits for severities for these things to go out to the service outside, I'm okay with that. How do we get that done? How do I get from RA to the desk station? How do I get there? I don't know.

Second, I'd like an HA variant that isn't going to scare me, and help me do all the on-boarding. I'd rather deal with the blades. I've got two blades out there with a bootable SAN system. Each blade fails, bam, this one comes up. All the VM's come right over. Pretty simple to me. That's what I'd like.

It's a very stable platform. We got it, we installed it, we put it inside of OpenStack, and it should not have been. We can't do systemic monitoring inside the hypervisor piece of it. It's resident on OpenStack. There's no routable way to get to that from a guest VM. It's designed that way for security. From a guest site, you can't go out to the community toolbar system. It's not going to allow you that.

The control hosts are the things around the OpenStack piece. Also the control hosts are like the ESI box. For us to launch that from a guest VM off a hypervisor, to try and do systemic monitoring from a hypervisor to a control hosts out there that's handling all of the hardware, or the secondary pieces of OpenStack, it says, "No, I'm not going to allow you to do that." We had to port out a static IP to go out there and do that, which was really not good. It was bad practice. It wasn't always stable. Once we moved it off the control hosts and we start putting blades within the cloud structure, it was fine.

It's really easy to build out as long as you know SQL. On the backend, we put it on Windows in 2008. We’re running 2012 SQL on the back end. It's pretty straightforward.

On the Linux side, we are up to RHEL 7. There is some legacy 6065. We are moving RHEL 7 now. It's already hitting RA. On the Windows side, there's not a lot of Windows out there for us. What is out there, they absolutely are very, very hesitant about it -- if it ain't broke, don't fix it.

Really good. Very, very good. I got nothing but nice things to say about them. From a pre-sale side all the way through to the support and logging a ticket. They are very prompt for our purposes. That day you put the ticket in, someone's calling you an hour later. If I chat up one of the engineers I know, let's do a WebEx and we will get on there, take a look what's going on.

We had VMware up and running fine. We had an internal cloud on VMware, it was great for five years. It was almost self-regulating. Then we decided to go this other route. You know what VMware had under the hood? You have to script and program on to OpenStack to make it do the RS capability. It was a lot of "holy cow!" going on.

It’s pretty straightforward.

The legacy club was already on CA with something called CA 6. It was up and functional. We always used it there. Then we started to go OpenStack, open source. I did seven or eight POC's in four months.

We looked at XenOps, we looked at MagiOS, we looked at Isinga, and we looked at CA. At the time we looked at it, CA wasn't ready. The UIM piece wasn't ready to do the no-JS, it wasn't ready to look at RHEL 7. It couldn't do OpenStack. We pushed it to the side. Same thing with EMC. We had the same problem with them. They were ready to do OpenStack or RHEL 7. We put them aside. We were going to run XenOps. Then we looked at Dynatrace. The APM solution is what we kept. They said to do a whole bunch more, but it fell short to a certain extent. We were pounding a square peg into a round hole. After about six months of playing with that, trying to get it to work, we finally said drop it. CA came back, said, guess what we can do. They met our requirements and our success criteria as well. We didn't have to have a POC on top of it. It's a new version of it. We are on 18 now. Once we put it in play and saw what it can do, it was, this is it.

Define your success criteria very well. Make it pointed to your needs, to your industry, specifically your company. Test against that. Don't let the app teams get involved. They are going to give you 14 or 15 different variations of the same damn thing you're going to be looking at anyway. You've got to look at each one of the systems in the enterprise.

We've got six, seven, 800 applications. Each has an app team. Now, we've got an enterprise environment and IAS environment. Enterprise is running another 500 applications that are coming in through them, for the mobile applications spot. If I tried to get, it's like building an elephant by committee. We have to define 80 percent of what we want to do and monitor in the cloud. The other 20 percent has got to be free to customize. What I'm trying to do is build to the 80. Allow me to do as much automation as I can to that 80, and then leave the customization to the 20.

• Ease of setup - install is quick and easy. For small environments, all components can be installed on a single server. Even larger, more-distributed environments are easy to install, given all required network ports are open.
• Automated robot deployment makes it easy to select targets for performance management.
• Justifiably, local and remote options are available for agent-based and touchless monitoring.
• Most probe configurations are OOTB best practices. The probe GUI is easy to navigate.
• A new feature, MCS, allows for monitoring policies to be created for groups of devices. You can monitor just about anything.

We are a managed services organization. Knowing about performance issues before our customers is key. To have reports ready at the beginning of the day is even better. Report scheduling is priceless.

I would like to see enhancements to core probes for bulk uploads. Some probes have the capability to monitor multiple targets. You either must enter them one by one or use scripting to bulk load the targets. I would like to see that functionality built into the probes.

We have been using this product for about seven years.

We have not encountered any stability issues.

We have not encountered any scalability issues.

The technical support is excellent. 24 x 7 support is awesome, not to mention that their support staff really knows the product. What makes it better is that support and development work close together so that turnaround on bug fixes is expedient.

We previously used Solarwinds NPM but it wasn't as scalable.

Setup was easy.

Buy what you need. The product is worth every bit of its cost.

We did not evaluate any other products beforehand.

Plan and commit people and processes. Build a service, don't just implement a tool.