An exporter for Amazon CloudWatch, for Prometheus. This chart bootstraps a cloudwatch exporter deployment on a Kubernetes cluster using the Helm package manager.

Amazon CloudWatch is a monitoring and management service built for developers, system operators, site reliability engineers (SRE), and IT managers. CloudWatch provides you with data and actionable insights to monitor your applications, understand and respond to system-wide performance changes, optimize resource utilization, and get a unified view of operational health. CloudWatch collects monitoring and operational data in the form of logs, metrics, and events, providing you with a unified view of AWS resources, applications and services that run on AWS, and on-premises servers. You can use CloudWatch to set high resolution alarms, visualize logs and metrics side by side, take automated actions, troubleshoot issues, and discover insights to optimize your applications, and ensure they are running smoothly.

With Amazon CloudWatch, it is easy to get started. There is no up-front commitment or minimum fee; you simply pay for what you use. You will be charged at the end of the month for what you use.

Prerequisites

  • kube2iam installed to used the aws.role config option otherwise configure aws.aws_access_key_id and aws.aws_secret_access_key

Benefits

ACCESS ALL YOUR DATA FROM A SINGLE PLATFORM

Modern applications are distributed (that is, they run on microservices architectures) and generate lots of data in the form of metrics, logs, and more. You need a way to easily collect, access, and correlate these data points from individual sources in silos (server, network, database, etc.) to effectively monitor applications and infrastructure resources. Amazon CloudWatch enables you to collect metrics and logs from all your AWS resources, applications, and services that run on AWS and on-premises servers, helping you break down data silos so you can easily gain system-wide visibility.

RICHEST AND DEEPEST INSIGHTS FOR AWS RESOURCES

Monitoring your AWS resources is easy with Amazon CloudWatch. CloudWatch is natively integrated with more than 70 AWS services such as Amazon EC2, Amazon DynamoDB, Amazon S3, Amazon ECS, AWS Lambda, Amazon API Gateway, etc. that automatically publish detailed 1-minute metrics and custom metrics with up to 1-second granularity. You can use AWS Systems Manager to install a CloudWatch Agent, or you can use the CloudWatch API to easily collect, publish, and store this data in CloudWatch.

VISIBILITY ACROSS YOUR APPLICATIONS, INFRASTRUCTURE, AND SERVICES

Gaining visibility across your distributed stack means correlating and visualizing metrics and logs to quickly pinpoint and resolve issues. With Amazon CloudWatch, you can visualize key metrics like CPU utilization and memory. You can also correlate a log pattern, e.g. error to a specific metric to quickly get the context and go from diagnosing the problem to understanding the root cause.

REDUCE MEAN TIME TO RESOLUTION (MTTR) AND IMPROVE TOTAL COST OF OWNERSHIP (TCO)

Amazon CloudWatch enables you to set high resolution alarms and take automated actions. This means freeing up important resources to focus on adding business value. For example, you can get alerted on Amazon EC2 instances and set up Auto Scaling to add or remove instances. You can also execute automated responses to detect and shut down unused EC2 resources, reducing billing overages and improving resource optimization.

DRIVE INSIGHTS TO OPTIMIZE APPLICATIONS AND OPERATIONAL RESOURCES

You need a unified operational view, real-time granular data, and historical reference to optimize performance and resource utilization. With Amazon CloudWatch, you get enhanced monitoring with 1-second granularity and up to 15 months of metrics storage and retention. You can also leverage native CloudWatch features, such as Metric Math, to perform calculations on your metric data. For example, you can aggregate usage across an entire fleet of EC2 instances to derive operational and utilization insights.

PAY AS YOU GO

With Amazon CloudWatch, there is no up-front commitment or minimum fee; you simply pay for what you use. You will be charged at the end of the month for your usage. To see more details, visit the CloudWatch Pricing page. Estimate your monthly bill using the AWS Simple Monthly Calculator.

CloudWatch has been observed to sometimes take minutes for reported values to converge. The default delay_seconds will result in data that is at least 10 minutes old being requested to mitigate this. The samples exposed will have the timestamps of the data from CloudWatch, so usual staleness semantics will not apply and values will persist for 5m for instant vectors.

In practice this means that if you evaluate an instant vector at the current time, you will not see data from CloudWatch. An expression such as aws_elb_request_count_sum offset 10m will allow you to access the data, and should be used in recording rules and alerts.

For certain metrics which update relatively rarely, such as from S3, set_timestamp should be configured to false so that they are not exposed with a timestamp. This is as the true timestamp from CloudWatch could be so old that Prometheus would reject the sample.

Special handling for certain DynamoDB metrics

The DynamoDB metrics listed below break the usual CloudWatch data model.

  • ConsumedReadCapacityUnits
  • ConsumedWriteCapacityUnits
  • ProvisionedReadCapacityUnits
  • ProvisionedWriteCapacityUnits
  • ReadThrottleEvents
  • WriteThrottleEvents

When these metrics are requested in the TableName dimension CloudWatch will return data only for the table itself, not for its Global Secondary Indexes. Retrieving data for indexes requires requesting data across both the TableName and GlobalSecondaryIndexName dimensions. This behaviour is different to that of every other CloudWatch namespace and requires that the exporter handle these metrics differently to avoid generating duplicate HELP and TYPE lines.

When exporting one of the problematic metrics for an index the exporter will use a metric name in the format aws_dynamodb_METRIC_index_STATISTIC rather than the usual aws_dynamodb_METRIC_STATISTIC. The regular naming scheme will still be used when exporting these metrics for a table, and when exporting any other DynamoDB metrics not listed above.

Tell us about a new Kubernetes application

Newsletter

Never miss a thing! Sign up for our newsletter to stay updated.

About

Discover and learn about everything Kubernetes

Navigation