AWS Database Blog

Set up Amazon CloudWatch alarms on Amazon RDS Enhanced Monitoring OS metrics

Monitoring is an important aspect of database management. Database administrators, application teams, and architects want to proactively eradicate performance issues before they affect users or cause an outage. To achieve this, they need the right level of visibility into database health indicators. Amazon Relational Database Service (Amazon RDS) provides monitoring tools, such as Enhanced Monitoring and Performance Insights, that you can use in conjunction with the default Amazon CloudWatch metrics published by RDS.

As a database administrator, you might need to set up alarms on specific informational and critical events related to operating system (OS) metrics. Depending on how serious the events are, you might need to intervene to protect the database from potential performance impact. In this post, we show you how to set up CloudWatch alarms on OS metrics captured through Enhanced Monitoring.

Prerequisites

To follow the steps mentioned in this post, you must have the following prerequisites in place:

  • An AWS account
  • An Amazon RDS for PostgreSQL instance with Enhanced Monitoring turned on
  • An Amazon Elastic Compute Cloud (Amazon EC2) instance with a PSQL client installed to connect to the Amazon RDS for PostgreSQL instance

What is Enhanced Monitoring and what are its benefits?

When you turn on Enhanced Monitoring, Amazon RDS sets up an agent that collects OS-level metrics and stores them in Amazon CloudWatch logs. You can choose an interval as granular as 1 second to collect data, which can be extremely useful when you are investigating database performance issues.

Amazon RDS provides metrics in real time for the OS that your DB instance runs on. It delivers the metrics from Enhanced Monitoring into your Amazon CloudWatch Logs account. You can create metric filters in CloudWatch from CloudWatch Logs and display the graphs on the CloudWatch dashboard.

You can turn on Enhanced Monitoring when you create an instance or by modifying an existing instance. There’s no cost to use Enhanced Monitoring, but the CloudWatch Logs that it generates might incur charges. You pay for CloudWatch Logs storage and PutLogEvents API calls when you exceed the free tier usage. For more details, see the Amazon CloudWatch Pricing page.

By default, Enhanced Monitoring metrics are stored in CloudWatch Logs for 30 days. To modify the amount of time the metrics are stored in the CloudWatch Logs, change the retention for the RDSOSMetrics log group in the CloudWatch console.

How is Enhanced Monitoring different from basic CloudWatch monitoring?

A hypervisor creates and runs virtual machines (VMs). Using a hypervisor, an instance can support multiple guest VMs by virtually sharing memory and CPU. CloudWatch gathers metrics about CPU utilization from the hypervisor for a DB instance. In contrast, Enhanced Monitoring gathers its metrics from an agent on the DB instance.

Enhanced Monitoring metrics are useful when you want to see how different processes or threads on a DB instance use the CPU and other operating system resources. Enhanced Monitoring metrics are collected at an interval defined by the user, which can be between 1 second and 1 minute. Therefore, Enhanced Monitoring metrics can have finer granularity than the standard metrics published to CloudWatch by the RDS service at 1-minute intervals. This can be very useful when troubleshooting performance issues.

Viewing Enhanced Monitoring metrics from the Amazon RDS console

You can view OS metrics reported by Enhanced Monitoring in the Amazon RDS console by choosing Enhanced monitoring under the Monitoring tab.

The Operating System process list helps you view the details for the processes running on your database instance. The Enhanced Monitoring metrics shown in this list are organized as follows: RDS child processes, RDS processes, and OS processes.

Viewing Enhanced Monitoring logs in Amazon CloudWatch Logs

You can review the logs generated by RDS Enhanced Monitoring in your Amazon CloudWatch Logs account.

  1. Check the Amazon RDS instance ID and resource ID from the Amazon RDS console.
    1. Navigate to the Amazon RDS console.
    2. Choose the RDS instance you want to use.
    3. Select the Configuration tab.
  2. Using the previously mentioned resource ID, check the Enhanced Monitoring JSON logs:
    1. Navigate to the CloudWatch console.
    2. Choose Log groups.
    3. Select RDSOSMetrics and select the log stream for which you want to view the logs.

    4. View the JSON logs.

Create a CloudWatch alarm on free memory (Enhanced Monitoring metric)

Enhanced Monitoring provides visibility into OS metrics. To learn more details about what metrics are available, see OS metrics in Enhanced Monitoring. In the following steps, you create a custom CloudWatch metric using the free memory (memory.free) from Enhanced Monitoring and set up an alarm on it.

Free memory refers to the amount of unassigned memory and is measured in kilobytes by default. Unassigned memory is one of the key metrics that DBAs and developers use to measure the performance of their queries. You can read more about the RDS Enhanced Monitoring metrics in OS metrics for MariaDB, MySQL, Oracle, and PostgreSQL.

You might incur some cost by publishing custom metrics to CloudWatch and creating alarms.

Metric filters define the terms and patterns to look for in log data as they are sent to CloudWatch Logs. CloudWatch Logs uses these metric filters to turn log data into numerical CloudWatch metrics that you can graph or set an alarm on.

To create a metric filter:

  1. Open the CloudWatch console.
  2. In the navigation pane, choose Logs, and then choose Log groups.
  3. Select RDSOSMetrics and select the log stream for which you want to view the logs. For this post, it’s db-3EVSZBTZGSPTY4R7PLH6C6YQOE.
  4. Choose Actions and then select Create metric filter.
  5. For Filter pattern, if you enter the filter pattern {$.instanceResourceID!=""}, it selects the metrics of all the Amazon RDS instances.
    Alternatively, you can also choose the filter pattern with the instance ID you want to set up the alarm on. For more information about syntax, see Filter and pattern syntax.
  6. Choose Next, and then enter a name for your metric filter.
  7. Under Metric details, for Metric namespace, enter a name for the CloudWatch namespace where the metric will be published. If the namespace doesn’t already exist, make sure that Create new is selected. For this post, we use RDSCustomMetrics as the namespace.
  8. For Metric name, enter a name for the new metric. For this post, we use FreeMemory.
  9. For Metric Value, choose $.memory.free.

This syntax allows you to retrieve the value of the free key nested in a memory object from an enhanced monitoring JSON log. For this post, we chose the free memory metric. You can choose any other OS metrics as needed for your use case.

  1. [Optional] For Unit, select a unit to assign to the metric. For this post, we selected kilobytes, which is the default unit available for this metric.
  2. Enter the DBInstanceIdentifier and DBInstanceResourceID as dimensions.
  3. Choose Next.

  4. Review and choose Create metric filter.
  5. You can view the metric filter that you created from the navigation pane. Navigate to CloudWatch console, choose Logs, and then choose Log groups. Select RDSOSMetrics and choose the log stream that you created your metric filter for and then select the Metric filters tab.

Set up a CloudWatch alarm on the free memory metric

This section walks you through creating CloudWatch alarms for the RDS OS Enhanced Monitoring metric that was previously created.

  1. Open the CloudWatch console.
  2. In the navigation pane, select Logs and then select Log groups.
  3. Navigate to RDSOSMetrics, select the Metric Filters tab and select the metric name (FreeMemory).
  4. A corresponding namespace named RDSCustomMetrics opens.
    Choose the database instance to set the alarm on.
  5. Select the Graphed metrics tab. Under Actions, choose the alarm symbol.
  6. For Statistic, select Minimum. For Period, select 1 minute from the dropdown.
  7. Under Conditions, specify the following:
    • For Threshold type, choose Static, which allows you to use a specific value as a threshold.
    • Next, we need to choose the alarm condition operator. You can select Lower or Lower/Equal for metrics such as free memory when you want to be notified about a decrease in free memory space.
      • In this case, you want to ensure that free memory stays above a certain threshold, so you should specify Lower as the alarm condition operator.
      • You can specify the threshold to cause the alarm to go to ALARM state if the free memory falls below this value. For this setup, you can set the threshold to 100 MB. That means that if the free memory drops below 100 MB, then the alarm is invoked.

  8. In Configure actions, keep In alarm selected, choose Create/Existing Amazon SNS topic, and enter the topic name and a valid email address. This will send email notifications to the address whenever the alarm is triggered.
  9. Choose Next.

  10. On the Add name and description page, enter an Alarm name and Alarm description. Then choose Next.

In this post, the Alarm name is RDS – postgresrds-FreeMemory < 100MB. You can keep any name of your choice.

  1. Preview the alarm that you’re about to create on the Preview and create page and then choose Create alarm.

For more information on creating alarms, see the CloudWatch Documentation

When free memory for the Amazon RDS instance falls below 100 MB, you will receive an email from AWS Notifications for the CloudWatch alarm similar to the following:


Clean up

When you’re done testing, delete the resources you created for this post:

Summary

In this post, you learned how to view Enhanced Monitoring metrics and set up CloudWatch alarms using metric filters.

Do you have follow-up questions or feedback? Leave a comment. We’d love to hear your thoughts and suggestions.

About the Authors

Sameer Kumar is a Principal Database Specialist TAM at Amazon Web Services. He focuses on Amazon RDS, Amazon Aurora, and Amazon DocumentDB. He works with enterprise customers providing technical assistance on database operational performance and sharing database best practices.

Deepak Sharma is a Database Specialist TAM at Amazon Web Services focusing on Amazon RDS PostgreSQL, RDS Oracle, and Amazon Aurora engines. He works with enterprise customers to provide technical assistance on operational performance, help them run optimized workloads on AWS, and share database best practices.

Nirupam Datta is a Cloud Support DBA at AWS. He has been with AWS for around 3.5 years. With over 11 years of experience in database engineering and infra-architecture, Nirupam is also a subject matter expert in the Amazon RDS core systems and Amazon RDS for SQL Server. He provides technical assistance to customers, guiding them to migrate, optimize, and navigate their journey in the AWS Cloud.

Chaitanya Gummadi is a Sr Cloud Support Engineer at AWS. He’s passionate about helping customers solve their AWS issues in the Networking domain. When not helping customers, he likes to explore different cuisines and go hiking.