Not a customer? Click the 'Start a free trial' link to begin a 30-day SaaS trial of our product and to join our community.
Existing Cisco AppDynamics customers should click the 'Sign In' button to authenticate to access the community
on
08-10-2020
05:10 PM
- edited on
04-28-2021
02:54 PM
by
Claudia.Landiva
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.
AWS extensions can be configured to connect to AWS in several ways.
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>"
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.
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.
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.
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.
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: [".*"]
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"]
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 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 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
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
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 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
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?
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.
Thank you! Your submission has been received!
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form