CloudWatch DynamoDB

Using CloudWatch for DynamoDB Monitoring

What Is DynamoDB Monitoring?

Amazon DynamoDB is a fully managed NoSQL database service that provides fast and predictable performance with seamless scalability. DynamoDB monitoring refers to the process of monitoring the performance and usage of a DynamoDB database. This includes tracking metrics such as read and write throughput, response time, and error rates, as well as monitoring the usage of resources such as storage space and data transfer. 

Monitoring can be done through Amazon CloudWatch, the AWS Management Console, and third-party monitoring tools. The goal of DynamoDB monitoring is to ensure the database is running efficiently and effectively, and to identify and resolve any issues that may arise.

This is part of a series of articles about serverless debugging

Monitoring DynamoDB with Amazon CloudWatch 

Amazon CloudWatch is a monitoring service provided by Amazon that allows you to monitor various metrics for various AWS resources, including DynamoDB. CloudWatch provides the following monitoring features for DynamoDB:

• Metric monitoring: You can monitor various metrics for DynamoDB, such as read and write throughput, response time, error rates, and storage space usage.
• Alarm monitoring: You can set up alarms to notify you when certain thresholds are exceeded for DynamoDB metrics, such as when read or write throughput exceeds a certain level or when error rates are above a certain threshold.
• Dashboard monitoring: You can create custom dashboards in CloudWatch to view the metrics and alarms for DynamoDB in a single location.
• Log monitoring: You can use CloudWatch to monitor log files generated by DynamoDB. This can be useful for troubleshooting issues with the database or identifying trends in usage patterns.
• Event monitoring: You can use CloudWatch to monitor events related to DynamoDB, such as when a table is created or deleted.

Creating CloudWatch Alarms to Monitor DynamoDB 

To create CloudWatch alarms to monitor capacity in DynamoDB:

1. Sign in to the AWS Management Console and open the CloudWatch console.
2. In the left navigation pane, under Alarms, choose Create alarm.
3. On the Create Alarm page, choose Select Metric.
4. In the Select Metric window, select DynamoDB from the All Metrics tab.
5. From the list of metrics, select ConsumedReadCapacityUnits or ConsumedWriteCapacityUnits.
6. Choose the table that you want to monitor and specify the period for the alarm to watch over the metric data.
7. On the Threshold page, set the threshold for the alarm. For example, you could set the threshold at 80% of your provisioned capacity to receive a notification before you reach your full capacity.
8. On the Actions page, choose New list for the Alarm actions field.
9. Enter a name for the list and choose Create.
10. Select the new list from the Alarm actions dropdown menu.
11. On the Configure actions page, choose Add action, and then select the type of action you want to take when the alarm is triggered. You can choose to receive a notification by email or SMS, or you can choose to execute an AWS Lambda function.
12. On the Additional options page, enter a name and description for the alarm, and then choose Create Alarm.

To create an alarm for system errors in DynamoDB, follow the same steps as above, but select the ThrottledRequests metric and set the threshold at a value of 1 or more. This will trigger the alarm whenever there is a system error in DynamoDB.

How to Use CloudWatch Metrics with DynamoDB 

UserErrors

The UserErrors metric in CloudWatch measures the number of user errors that occurred when interacting with a DynamoDB table. A user error is an error that occurs due to a mistake made by the user, such as attempting to read an item that does not exist in the table. Monitoring this metric can be useful for identifying and troubleshooting issues with user interactions with the DynamoDB table.

SystemErrors

The SystemErrors metric in CloudWatch measures the number of system errors that occurred when interacting with a DynamoDB table. A system error is an error that is not caused by a mistake made by the user, but rather by an issue with the DynamoDB service itself. Monitoring this metric can be useful for identifying and troubleshooting issues with the DynamoDB service.

ConsumedReadCapacityUnits and ConsumedWriteCapacityUnits

The ConsumedReadCapacityUnits metric in CloudWatch measures the number of read capacity units that have been consumed when interacting with a DynamoDB table. Read capacity units are a measure of the number of reads per second that a DynamoDB table can handle.

The ConsumedWriteCapacityUnits metric in CloudWatch measures the number of write capacity units that have been consumed when interacting with a DynamoDB table. Write capacity units are a measure of the number of writes per second that a DynamoDB table can handle.

Monitoring these metrics can be useful for understanding the performance and usage of a DynamoDB table and for identifying potential issues with read and write capacity.

ThrottledRequests

The ThrottledRequests metric in CloudWatch measures the number of requests to a DynamoDB table that were throttled due to exceeding the table’s capacity limits. When a request is throttled, it is not processed and an error is returned to the user.

Monitoring this metric can be useful for identifying when capacity limits are being reached and for determining whether additional capacity is needed to meet demand. It can also be useful for identifying potential issues with the DynamoDB service itself.

Monitoring DynamoDB with Lumigo

Lumigo is a troubleshooting platform purpose-built for microservice-based applications. Developers building serverless apps with services like DynamoDB use Lumigo to monitor, trace and troubleshoot. Deployed with no changes and automated in one-click, Lumigo stitches together every interaction between micro and managed services into end-to-end stack traces, giving complete visibility into serverless environments. Using Lumigo to monitor and troubleshoot their applications, developers get:

• End-to-end virtual stack traces across every micro and managed service that makes up a serverless application, in context
• API visibility that makes all the data passed between services available and accessible, making it possible to perform root cause analysis without digging through logs 
• Distributed tracing that is deployed with no code and automated in one click 
• Unified platform to explore and query across microservices, see a real-time view of applications, and optimize performance

To learn more about monitoring and troubleshooting DynamoDB, read our blog Monitoring AWS DynamoDB performance and latency.