The AppD Approach: How to Monitor the AWS Cloud and Save Money

The AppDynamics platform is highly extensible, allowing our customers to monitor a variety of key Amazon Web Services (AWS) metrics. We have 20 unique AWS extensions that capture stats for everything from Auto Scaling which optimizes app performance and cost, to Storage Gateway which enables on-prem apps to use AWS cloud storage. We’re always fine-tuning these cloud-monitoring extensions and making improvements where necessary. In some cases, we’ll integrate these features into our core APM product to keep it best in class.

What can AppD’s extensions do for you? Each efficiently gathers metrics from all Regions and Availability Zones in the AWS Global Infrastructure. Using Amazon CloudWatch APIs, our extensions pull metrics from specific AWS components and pass them to the AppDynamics Controller for tracking, and for creating health rules and dashboard visualizations. These cloud-monitoring extensions give our customers greater insight into how their apps and businesses are running on AWS.

The AWS EC2 Monitoring Extension, for instance, retrieves data from Amazon CloudWatch on EC2 instances—including CPU, network and IO utilization—and displays this information in the AppDynamics Metric Browser. Similarly, the Billing Monitoring Extension captures billing statistics, while the S3 Monitoring Extension pulls in data on S3 bucket size, the number of objects in a bucket, HTTP metrics, and more.

AppDynamics users can also leverage the AWS cloud connector extension to automatically scale up or down in the cloud based on a variety of rules-based policies, such as the health of business transactions, the end-user experience, database and remote services, error rates, and overall app performance.

This cloud-monitoring extension helped one AppD customer avoid a Black Friday ecommerce meltdown by implementing health rules to automatically scale up EC2 resources when certain load and response time metrics were breached, and scale down when those metrics returned to normal. Another plus: By adding an authorization step to these workflows—one that asked permission before spinning instances up or down—the customer paid only for EC2 resources he needed.

Simple Setup

It’s easy to edit an AppDynamics AWS extension’s config file, extract the performance metrics you need, and show the data on your dashboard. Once you provide the necessary information in config.yml (see below), the extension will do the rest. You can select time ranges for data gathering, include/exclude specific metrics, and specify the way you’d like your stats collected: ave, max, min, sum, or sample count:

How AWS Extensions Save You Money

Many of our customers are gathering AWS metrics in the AppD platform. Collecting these metrics requires the use of Amazon API calls, which can get expensive when used excessively. As reported by AWS, a recent study by migration analytics firm TSO Logic found that most organizations are overpaying for cloud services, and that 35% of an average company’s cloud computing bill is wasted cost.

AWS regularly releases new products, all of which use CloudWatch APIs. The good news is that AppDynamics offers a special extension that monitors products using those APIs. By helping you collect only the metrics you need, AppD can help you manage your AWS bill.

EC2 Example

CloudWatch monitoring has two levels of pricing: Basic and Detailed. In Basic monitoring, metrics are updated in five-minute intervals; in Detailed, metrics are updated every minute.

Let’s say you have an EC2 instance that returns seven metrics, and you want to monitor all EC2 instances from one AWS region. To do so, you install the EC2 Monitoring Extension on your machine agent, and add your access key and secret key to the config.yml file. Then add the AWS region you’d like to monitor.

The extension makes a call to AWS to get the list of instances for each region listed in the config file, as well as the metrics associated with them. To get a metric value, AppDynamics calls CloudWatch to get the value associated with each instance.

Simply put, API calls add up in a hurry. Let’s look at an example:

1 list call + 7 metrics x 1 every minute   = 8 calls
x 60 minutes/hour = 480 calls
x 24 hours/day = 11,520 calls
x 30 days = 345,600 calls
x 20 instances = 6,912,000 calls

CloudWatch pricing gives you one million free API requests each month. This means you’ll be charged for the remaining ~6 million calls.

How can AppD help? By letting you specify how frequently your AWS extensions should make API calls. This feature allows you to dramatically reduce the number of AWS calls, while still monitoring all of your instances. It has been very effective for several AppD clients and is being added over time to all of our AWS extensions.

Select Your Cloud-Monitoring Metrics

Metric selection is another key feature of our AWS extensions. This is important because CloudWatch, by default, provides several metrics that may not be necessary for monitoring your environment.

AppDynamics’ extensions let you select only the metrics you’d like to monitor. In addition to better managing your CloudWatch bill, this also allows you to better manage which data is important to your business, and which isn’t.

You can monitor individual instances as well: Choose the instance you’d like to monitor, and the extension will only make calls regarding that instance. Since this feature allows you to monitor just those instances you use regularly, it saves money.

AppDynamics is always refining its AWS extensions, making improvements where necessary and integrating some of these features into our core APM product. Again, if there’s an AWS metric you need, we collect it. If you have specific AWS needs, contact your account manager. Want to learn more about AppDynamics? Learn more here or schedule a demo today.

Black Friday Horror Story Averted with Alerting and Monitoring

AppDynamics recently announced the launch of our Application Intelligence Platform, which is the underlying infrastructure that delivers our portfolio of products to customers. A key component of the Application Intelligence platform is the notion of extensibility – we can integrate with many of the existing tools you already have in place so you can leverage AppDynamics analytics in the tools and dashboards your team knows and loves with minimal effort. These extensions as we call them are available on the AppDynamics eXchange section of our Community for download, and customers even have the option to submit extensions they’ve written themselves to be included in the eXchange.

To illustrate the power of the 75+ extensions we’ve published in our community, I’ll walk you through two scenarios that involve several common technologies that are prevalent across our customer base.


Before AppDynamics:

Jerry has been tossing and turning all night long. In fact, he’s had difficulty sleeping the past three weeks. His sub-optimal sleep patterns are in large part a result of the production application environment he is responsible for. “Things always seem to break in the middle of the night,” Jerry complained to his wife earlier that day.

As the DevOps lead for their company’s mission critical ecom app, Jerry is copied on most urgent application related alerts so that he can help manually forward the details he gets from his current monitoring tools to the admin from his team who happens to be on call at the time. Tonight, he only received 5 such notifications which is less than normal, but still sufficient to wake him up throughout the night. As he squints in the darkness and his eyes adjust to the bright screen, he sees a new notification that troubles him… “SSL Certificate Expired?” he mumbles to himself. “How is that possible?”

He checks the clock – 5:30AM. The person who handles the SSL Certificate isn’t going to be awake for a few more hours. Jerry’s heart drops because he knows that for every hour his ecommerce application is down it costs his company about $10,000 of revenue. “Why wasn’t this on my radar?” Jerry says. “We could’ve planned for this.”

Jerry gets to work early and starts sending emails and calling stakeholders to schedule an 8:30AM conference call. By 9:15AM the action items and deliverables are clear. By 10:30AM the SSL Certificate is renewed and the ecom store is back online servicing customers. Whew. “That could’ve been a lot worse than just 5 hours of downtime and $50K of revenue impact,” Jerry reasons with a colleague.

Back at his desk, Jerry looks at his calendar, his next meeting is ‘testing & capacity planning’ which is a weekly recurring meeting with him and his team.

Jerry’s company is preparing for the holiday season (Black Friday, Cyber Monday, etc.) which is still a few months away but for ecommerce stores, these peak seasons are huge operational and business challenges. You know that $10K per hour of revenue metric?  During those peak days in the holiday season that quadruples to $40K of revenue per hour. The ecommerce store can’t have any hiccups during that time or the impact would be massive, and that’s why this particular recurring meeting leading up to the code freeze are very important.

Jerry greets his team and looks over the shoulder of one of his sys admins. She’s just got the application infrastructure diagram drawn on the white board and has the first load test done and now they are analyzing the results. Looks like most of the synthetic tests they’ve run completed with relatively few errors and utilization was within the acceptable range even as the load increased over the duration of the load test. So far so good.

Jerry moves on to peek over the shoulder of his DBA who is currently analyzing the Cassandra cluster metrics after the load test. Disk I/O looked good and memory looked OK. Over the course of the next hour Jerry’s team tests 6 different load testing and failover scenarios. Today’s tests are done – until next week.

“Everything looks good… a little too good,” Jerry says to himself. “My team and I understand things like utilization and throughput but how does that translate to things my boss and the rest of the business care about?”

If only there was another approach to monitoring that would save Jerry from the fire drills, cut down on the constant testing and debugging, and give him a real-time view into how customers were engaging with his ecommerce application…

Luckily for Jerry, AppDynamics does just that…  Let’s look at this same situation one year later.

After AppDynamics:

Jerry wakes up from a great night’s sleep and checks his email for the daily AppDynamics events digest that gets sent to him with all of the application events over the last 24 hours. Only one event in the digest. Ever since Jerry’s organization invested into AppDynamics’ products that are delivered on the Application Intelligence Platform, his dev team has gotten code-level visibility into the root cause of performance issues inside his ecommerce application and has substantially cut down the number of bugs in the software. That means less production issues for his team to deal with downstream.

Using the PagerDuty alerting extension, the one issue that was sent in Jerry’s digest triggered the creation of a help ticket and was automatically assigned to the technician on duty with no manual intervention on Jerry’s part.

By the time Jerry checked on the status, the issue was already resolved. Nice.

On his way to work, Jerry smiles and thinks about last year’s SSL Certificate debacle. Since installing the SSL Certificate Monitoring extension from AppDynamics, his team has been able to build a dashboard that shows the number of days left until the SSL Certificate expires. No more SSL Certs expiring without anyone knowing ahead of time.

Jerry arrives at work and goes to his recurring ‘testing and capacity planning’ meeting that his team sets up every year around this time. Since deploying AppDynamics and installing two additional AppDynamics extensions – the Cassandra monitoring extension and the Amazon Web Services (AWS) cloud connector extension – his testing and capacity planning work for the holiday season has gotten a lot easier.

First, AppDynamics has given him and his team a great topology view that has relieved them of their needs for Visio diagrams and whiteboarded architectures. Being able to have a real-time view of how the different components of an application interact with each other, and have that map update automatically as new code is released, was hugely valuable for Jerry’s team.

Screen Shot 2014-06-18 at 10.26.02 AM

Second, during Cassandra testing, in addition to getting basic metrics like disk I/O and memory, the Cassandra extension provides configurable metrics like:

  • Cache size, capacity, hit count, hit rate, request count

  • Total latency, statistics, timeout requests, unavailable requests

  • Bloom filter disk space used, false positives, false ratio

  • SSTables compression ratio, live tables, disk space, compacted row size

  • Row size histogram

  • Column count histogram

  • Memtable columns, data size, switch count

  • Pending tasks

  • Read latency

  • Write latency

  • Pending and completed tasks

  • Compaction tasks pending and completed

  • Timeouts

  • Dropped messages

  • Streams

  • Total disk space used

  • Thread pool tasks: active, completed, blocked, pending

By leveraging these metrics, Jerry’s team is able to get granular visibility into Cassandra performance and see exactly where performance bottlenecks occur. This visibility has cut down the time needed to test their Cassandra implementation drastically. Pinpointing exactly where the performance issues are and what caused them enable Jerry’s team to proactively address Cassandra performance issues before they affect end users.

Finally, while capacity planning, Jerry now leverages the Amazon Web Services (AWS) cloud connector extension which allows his team to easily scale up and scale down in the cloud automatically based on policies that can involve a number of rules including:

•       Overall application health (load, response time, number of slow calls, etc.)

•       Business transaction health (load, response time, number of slow calls, etc.)

•       End User Experience health (pages / iFrames / AJAX requests per minute, first byte time, DOM ready time, etc.)

•       Databases & Remote Services health (calls per minute, errors per minute, etc)

•       Error rates (exceptions, return codes, etc.)

This year, Jerry’s team is putting a few different health rules in place that will automatically scale up the AWS EC2 resources when certain load & response time metrics are breached and scale down when those metrics go back down to a normal level. Jerry has also added an authorization step to these workflows that will alert him and ask for permission before spinning instances up or down. That way, they only pay for the EC2 resources they need to use and Jerry still has full control.

Screen Shot 2014-06-12 at 3.49.26 PMScreen Shot 2014-06-12 at 3.49.51 PM

Screen Shot 2014-06-12 at 3.50.17 PM

Jerry leaves the testing meeting with full confidence that his team has a good grasp on the upcoming peak season and has the visibility in place that will allow his team to quickly deal with any performance issues as they arise.


As you can see, Jerry is in a lot better spot this year than he was 1 year ago. By leveraging AppDynamics he has one platform that can easily connect to the rest of the technologies he already uses and provide him a single UI in which he can manage the performance of his environment.

If you’d like to try AppDynamics for free and test drive some of the extensions we’ve highlighted in this blog post, click here.