AppDynamics Review

It finds bugs in dev and test environments before they escape into staging/prod. We need it to track async calls because most of our APIs are async calls.

What is most valuable?

  • Business Transaction Tracking
  • HTTP Header values
  • Introspecting slow and error transaction at different tier levels
  • Analytics helps to group business calls based on vendor by using HTTP values

How has it helped my organization?

  • Finds the bugs in dev and test environments before they escape into staging/prod
  • Helps to pinpoint where the issue is by application tier
  • Identify performance bottlenecks
  • Group business calls (API) by vendor
  • The above key points mentioned have helped the DevOps team work more effectively and reduce the turnaround time between releases
  • Reduced the debug time

What needs improvement?

The primary feature we are looking for is tracking async calls because most of our API are async calls. We cannot view HTTP data.

We require a seamless way to upgrade the controller and .NET agents.

The plugins available are tedious to use and not robust, e.g. URL monitoring.

The application(controller) is very heavy on hardware. This increases our cloud cost.

It should be more intuitive and provide better metrics when drilling down in the UI.

  1. Instrumenting Async method calls:
    For example, let's say we have Async Rest API call written in with this method - public async long Multiply (int x, inty). Now this call may take 5-15 seconds for REST Response. In AppDynamcis we have an option to instruement a specific method by providing the method definition and its parameters passed and returned values. We can define as variable data collectors to do this, and this is available with the drill down of the call stack. The data collector or variables should show the value which doesn't, and we also tried the diagnostic mode where we can introduce a delay. Though AppDynamics say there are settings to enable tracking of Async calls, but I think it's more inclined and friendly for POJO(Java) calls than POCO(dotnet) calls.
  2. HTTP Data Collector for Async calls:
    In the above example, if we like to see the HTTP data collectors then there is an option to view the HTTP header variables and custom variables. However, there is no way to see the JSON request and Response data in AppDynamics. I can view this in IE or Chrome using developer tools on the client but not within AppDynamics. I'm not sure if this feature is available in EUM which we haven't procured yet. Also, I don't rule out possibility I might have over looked something and missed it, but I really tried to get this working. Also, the AppDynamics team failed to assist to get this working.
  3. Plug-in's tried:(SQL monitoring and URL monitoring)
    There was a requirement where we wanted to query our database directly and display certain values (integer) in the AppDynamics UI for monitoring, say, a number of active sessions or database locks etc. Though AppDynamics doesn't provide an out of the box solution, the plug-in's available on Git-Hub which are claimed to be stable aren't working either. Ultimately, we succeed in writing custom VBS files which leverages database machine agent service provided by the tool. With this tool we dump the data to metrics file and manage to integrate. This was very good experience to get our hands around and customize few things which not found in the community of AppDynamics.

This also goes with URL monitoring script provided by community in Git-Hub and also Plug-In repositories on the AppDynamics site. This plug-in is a little tedious to configure because of the YAML file, and only supports HTTP 200 is alive i.e ping request to PORT 80. There's no script for login automation. Again we managed to write custom scripts here for logging using VBS.

There seems to be a certain disconnect between the AppDynamics development and support teams. Maybe because this is a developer intensive engineering tool and support guys need to understand the framework of .NET or a Java ecosystem and applications that cut across various design architectures. This could be a gap which AppDynamics needs to bridge.

For how long have I used the solution?

I have used this solution for one year.

What was my experience with deployment of the solution?

The controller slows down with Windows platforms.

Sometimes the MySQL process of the AppDynamics controller takes lot of memory and the controller hangs, despite configuring it as per requirement.

Since the application is agent driven (client side), if we need to upgrade the .NET agents on 100 servers, then we need to visit 100 servers to upgrade or deploy them.

How are customer service and technical support?

The technical capabilities of people sitting in technical support is questionable. The reason being this is an engineering tool for application instrumentation both for .NET and Java. We have asked queries and also raised some issues. For most of the issues, especially regarding tracking async for .NET API, we never received a solution. Also, some configuration issues where primitive in nature but not resolved immediately.

The technical documentation contradicts technical support.

We started using version 3.8 of the tool, and since then, I don't see many changes on the support side.

Which solution did I use previously and why did I switch?

No, we didn’t use anything in the past for application monitoring. This was the best out there in the market as per evaluation by market research. The tool was a good fit when we did a POC.

How was the initial setup?

Initial setup was complex.

Setting up configuration to track the metrics is little tedious.

Understanding the metrics numbers is little confusing as they contradict, e.g. The number of API calls displayed on the main screen is different than on the analytics screen.

A normal user would find it difficult to understand and read the metrics, because too much drill down is necessary, and the numbers are difficult to interpret and relate to the problem.

What about the implementation team?

Implementation was done in house. The tool is configuration intensive. A good development and operations team need to know the application dynamics to configure this application.

Since it’s high on budget, it’s recommended to buy a developer license and play around with this tool in a dev environment and then procure for production.

I don't think premium vendor support is required for setup and configuration.

What was our ROI?

We haven’t reached the stage where we calculate ROI, as we are in the early stages of onboarding customers. We can probably gauge this once we have a sizable number of customers on board, which will take time. Measuring ROI will be calculated by using the API call tracking by customer and also the turnaround time (time saving) in the early stages of development cycle.

What's my experience with pricing, setup cost, and licensing?

The pricing is way too high, especially with the analytics feature and end-user monitoring.

They have separate licensing offerings for development and production.

The best option is to get into an engagement for a few months before procuring this tool.

What other advice do I have?

This is purely an application instrumentation and monitoring tool with good features for business analytics.

It is probably more integrated and works well with Java application, as some features for .NET don't work.

Host the AppDynamics controller on a Linux machine with a medium or high profile. A Windows server machine would show symptoms of disliking it within 2 to 3 weeks of setup.

It is not comparable with infrastructure tools. The plug-in available to track infrastructure-related activities are not stable and not robust.

Which version of this solution are you currently using?

**Disclosure: I am a real user, and this review is based on my own experience and opinions.
More AppDynamics reviews from users
...who work at a Financial Services Firm
...who compared it with Dynatrace
Learn what your peers think about AppDynamics. Get advice and tips from experienced pros sharing their opinions. Updated: September 2021.
534,768 professionals have used our research since 2012.
Add a Comment
ITCS user
1 Comment

author avatarAnton Kasimov

Could you clarify, why you didn't use Ansible to deploy 100 agents?