Splunk AppDynamics Reviews

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.

In terms of our use cases, we monitor cloud instances and application instances. When we do performance testing, we monitor all the metrics, like server-side metrics, as well as the client-side metrics. If it is a browser with real user metrics, mobile user behavior kind of things, we'll monitor it as well. 

Whenever the application crashes from user behavior, we can easily simulate the error. We are happy with this feature and find it to be valuable. 

In terms of improvements we would like to see, we want to understand what the battery consumption metrics are whenever a user is viewing something in an app. It would be really helpful for us if we could get those details levels.

I have been using AppDynamics for the past four years.

We use on-premise, cloud, and public versions.

The stability is quite strong. We never experience any downtime. The only thing is that sometimes the agents get stuck where CPU memory metrics will not be recorded. Once we restart those agents, it will work as usual.

I am satisfied with support. We have a dedicated team that works whenever required. If we have any issues in any of the systems, we will send that email to them and they respond immediately. Their response is quick.

I would rate it a seven out of ten. 

Whenever a user uses the device and does a transaction on his phone using some of the apps we want to know how much battery consumption it is taking. We want to understand those level of metrics.

I would definitely recommend this solution. The reason being that it gives more information than we generally need. Whenever we create automation or performance scripts and we want to understand where exactly the crash report is happening, this tool would give more information. Dynatrace is also another tool that gives more information.

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.

Application Flow Map, Operational Dashboards, Transaction Scorecards, Exception details (stacktrace, sql queries, etc), it provides all the information required to engage the issue, Metric browser, Information Points, Correlation Analysis.

We can evaluate the performance of an application by doing a few clicks and find bottlenecks very easily. Automatic alerts on resource exhaustion for DB connection pools, HTTP app thread pools, discovering unexpected performance difference between identical applications instances. We have become more proactive rather than reactive.

Charting is cumbersome; inability to do decimal fraction arithmetic in expressions (for alerts), so everything has to be done in % rather than as natural fractions. Can’t get response time by host for an given host group without laboriously setting it up in the chart widget.

For seven months. We started with the controller hosted at AppDynamics servers, then we put the controller in an in-house virtualized environment and finally in a physical server in-house.

I didn't encounter any issues with deployment, stability or scalability.

It’s good, they have really fast response times.

Excellent in terms of commitment, response times and technical knowledge.

We haven't used any other solutions in past, this is the first APM solution we use for our Java based applications.

It was pretty much straightforward, we didn’t face any big problems when setting up AppDynamics.

We implemented through an In-house team.

Yes, I evaluated OPNET as well.

Scale the product properly within your system’s architecture to get better results in order to analyze your app's performance properly.

We've used AppDynamics to easily identify application slowdowns and rectify them on several occasions. It has also helped in our QA environment to analyze new releases and ensure they are not harming performance.

Stack trace of PHP calls through the application and timings of those calls.

None.

Just that we've run out of agents in our license :P :(

Customer Service: 10 out of 10, all our questions and issues have been addressed and resolved quickly.Technical Support: 10 out of 10, as above, all questions and issues have been addressed and resolved quickly.

No, AppDynamics was our first.

Very simple- install controller, install agents, configure agents, done.

In-house

Quicker turnaround on finding/resolving issues or improving performance, which leads to improved client experiences.

We investigated several other APM solutions prior to going with AppDynamics, specifically New Relic and dynaTrace.

Read up on documentation, and play around with the config settings, there is a vast wealth of information that can be retrieved if you know how to look for it.

Our main use of this AppDynamics is to monitor customer applications, such as web applications. For example, to monitor the availability of online stores, and to figure out whether we have any problems.

AppDynamics has a very broad range of supported technologies, and it's user-friendly. It looks nice, and it's easy to sell the solution to the stakeholders when we can visualize how the website is working. For example, where we have any problems through visual analytics.

The end-user experience is not really good because we can't catch all of the transactions. We only can catch the full stack of flow transactions, but I think that this is caused by the technology they use. If they will catch every transaction, it will cause a very big load on the performance of applications. The monitoring of all transactions needs improvement.

I have been using AppDynamics for approximately eight years.

The solution has been stable in my experience. 

The solution is scalable. AppDynamics has been flexible enough for what I use it for.

I have not contacted support. We have only used our local distributors, and they have been good.

I have used an older version of Dynatrace previously.

The solution is easy to deploy if you know what you are doing. It was simple for me.

The price of AppDynamics could be reduced in my region.

My advice to others that want to implement this solution is to have a test environment, and then go to production. Sometimes it requires tuning of the software and restarting services a couple of times,  it's better to make all of these changes on a test environment, and then to move to production.

I have been using AppDynamics for approximately eight out of ten.