AppDynamics Reviews

It automatically detects “slow” and “error” as transaction snapshots. The transaction snapshots help me find the root cause of the problem. Transaction snapshots collect business transaction information such as the application call stack and SQL statements.

It also captures important information about business transactions, such as method parameters and HTTP information (header, session, and cookie). The snapshots also correlate application calls among all monitoring nodes. It can identify the entry point to help us trace from the first tier to the back-end tier.

The solution helped me to find out if the slow transactions are caused by SQL statements or by external system calls. We also use it to trace the socket leak issue that occurred with the old mobile device version.

Adobe Flash Player is a forbidden program in many companies' IT security policies. AppDynamics was using HTML5 to improve its UI and replace Flash Player over the course of the last two years. However, its UI still has some features that require Flash Player as a display interface. They need to update their UI to HTML5 customer can easy to use and optimize UI performance.

We have used this solution for four years.

We did not encounter any issues with stability.

We did not encounter any issues with scalability.

I would give it the highest rating in terms of technical support. The support engineer responds to questions very quickly and his answers clarify the issues.

Our previous solution did not fulfill our monitoring requirements, so we chose AppDynamics to replace the old solution.

The AppDynamics initial setup is a very easy, out-of-the-box installation.

We evaluated Dynatrace and New Relic.

AppDynamics provides a complete online document. Everyone can learn by him/herself through the instructions provided in that document.

The fast setup of AppDynamics independent from the details of the application landscape is valuable.

We mainly use AppDynamics in our test lab to monitor the application undergoing testing together with its surrounding systems. The possibility to quickly drill down into problematic requests in combination with the drill down into all kinds of different monitoring data greatly reduced the time to analyze problems which we uncover during our load tests.

The graphical display of the monitoring data is very simple and unscientific. Histograms should be plotted as histograms. An easy export of the data of a graph in CSV or Excel format would be helpful for the creation of individual reports.

The advantage of a histogram plot is that you see the measuring intervals (bins) and are not mislead

to believe in a linear increase or decrease, where there was none. As for the export to .csv-files. It is very often necessary to prepare reports for customers or management. For those people the data need to be prepared individually with different kind of plots to emphasize the important point. Therefore a .csv-Export is very helpful.

We have been using this solution for four years.

AppDynamics was very stable. It needed maintenance about 1-2 times a year.

We did not encounter scalability issues, but our test laboratory does not host a large scale application landscape.

We got our questions answered in a timely manner.

At the time of our decision about which product to use, we tried several of the ‘main’ products and settled on AppDynamics.

The initial setup was straightforward. The most difficult part was the procedure until we had the correct license installed.

If you go in this field, consider that you will build a long-term solution, which will include a large part of your infrastructure. The tool is then very helpful, but you have to plan the long-term cost in your budget.

The simplicity of usage implies that you need not get a decent course on how to use this product. But if you go to a course, you can learn different approaches and you can get into contact with people to whom you might ask questions at a later time.

The most valuable feature is the fact that it can instrument without the developers having to do anything special or significant. You can just install it on the same machine that it runs on with the application and it works.

We're using it to give an overall picture of health for certain applications. It gives a little higher-level view of our application health.

I don’t know about room for improvement. I think it's pretty good at what it's designed for. I think it does a great job at what it's designed to do, which is Java, JVM, instrumentation.

See my answer regarding scalability.

It's stable. It's pretty good. The stability's good. It's got redundancy, failover, recovery of databases if one node goes down. It's pretty good. It's pretty solid.

Scalability-wise, I think it's a little limited on an enterprise-wide scale. It's like a medium-class scale. As far as load and distributed load, I think it could use some work.

Their technical support is great.

We were guided towards it from an architectural standpoint. Another person guided us to use it, so we set it up and we installed it.

Initial setup was both straightforward and complex in that most of the instructions worked fine, but then we had a specific situation where we had to go in and actually modify some files. That was the complex part.

It looks very powerful, and it looks like you really need to spend some time with it to get to know it, so don't just expect results right out of the box. Spend some time with it and get to know how to use it.

I believe we are using APM with AppDynamics reporting service.
My rating reflects the fact that I'm kind of a tough sell, I guess.

JVM memory monitoring, hardware monitoring, response time monitoring and proactive alerting.

AppDynamics has allowed us to find critical memory flaws in our application. We were able to find a root cause to a JVM permgen issue by using AppDynamics’ memory monitoring tools.

Remove all Flash from the product. Also make drilling down in the response time call stacks easier.

1 year

None.

Customer Service: 8 out of 10. They have answered everything I have asked.Technical Support: 7 out of 10. Sometimes not as specific as I would like but overall I am happy with them.

Our previous solution only allowed us to see hardware and response time latency, we were unable to drill into call stacks to find the root cause.

Pretty straight forward. Followed the setup guide and was in business within an hour or so.

In-house

Setup cost was about 2-3 days of a developers time to install / configure. Day to day cost is we have an extra server that needs to be on to run AppDynamics.

AppDynamics has a lot of information it can give you. Be sure to take the time and understand all the data. There may be critical information that can help improve your application performance.

We use this product for performance monitoring.

The monitoring is similar to Dynatrace.

The dashboard can be better. Also, the automated reports could be improved.

The UI in Dynatrace is more user-friendly.

I would like to see more automated reports. 

We were using AppDynamics from 2017 to 2019.

I have no issues with the stability of this solution. I have not had any problems.

AppDynamics is a scalable solution.

I have not had the need to contact technical support.

With my experience using Dynatrace, I would rate it a ten out of ten. It is more detailed and it offers more technology.

I was not part of the initial setup.

I would recommend Dynatrace, it's better than AppDynamics.

I would rate AppDynamics an eight out of ten.

On-premises

The most valuable feature is just the sheer visibility it gives us, especially being on the performance team. It's basically our "eyes" to the application. Without it, we don't know the flow, we don't know where things are being impacted. We just love the visibility it gives us.

We have a lot of legacy systems. We have a lot of engineers, people. Not everybody knows the whole picture, where AppDynamics basically stitches all that together for us. So, you don't have to go to 10 different people, you can go to one screen and see that full view.

It improves the way we work, it improves our efficiency; a whole host of things, actually. It allows us to be more proactive than reactive. It even helps us more in our non-prod environment. We find issues before we ever get to production.

We're definitely looking for adoption of more platforms. We have some legacy z/OS systems that we use, so we're looking to help stitch those in. It's pretty difficult to; things aren't on the open system side. We’re definitely looking for that.

Given the testing we do, we look for ways to save detailed information on tests, such as "point in time". If we have a test we run, and we want to save that granularity and be able to pull it up, like a month later. We've expressed our want for that.

We haven't had any stability issues. Overhead seems to be pretty low. With some existing monitoring solutions we've had, we've always had the concern for overhead. We don't seem to have that concern with the AppDynamics solution.

It seems to be scaling well for us. We have hundreds of nodes, hundreds of agents out there right now. I don't admin the tool too much but from what I've heard, it's scaling pretty well.

We have technical support. We have the technical services. We work with one of their engineers on a monthly basis. It’s great, very responsive, knowledge is really good.

Adoption: It's hard to do with just one person driving it. If you have that adoption, the team doing it, that definitely makes it a lot easier. Start on a couple small things. Work your way up. Don't try to do one "big bang" and get it all in there. At least for us, that's the way it's worked well.

In general, when I’m looking to work with a vendor, the most important criteria are definitely reliability, where they sit in the industry, responsiveness. They have to be responsive. They have to be cutting edge. Those are basically the main points.

As far as using other AppDynamics solutions, we started to get into the database monitoring side, so we can see some query performance, and not have to bug the DBAs; we can look at that ourselves. We’re enjoying that.

Features that are valuable to us are the business transaction transparency from one tier to the next and the ability to be able to drill down into the called stack. The ability to identify the stalled and error transactions in real time. And be able to investigate it, pick up the trends. That's one of the useful things. Because we use that as part of our root cause analysis and as a proactive, as well as a reactive way, to look at the incident and see what we can do to fix it.

For example, without getting in to the specifics of the issue, we've had some issues with our application where the capability in which we use tracing functionality to write the logs and stuff like that. And one of them had been enabled and it was writing it to a file instead of writing it to an HW, which was costing a lot of I/O. And unfortunately, at the time, the file share server that was taking all these logs was having an issue with the I/O. But it wasn't apparent because the experience of the customer was that the transaction was taking longer to complete. And we were trying to understand where's the bottleneck because everything looks healthy. But the requests kept stacking up.

But then, when we looked into the AppDynamics it make it very easy for us to identify that it was trying to write it to a log. And that operation, out of the entire chain, was this one step where it was trying to write to a location and that's where it was reporting a huge latency. In a matter of, I'd say about 15-20 minutes, we were able to trace it and be able to basically identify what the issue was and we fixed it. In fact, it drove a chain of reactions, in retrospect. Because obviously, it meant we need to look into these things much more carefully because to avoid these kind of incidents from happening in the future.

AppDynamics lets you find things that you wouldn't otherwise be able to see.
Without APM, you'd be spending a lot more time to try and investigate into all the individual event logs. Our services are massive. It's not a simple application with a front end and a back end. We have a lot of other micro-services that talk to each other. I think one of the trainers at a recent conference mentioned that one single touch starts a chain reaction. And when you have such a topology, it's very difficult manually to go through every single layer and figure out where the bottleneck is. Versus APM giving you an end-to-end workflow and gives you exactly which layer the AppDynamics thinks is having problem. Then it lets you drill down and further down. The zooming capability is brilliant.

I'm not aware that we use any other AppDynmics products along with APM. I've used the reporting and stuff like that. I'm part of an incident response team, so we are the command center for AppDynamics products. So we are more focused on the operation side of things.

One of the things that I've noticed is when you have a massive scale, turning on too much of data logging is not possible. So sometimes what's happening is we would use the snapshot capabilities to a minimum. But then what's happening as a result is we miss certain transactions and we need the snapshot.

I was working on a case and I knew what the problem was. I knew what the root cause was. I was trying to reproduce that case so I can collect the data in APM, which is a lot more user-friendly. Because I knew what the issue was, but if I needed to explain it to someone, I don't want to write an email. So I wanted a diagram view of what the issue was. And I was trying to reproduce it.

It took me a long time to get that snapshot in to the APM, because I think it wasn't taking very frequent snapshots. And it's probably the way we configured APM, because of the volume of data that generates it. They probably deemed it necessary to not just take every snapshot because obviously, it's a very expensive operation and it costs a lot of I/O and performance as well. So, that is something I would probably say that would be useful. To be able to say - I'd like to be able to do a snapshot much more frequently if it's possible in any way.

The monitoring capability could be improved. It's dateless right now. But, at a recent conference, I think one of the CTOs or COs mentioned that they're working with another monitoring solution to integrate it. But at the moment, it does have a monitoring capability, but it's very, very basic. Just to give you an example. Let's say if you get an alert, you don't want another alert in the next five minutes to say that it's down. You need to be able to increase the counter on that alert to say, look, it's still down but I don't want to trigger another alert. And every alert in our space would mean a ticket to our space. So you don't want to flag a hundred alerts for the same type of issue like a hundred times, if you know already what the issue is. So it's those capabilities. The integration, either with the existing monitoring capability, and that smooth transition. In fact, I was just looking at my email today. I have like 15 emails from APM. It's just way too much traffic for me.

Scalability is part of our day to-day jobs. At a recent conference, one of the trainers that mentioned very clearly that none of the databases are not growing. They are growing every day. The users are growing and the expectations are growing. They need faster and faster response times with complex systems. So, scalability is a number one priority for us. Because when the customer gets on-boarded, they are relatively small. But as the time passes by, they grow. But if you provision the capacity based on their initial requirements, eventually you'll hit a problem with the scalability.

So, it's very important to keep those factors in mind. And the best way to look at it is the usage analytics, the response rate. And the best part, and this is something that I took away from recent training is the base-lining. Because you don't want to be too late into identifying that you're hitting scalability issues. By then, customers would start experiencing issues. If you see that a deviation in the performance based on your baseline data, I think that's when you need to start thinking, okay, looks like the usage is going up. How do we scale better? How do we get more capacity, or fine tune if it's in any way possible, or distribute it? So, that's what I do every single day.

We have not really used technical support. I'm not on the side of configuring APM. I'm a user of APM. I just look at the data that it's already providing to me. Although there are a few questions, we usually pass them on to our guys who work with the AppDynamics to get them sorted out. I'm more of a subscriber to that.

I want a vendor to be honest. I've never been involved in those kind of conversations. But I'd expect them to tell me what exactly it does and what it exactly doesn't do. Nobody expects a product to be perfect. Nobody expects the product should have every single bell and whistle. But if you sell it that way, you're going to be disappointed. I'd rather know that upfront. And probably setup a roadmap and say, look, we are getting these features in the pipeline, which is a much more realistic conversation.

My advice is that just before you turn on APM, think about what's important to you. Just don't go ballistic on putting everything under the sun under the AppDynamics. The danger of doing so, the side effect of that is you're looking at way too much information and it gets foggy. Start with a subset that is critical to your business. Understand it from a customer perspective. Don't look at it from an operational perspective. Where do the customers feel the pain the most? Start with that and then start instrumenting those. Try and get as specific as possible because that way, whatever you're looking for in APM is important to you. If I'm an operations person and I'm dealing with hundreds of incidents every day, I'd like to see an incident that I'm absolutely working on. So try and reduce the noise ratio as much as possible. And try and look at the important ones that you should be straight away looking into and action on. I think that's probably the key advice that I would give anybody who wants to implement not just AppDynamics, but any APM into their products.

The valuable features of this product are being able to monitor the network traffic and know where my calls are generated from and where they are going to. This makes it easier for me to triage and diagnose, if there have been any problems.

We've been able to triage and diagnose problems sooner and proactively tell the teams involved if there have been lags in their performances, so they could look into them before there are any errors in production.

I would like to see some more work done for custom extensions. I don't think that there is enough support in that aspect.

We primarily have Java applications and that could be expanded as well.

It's been decent so far, at least since I've been working with it.

We did expand our licenses recently. It has been fine with the large number of servers that we have been monitoring.

We have used technical support. They have been proactive in answering all our queries.

Our company was using other applications and tools previously. However, they wanted a consolidated solution, so AppDynamics did offer a lot in regards to what they were looking for.

I'm not sure of all the tools that they were using but I know that they were using Nagios and GigaStor. I may be missing a few names but there were quite a few. Now we have narrowed it down to AppDynamics.

I was not involved with the initial setup.

I would recommend others who are looking out for a similar solution to try this product. However, it does depend on each business individually and what suits its needs; so I won’t be able to get into any specifics.

I personally don’t use any other solution besides APM but there are people on my team using End User Monitoring.

There's always room for improvement in this product.