cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Akshay.Srivastava
AppDynamics Team

What should I consider when configuring AWS extensions with AppDynamics? 

 

Table of Contents

 

What should I know about monitoring AWS with AppDynamics?

AppDynamics provides multiple AWS extensions to collect metrics and monitor various AWS services or namespaces. All AWS Extensions pull metrics from AWS CloudWatch.


Visit AppDynamics Exchange for a complete list of AWS extensions. If an extension for a particular AWS namespace is missing, try using the AWS Custom Namespace Extension.

 

How can I configure AWS extensions to connect to AWS? 

AWS extensions can be configured to connect to AWS in several ways.

 

 

Using IAM Roles to connect with AWS

The most preferred option, IAM roles can be provided to users, accounts, services, and applications to delegate access to AWS resources. Using this approach, an IAM role with necessary permission policies can be provided to an AWS EC2 instance in which the MA/SIM agent is running. 

 

See more details on Instance Profiles (IAM Role on an EC2 Instance) here. In this mode, the accounts section in the config.yml should be configured as follows:

accounts:
	- awsAccessKey: ""
	  awsSecretKey: ""
	  displayAccountName: "<USER_DISPLAY_ACCOUNT_NAME>"

 

Connecting to AWS with account credentials:

An AppDynamics AWS extension can be configured to connect to one or more AWS accounts by providing account credentials in theconfig.yml

 accounts:
	- awsAccessKey: "<ACCOUNT_ACCESS_KEY>"
	  awsSecretKey: "<ACCOUNT_SECRET_KEY>"
	  displayAccountName: "<USER_DISPLAY_ACCOUNT_NAME>" 
              regions: ["us-east-1","us-west-1","us-west-2"]

Note: AWS Account access and secret keys will be provided by the user’s AWS Account admin, not by AppDynamics.

 

AWS Extension Permission Policies

At the very least, an AppDynamics AWS extension needs read-only access to the various CloudWatch APIs. 

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "cloudwatch:List*",
                "cloudwatch:Get*"
            ],
            "Resource": "*"
        }
    ]
  }

Certain AWS extensions may need more permissions to fulfill additional use cases. For example, AWS EC2 Extension needs permission for DescribeInstances API in order to filter the EC instances by tags.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "cloudwatch:List*",
                "cloudwatch:Get*",
                 "ec2:Describe*"
            ],
            "Resource": "*"
        }
    ]
  }

If multiple AppDynamics extensions are being used to monitor different AWS services, a policy with read-only access to all AWS services can be much easier to maintain. For more information on AWS Access Policies, visit Policies and Permissions.

 

How do I limit AWS costs?

 

CloudWatch Pricing

AWS Extensions use the AWS CloudWatch GetMetricsStatistics and ListMetrics API calls. The first 1 million CloudWatch API calls are free, after which the requests are chargeable to your AWS account monthly bill. For more details, please refer to CloudWatch Pricing.

 

Configuring Regions

The extension lists out all the region endpoints, provided by AWS, in the config.yml. For every account listed in the config.yml, there should be a region, or a list of regions, specified in the config. In order to limit AWS Costs, the user should specify only the regions that they would like to monitor.

    # Allowed values: ap-southeast-1, ap-southeast-2, ap-northeast-1, eu-central-1,us-east-1, eu-west-1, us-west-1, us-west-2, sa-east-1
    regions: ["us-west-2", "eu-west-1"]
 

Note: AWS continually adds new regions to their system. Please check and configure your appropriate regions.

 

Configuring Dimensions

The extensions can filter metrics using Dimensions listed for a certain AWS service, thereby reducing the number of API calls. If the user would like to get metrics for all values in a Dimension, they can use a "*" as the value.

 

This example will pull all metrics that have the LoadBalancerName as cs-north or dev-test, from all availability zones.

# Classic (namespace : "AWS/ELB")
# Dimensions : AvailabilityZone, LoadBalancerName
dimensions:
   - name: "LoadBalancerName"
     displayName: "Load Balancer Name"
     values: ["cs-north", "dev-test"]
   - name: "AvailabilityZone"
     displayName: "Availability Zone"
     values: [".*"]

 

Configuring Tags 

The extension can filter metrics based on the tags specified in your AWS environment, further reducing the API Calls. Even though your config.yml is not a mandatory field, please do configure it with the appropriate tags.

 

 

tags:
  - name: "Name"
    value: ["tag1", "tag2", "tag3"]

 

 

CloudWatchMonitoring Level

The extensions can be configured to call AWS CloudWatch APIs at fixed time intervals. There are 2 pre-configured levels: 

  • Basic calls CloudWatch APIs once every 5 min

  • Detailed calls CloudWatch APIs once every 1 min

 

 

cloudWatchMonitoring: "Basic" 
cloudWatchMonitoring: "Advanced"

 

 

If neither of these modes suit your use-case, the extension can be configured to call the APIs at custom intervals. Use the cloudWatchMonitoringInterval field to specify the time interval.

 

For example:

 

cloudWatchMonitoringInterval : 10  #Calls the CloudWatch APIs once every 10 minutes

 

 

AWS Throttling

AWS throttles the amount of data provided by Cloudwatch in a number of ways. Extensions provide options to configure these limits at the client level as well.

 

CloudWatch limits 

CloudWatch places a limit on the number of API requests that can be made. 400 Transactions(or requests) per sec(TPS) is the maximum allowed number of requests that can be made from the extension to the AWS CloudWatch API to get metrics,  per AWS account. For more details, refer to this page

 

This limit can be set in config.yml with the following field:

 

  # Rate limit ( per second ) for GetMetricStatistics, default value is 400
  getMetricStatisticsRateLimit: 400

 

 

Max Error Retry

If any metric returns a 5xx error or 4xx error from Cloudwatch, the extension can be configured to retry the request. The maxErrorRetry field in the config.yml should be configured with the number of retries needed. The extension uses the default exponential back-off strategy between retries.

 

For example,

 

maxErrorRetrySize: 3 # will retry it 3 times

 

 

MetricsTimeRange (startTimeInMinsBeforeNow and endTimeInMinsBeforeNow) and Period

CloudWatch throttles the request if the combination of the start time, end time and period return more than 1440 data points. Please ensure that the combination of metricTimeRange and period gives less than 1440 data points per metric.

 

Every time the extension calls the CloudWatch API, it captures metrics over a time window. This time window can be configured by these tags: 

  • startTimeInMinsBeforeNow 
  • endTimeInMinsBeforeNow.

 

startTimeInMinsBeforeNow denotes time at which the data collection starts. endTimeInMinsBeforeNow denotes the end of the window (this could be the current time if the field is set to zero). 

 

Period denotes the time range over which the metrics are aggregated in CloudWatch.

 

For example, if the startTimeinMinsBeforeNow is 60, endTimeInMinsBeforeNow is 0 and the period is 60 seconds, then the extension collects the data over the last hour, as data points for every 1 min. 

 

Note: AppDynamics AWS extensions have a standard period of 60 seconds. 

The metricsTimeRange and period can be configured either per metric or globally.

 

Metric configuration

 

- name: "QueryRuntimeBreakdown"
 alias: "QueryRuntimeBreakdown (Unit - Milliseconds; StatType - ave)"
 statType: "ave"
 delta: false
 multiplier: 1
 aggregationType: "AVERAGE"
 timeRollUpType: "AVERAGE"
 clusterRollUpType: "INDIVIDUAL"
 metricsTimeRange:
   startTimeInMinsBeforeNow:  9 
   endTimeInMinsBeforeNow: 4

 

 

 

Global configuration

 

metricsTimeRange:
 startTimeInMinsBeforeNow: 9
 endTimeInMinsBeforeNow: 4

 

 

References

AppDynamics Exchange, AWS extensions

Comments
pallavi.patil
New Member

This is a very nice one and gives in-depth information. I am really happy with the quality and presentation of the article. I’d really like to appreciate the efforts you get with writing this post. Thanks for sharing.

Hello Team
Is there a way to run the agent on a docker container or on EKS instead of EC2?

 

Akshay.Srivastava
AppDynamics Team

Hello @Kashinath.Kumbharkar 
The agent can run on a container or EKS. However please note you would need to configure the agent every time the pod is restarted. 

Version history
Last update:
‎04-28-2021 02:54 PM
Updated by:
Join Us On December 10
Learn how Splunk and AppDynamics are redefining observability


Register Now!

Observe and Explore
Dive into our Community Blog for the Latest Insights and Updates!


Read the blog here