# Logging and monitoring
Monitoring is an important part of maintaining the reliability, availability, and performance of MemoryDB and your other AWS solutions. AWS provides the following monitoring tools to watch MemoryDB, report when something is wrong, and take automatic actions when appropriate:
+ *Amazon CloudWatch* monitors your AWS resources and the applications you run on AWS in real time. You can collect and track metrics, create customized dashboards, and set alarms that notify you or take actions when a specified metric reaches a threshold that you specify. For example, you can have CloudWatch track CPU usage or other metrics of your Amazon EC2 instances and automatically launch new instances when needed. For more information, see the [Amazon CloudWatch User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
+ *Amazon CloudWatch Logs* enables you to monitor, store, and access your log files from Amazon EC2 instances, CloudTrail, and other sources. CloudWatch Logs can monitor information in the log files and notify you when certain thresholds are met. You can also archive your log data in highly durable storage. For more information, see the [Amazon CloudWatch Logs User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/).
+ *AWS CloudTrail* captures API calls and related events made by or on behalf of your AWS account and delivers the log files to an Amazon S3 bucket that you specify. You can identify which users and accounts called AWS, the source IP address from which the calls were made, and when the calls occurred. For more information, see the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
# Monitoring MemoryDB with Amazon CloudWatch
You can monitor MemoryDB using CloudWatch, which collects raw data and processes it into readable, near real-time metrics. These statistics are kept for 15 months, so that you can access historical information and gain a better perspective on how your web application or service is performing. You can also set alarms that watch for certain thresholds, and send notifications or take actions when those thresholds are met. For more information, see the [Amazon CloudWatch User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
The following sections list the metrics and dimensions for MemoryDB.
**Topics**
+ [
# Host-Level Metrics
](metrics.HostLevel.md)
+ [
# Metrics for MemoryDB
](metrics.memorydb.md)
+ [
# Which Metrics Should I Monitor?
](metrics.whichshouldimonitor.md)
+ [
# Choosing Metric Statistics and Periods
](metrics.ChoosingStatisticsAndPeriods.md)
+ [
# Monitoring CloudWatch metrics
](cloudwatchmetrics.md)
# Host-Level Metrics
The `AWS/MemoryDB` namespace includes the following host-level metrics for individual nodes.
**See Also**
+ [Metrics for MemoryDB](metrics.memorydb.md)
| Metric | Description | Unit |
| --- | --- | --- |
| CPUUtilization | The percentage of CPU utilization for the entire host. Because Valkey and Redis OSS are single-threaded, we recommend you monitor EngineCPUUtilization metric for nodes with 4 or more vCPUs. | Percent |
| FreeableMemory | The amount of free memory available on the host. This number is derived from the memory in RAM and buffers that the OS reports as freeable. | Bytes |
| NetworkBytesIn | The number of bytes the host has read from the network. | Bytes |
| NetworkBytesOut | The number of bytes sent out on all network interfaces by the instance. | Bytes |
| NetworkPacketsIn | The number of packets received on all network interfaces by the instance. This metric identifies the volume of incoming traffic in terms of the number of packets on a single instance. | Count |
| NetworkPacketsOut | The number of packets sent out on all network interfaces by the instance. This metric identifies the volume of outgoing traffic in terms of the number of packets on a single instance. | Count |
| NetworkBandwidthInAllowanceExceeded | The number of packets shaped because the inbound aggregate bandwidth exceeded the maximum for the instance. | Count |
| NetworkConntrackAllowanceExceeded | The number of packets shaped because connection tracking exceeded the maximum for the instance and new connections could not be established. This can result in packet loss for traffic to or from the instance. | Count |
| NetworkBandwidthOutAllowanceExceeded | The number of packets shaped because the outbound aggregate bandwidth exceeded the maximum for the instance. | Count |
| NetworkPacketsPerSecondAllowanceExceeded | The number of packets shaped because the bidirectional packets per second exceeded the maximum for the instance. | Count |
| NetworkMaxBytesIn | The maximum per second burst of received bytes within each minute. | Bytes |
| NetworkMaxBytesOut | The maximum per second burst of transmitted bytes within each minute. | Bytes |
| NetworkMaxPacketsIn | The maximum per second burst of received packets within each minute. | Count |
| NetworkMaxPacketsOut | The maximum per second burst of transmitted packets within each minute. | Count |
| SwapUsage | The amount of swap used on the host. | Bytes |
# Metrics for MemoryDB
The `AWS/MemoryDB` namespace includes the following metrics.
With the exception of `ReplicationLag`, `EngineCPUUtilization`, `SuccessfulWriteRequestLatency`, and `SuccessfulReadRequestLatency`, these metrics are derived from the Valkey and Redis OSS **info** command. Each metric is calculated at the node level.
For complete documentation of the **INFO** command, see [INFO](http://valkey.io/commands/info).
**See also:**
+ [Host-Level Metrics](metrics.HostLevel.md)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html)
The following are aggregations of certain kinds of commands, derived from **info commandstats**. The commandstats section provides statistics based on the command type, including the number of calls.
For a full list of available commands, see [commands](https://valkey.io/commands).
| Metric | Description | Unit |
| --- | --- | --- |
| EvalBasedCmds | The total number of commands for eval-based commands. This is derived from the commandstats statistic by summing eval and evalsha. | Count |
| GeoSpatialBasedCmds | The total number of commands for geospatial-based commands. This is derived from the commandstats statistic. It's derived by summing all of the geo type of commands: geoadd, geodist, geohash, geopos, georadius, and georadiusbymember. | Count |
| GetTypeCmds | The total number of read-only type commands. This is derived from the commandstats statistic by summing all of the read-only type commands (get, hget, scard, lrange, and so on.) | Count |
| HashBasedCmds | The total number of commands that are hash-based. This is derived from the commandstats statistic by summing all of the commands that act upon one or more hashes (hget, hkeys, hvals, hdel, and so on). | Count |
| HyperLogLogBasedCmds | The total number of HyperLogLog-based commands. This is derived from the commandstats statistic by summing all of the pf type of commands (pfadd, pfcount, pfmerge, and so on.). | Count |
| JsonBasedCmds | The total number of commands that are JSON-based. This is derived from the commandstats statistic by summing all of the commands that act upon one or more JSON document objects. | Count |
| KeyBasedCmds | The total number of commands that are key-based. This is derived from the commandstats statistic by summing all of the commands that act upon one or more keys across multiple data structures (del, expire, rename, and so on.). | Count |
| ListBasedCmds | The total number of commands that are list-based. This is derived from the commandstats statistic by summing all of the commands that act upon one or more lists (lindex, lrange, lpush, ltrim, and so on). | Count |
| PubSubBasedCmds | The total number of commands for pub/sub functionality. This is derived from the commandstats statistics by summing all of the commands used for pub/sub functionality: psubscribe, publish, pubsub, punsubscribe, subscribe, and unsubscribe. | Count |
| SearchBasedCmds | The total number of secondary index and search commands, including both read and write commands. This is derived from the commandstats statistic by summing all search commands that act upon secondary indexes. | Count |
| SearchBasedGetCmds | Total number of secondary index and search read-only commands. This is derived from the commandstats statistic by summing all secondary index and search get commands. | Count |
| SearchBasedSetCmds | Total number of secondary index and search write commands. This is derived from the commandstats statistic by summing all secondary index and search set commands. | Count |
| SearchNumberOfIndexes | Total number of indexes. | Count |
| SearchNumberOfIndexedKeys | Total number of indexed keys | Count |
| SearchTotalIndexSize | Memory (bytes) used by all the indexes. | Bytes |
| SetBasedCmds | The total number of commands that are set-based. This is derived from the commandstats statistic by summing all of the commands that act upon one or more sets (scard, sdiff, sadd, sunion, and so on). | Count |
| SetTypeCmds | The total number of write types of commands. This is derived from the commandstats statistic by summing all of the mutative types of commands that operate on data (set, hset, sadd, lpop, and so on.) | Count |
| SortedSetBasedCmds | The total number of commands that are sorted set-based. This is derived from the commandstats statistic by summing all of the commands that act upon one or more sorted sets (zcount, zrange, zrank, zadd, and so on). | Count |
| StringBasedCmds | The total number of commands that are string-based. This is derived from the commandstats statistic by summing all of the commands that act upon one or more strings (strlen, setex, setrange, and so on). | Count |
| StreamBasedCmds | The total number of commands that are stream-based. This is derived from the commandstats statistic by summing all of the commands that act upon one or more streams data types (xrange, xlen, xadd, xdel, and so on). | Count |
# Which Metrics Should I Monitor?
The following CloudWatch metrics offer good insight into MemoryDB performance. In most cases, we recommend that you set CloudWatch alarms for these metrics so that you can take corrective action before performance issues occur.
**Topics**
+ [
## CPUUtilization
](#metrics-cpu-utilization)
+ [
## EngineCPUUtilization
](#metrics-engine-cpu-utilization)
+ [
## SwapUsage
](#metrics-swap-usage)
+ [
## Evictions
](#metrics-evictions)
+ [
## CurrConnections
](#metrics-curr-connections)
+ [
## Memory
](#metrics-memory)
+ [
## Network
](#metrics-network)
+ [
## Latency
](#metrics-latency)
+ [
## Replication
](#metrics-replication)
## CPUUtilization
This is a host-level metric reported as a percentage. For more information, see [Host-Level Metrics](metrics.HostLevel.md).
For smaller node types with 2vCPUs or less, use the `CPUUtilization ` metric to monitor your workload.
Generally speaking, we suggest you set your threshold at 90% of your available CPU. Because Valkey and Redis OSS are single-threaded, the actual threshold value should be calculated as a fraction of the node's total capacity. For example, suppose you are using a node type that has two cores. In this case, the threshold for CPUUtilization would be 90/2, or 45%. To find the number of cores (vCPUs) your node type has, see [MemoryDB Pricing](https://aws.amazon.com/memorydb/pricing/?p=ps).
You will need to determine your own threshold, based on the number of cores in the node that you are using. If you exceed this threshold, and your main workload is from read requests, scale your cluster out by adding read replicas. If the main workload is from write requests, we recommend that you add more shards to distribute the write workload across more primary nodes.
**Tip**
Instead of using the Host-Level metric `CPUUtilization`, you might be able to use the metric `EngineCPUUtilization`, which reports the percentage of usage on the Valkey or Redis OSS engine core. To see if this metric is available on your nodes and for more information, see [Metrics for MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).
For larger node types with 4vCPUs or more, you may want to use the `EngineCPUUtilization` metric, which reports the percentage of usage on the Valkey or Redis OSS engine core. To see if this metric is available on your nodes and for more information, see [Metrics for MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).
## EngineCPUUtilization
For larger node types with 4vCPUs or more, you may want to use the `EngineCPUUtilization` metric, which reports the percentage of usage on the Valkey or Redis OSS engine core. To see if this metric is available on your nodes and for more information, see [Metrics for MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).
## SwapUsage
This is a host-level metric reported in bytes. For more information, see [Host-Level Metrics](metrics.HostLevel.md).
If either the `FreeableMemory` CloudWatch metric is close to 0 (i.e., below 100MB), or the `SwapUsage` metric is greater than the `FreeableMemory` metric, then a node could be under memory pressure.
## Evictions
This is a engine metric. We recommend that you determine your own alarm threshold for this metric based on your application needs.
## CurrConnections
This is a engine metric. We recommend that you determine your own alarm threshold for this metric based on your application needs.
An increasing number of *CurrConnections* might indicate a problem with your application; you will need to investigate the application behavior to address this issue.
## Memory
Memory is a core aspect of Valkey and of Redis OSS. Understanding the memory utilization of your cluster is necessary to avoid data loss and accommodate future growth of your dataset. Statistics about the memory utilization of a node are available in the memory section of the [INFO](https://valkey.io/commands/info) command.
## Network
One of the determining factors for the network bandwidth capacity of your cluster is the node type you have selected. For more information about the network capacity of your node, see [Amazon MemoryDB pricing](https://aws.amazon.com/memorydb/pricing/).
## Latency
The latency metrics `SuccessfulWriteRequestLatency` and `SuccessfulReadRequestLatency` measure the total time that MemoryDB for the Valkey engine takes to respond to a request.
**Note**
Inflated values for `SuccessfulWriteRequestLatency` and `SuccessfulReadRequestLatency` metrics may occur when using Valkey pipelining with CLIENT REPLY enabled on the Valkey client. Valkey pipelining is a technique for improving performance by issuing multiple commands at once, without waiting for the response to each individual command. To avoid inflated values, we recommend configuring your Redis client to pipeline commands with [CLIENT REPLY OFF](https://valkey.io/commands/client-reply/).
## Replication
The volume of data being replicated is visible via the `ReplicationBytes` metric. You can monitor `MaxReplicationThroughput` against the replication capacity throughput. It is recommended to add more shards when reaching the maximum replication capacity throughput.
`ReplicationDelayedWriteCommands` can also indicate if the workload is exceeding the maximum replication capacity throughput. For more information about replication in MemoryDB, see [Understanding MemoryDB replication](https://docs.aws.amazon.com/memorydb/latest/devguide/replication.html)
# Choosing Metric Statistics and Periods
While CloudWatch will allow you to choose any statistic and period for each metric, not all combinations will be useful. For example, the Average, Minimum, and Maximum statistics for CPUUtilization are useful, but the Sum statistic is not.
All MemoryDB samples are published for a 60 second duration for each individual node. For any 60 second period, a node metric will only contain a single sample.
# Monitoring CloudWatch metrics
MemoryDB and CloudWatch are integrated so you can gather a variety of metrics. You can monitor these metrics using CloudWatch.
**Note**
The following examples require the CloudWatch command line tools. For more information about CloudWatch and to download the developer tools, see the [ CloudWatch product page](https://aws.amazon.com/cloudwatch).
The following procedures show you how to use CloudWatch to gather storage space statistics for an cluster for the past hour.
**Note**
The `StartTime` and `EndTime` values supplied in the examples following are for illustrative purposes. Make sure to substitute appropriate start and end time values for your nodes.
For information on MemoryDB limits, see [AWS service limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_memorydb) for MemoryDB.
## Monitoring CloudWatch metrics (Console)
**To gather CPU utilization statistics for a cluster**
1. Sign in to the AWS Management Console and open the MemoryDB console at [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/).
1. Select the nodes you want to view metrics for.
**Note**
Selecting more than 20 nodes disables viewing metrics on the console.
1. On the ** Clusters** page of the AWS Management Console, click the name of one or more clusters.
The detail page for the cluster appears.
1. Click the **Nodes** tab at the top of the window.
1. On the **Nodes** tab of the detail window, select the nodes that you want to view metrics for.
A list of available CloudWatch Metrics appears at the bottom of the console window.
1. Click on the **CPU Utilization** metric.
The CloudWatch console will open, displaying your selected metrics. You can use the **Statistic** and **Period** drop-down list boxes and **Time Range** tab to change the metrics being displayed.
## Monitoring CloudWatch metrics using the CloudWatch CLI
**To gather CPU utilization statistics for a cluster**
+ Use the CloudWatch command **aws cloudwatch get-metric-statistics** with the following parameters (note that the start and end times are shown as examples only; you will need to substitute your own appropriate start and end times):
For Linux, macOS, or Unix:
```
1. aws cloudwatch get-metric-statistics CPUUtilization \
2. --dimensions=ClusterName=mycluster,NodeId=0002" \
3. --statistics=Average \
4. --namespace="AWS/MemoryDB" \
5. --start-time 2013-07-05T00:00:00 \
6. --end-time 2013-07-06T00:00:00 \
7. --period=60
```
For Windows:
```
1. mon-get-stats CPUUtilization ^
2. --dimensions=ClusterName=mycluster,NodeId=0002" ^
3. --statistics=Average ^
4. --namespace="AWS/MemoryDB" ^
5. --start-time 2013-07-05T00:00:00 ^
6. --end-time 2013-07-06T00:00:00 ^
7. --period=60
```
## Monitoring CloudWatch metrics using the CloudWatch API
**To gather CPU utilization statistics for a cluster**
+ Call the CloudWatch API `GetMetricStatistics` with the following parameters (note that the start and end times are shown as examples only; you will need to substitute your own appropriate start and end times):
+ `Statistics.member.1``=Average`
+ `Namespace``=AWS/MemoryDB`
+ `StartTime``=2013-07-05T00:00:00`
+ `EndTime``=2013-07-06T00:00:00`
+ `Period``=60`
+ `MeasureName``=CPUUtilization`
+ `Dimensions``=ClusterName=mycluster,NodeId=0002`
**Example**
```
1. http://monitoring.amazonaws.com/
2. ?SignatureVersion=4
3. &Action=GetMetricStatistics
4. &Version=2014-12-01
5. &StartTime=2013-07-16T00:00:00
6. &EndTime=2013-07-16T00:02:00
7. &Period=60
8. &Statistics.member.1=Average
9. &Dimensions.member.1="ClusterName=mycluster"
10. &Dimensions.member.2="NodeId=0002"
11. &Namespace=Amazon/memorydb
12. &MeasureName=CPUUtilization
13. &Timestamp=2013-07-07T17%3A48%3A21.746Z
14. &AWS;AccessKeyId=<&AWS; Access Key ID>
15. &Signature=
```
# Monitoring MemoryDB events
When significant events happen for a cluster, MemoryDB sends notification to a specific Amazon SNS topic. Examples include a failure to add a node, success in adding a node, the modification of a security group, and others. By monitoring for key events, you can know the current state of your clusters and, depending upon the event, be able to take corrective action.
**Topics**
+ [
# Managing MemoryDB Amazon SNS notifications
](mdbevents.sns.md)
+ [
# Viewing MemoryDB events
](mdbevents.viewing.md)
+ [
# Event Notifications and Amazon SNS
](memorydbsns.md)
# Managing MemoryDB Amazon SNS notifications
You can configure MemoryDB to send notifications for important cluster events using Amazon Simple Notification Service (Amazon SNS). In these examples, you will configure a cluster with the Amazon Resource Name (ARN) of an Amazon SNS topic to receive notifications.
**Note**
This topic assumes that you've signed up for Amazon SNS and have set up and subscribed to an Amazon SNS topic. For information on how to do this, see the [Amazon Simple Notification Service Developer Guide](https://docs.aws.amazon.com/sns/latest/dg/).
## Adding an Amazon SNS topic
The following sections show you how to add an Amazon SNS topic using the AWS Console, the AWS CLI, or the MemoryDB API.
### Adding an Amazon SNS topic (Console)
The following procedure shows you how to add an Amazon SNS topic for a cluster.
**Note**
This process can also be used to modify the Amazon SNS topic.
**To add or modify an Amazon SNS topic for a cluster (Console)**
1. Sign in to the AWS Management Console and open the MemoryDB console at [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/).
1. In ** Clusters**, choose the cluster for which you want to add or modify an Amazon SNS topic ARN.
1. Choose **Modify**.
1. In **Modify Cluster** under **Topic for SNS Notification**, choose the SNS topic you want to add, or choose **Manual ARN input** and type the ARN of the Amazon SNS topic.
1. Choose **Modify**.
### Adding an Amazon SNS topic (AWS CLI)
To add or modify an Amazon SNS topic for a cluster, use the AWS CLI command `update-cluster`.
The following code example adds an Amazon SNS topic arn to *my-cluster*.
For Linux, macOS, or Unix:
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--sns-topic-arn arn:aws:sns:us-east-1:565419523791:memorydbNotifications
```
For Windows:
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--sns-topic-arn arn:aws:sns:us-east-1:565419523791:memorydbNotifications
```
For more information, see [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html) .
### Adding an Amazon SNS topic (MemoryDB API)
To add or update an Amazon SNS topic for a cluster, call the `UpdateCluster` action with the following parameters:
+ `ClusterName``=my-cluster`
+ `SnsTopicArn``=arn%3Aaws%3Asns%3Aus-east-1%3A565419523791%3AmemorydbNotifications`
To add or update an Amazon SNS topic for a cluster, call the `UpdateCluster` action.
For more information, see [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html).
## Enabling and disabling Amazon SNS notifications
You can turn notifications on or off for a cluster. The following procedures show you how to disable Amazon SNS notifications.
### Enabling and disabling Amazon SNS notifications (Console)
**To disable Amazon SNS notifications using the AWS Management Console**
1. Sign in to the AWS Management Console and open the MemoryDB console at [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/).
1. Choose the radio button to the left of the cluster you want to modify notification for.
1. Choose **Modify**.
1. In **Modify Cluster** under **Topic for SNS Notification**, choose *Disable Notifications*.
1. Choose **Modify**.
### Enabling and disabling Amazon SNS notifications (AWS CLI)
To disable Amazon SNS notifications, use the command `update-cluster` with the following parameters:
For Linux, macOS, or Unix:
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--sns-topic-status inactive
```
For Windows:
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--sns-topic-status inactive
```
### Enabling and disabling Amazon SNS notifications (MemoryDB API)
To disable Amazon SNS notifications, call the `UpdateCluster` action with the following parameters:
+ `ClusterName``=my-cluster`
+ `SnsTopicStatus``=inactive`
This call returns output similar to the following:
**Example**
```
1. https://memory-db.us-east-1.amazonaws.com/
2. ?Action=UpdateCluster
3. &ClusterName=my-cluster
4. &SnsTopicStatus=inactive
5. &Version=2021-01-01
6. &SignatureVersion=4
7. &SignatureMethod=HmacSHA256
8. &Timestamp=20210801T220302Z
9. &X-Amz-Algorithm=Amazon4-HMAC-SHA256
10. &X-Amz-Date=20210801T220302Z
11. &X-Amz-SignedHeaders=Host
12. &X-Amz-Expires=20210801T220302Z
13. &X-Amz-Credential=
14. &X-Amz-Signature=
```
# Viewing MemoryDB events
MemoryDB logs events that relate to your clusters, security groups, and parameter groups. This information includes the date and time of the event, the source name and source type of the event, and a description of the event. You can easily retrieve events from the log using the MemoryDB console, the AWS CLI `describe-events` command, or the MemoryDB API action `DescribeEvents`.
The following procedures show you how to view all MemoryDB events for the past 24 hours (1440 minutes).
## Viewing MemoryDB events (Console)
The following procedure displays events using the MemoryDB console.
**To view events using the MemoryDB console**
1. Sign in to the AWS Management Console and open the MemoryDB console at [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/).
1. In the left navigation pane, choose **Events**.
The *Events* screen appears listing all available events. Each row of the list represents one event and displays the event source, the event type (such as cluster, parameter-group, acl, security-group or subnet group), the GMT time of the event, and the description of the event.
Using the **Filter** you can specify whether you want to see all events, or just events of a specific type in the event list.
## Viewing MemoryDB events (AWS CLI)
To generate a list of MemoryDB events using the AWS CLI, use the command `describe-events`. You can use optional parameters to control the type of events listed, the time frame of the events listed, the maximum number of events to list, and more.
The following code lists up to 40 cluster events.
```
aws memorydb describe-events --source-type cluster --max-results 40
```
The following code lists all events for the past 24 hours (1440 minutes).
```
aws memorydb describe-events --duration 1440
```
The output from the `describe-events` command looks something like this.
```
{
"Events": [
{
"Date": "2021-03-29T22:17:37.781Z",
"Message": "Added node 0001 in Availability Zone us-east-1a",
"SourceName": "memorydb01",
"SourceType": "cluster"
},
{
"Date": "2021-03-29T22:17:37.769Z",
"Message": "cluster created",
"SourceName": "memorydb01",
"SourceType": "cluster"
}
]
}
```
For more information, such as available parameters and permitted parameter values, see [https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-events.html](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-events.html).
## Viewing MemoryDB events (MemoryDB API)
To generate a list of MemoryDB events using the MemoryDB API, use the `DescribeEvents` action. You can use optional parameters to control the type of events listed, the time frame of the events listed, the maximum number of events to list, and more.
The following code lists the 40 most recent -cluster events.
```
https://memory-db.us-east-1.amazonaws.com/
?Action=DescribeEvents
&MaxResults=40
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&SourceType=cluster
&Timestamp=20210802T192317Z
&Version=2021-01-01
&X-Amz-Credential=
```
The following code lists the cluster events for the past 24 hours (1440 minutes).
```
https://memory-db.us-east-1.amazonaws.com/
?Action=DescribeEvents
&Duration=1440
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&SourceType=cluster
&Timestamp=20210802T192317Z
&Version=2021-01-01
&X-Amz-Credential=
```
The above actions should produce output similar to the following.
```
cluster created
cluster
2021-08-02T18:22:18.202Z
my-memorydb-primary
(...output omitted...)
e21c81b4-b9cd-11e3-8a16-7978bb24ffdf
```
For more information, such as available parameters and permitted parameter values, see [https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html).
# Event Notifications and Amazon SNS
MemoryDB can publish messages using Amazon Simple Notification Service (SNS) when significant events happen on a cluster. This feature can be used to refresh the server-lists on client machines connected to individual node endpoints of a cluster.
**Note**
For more information on Amazon Simple Notification Service (SNS), including information on pricing and links to the Amazon SNS documentation, see the [Amazon SNS product page](https://aws.amazon.com/sns).
Notifications are published to a specified Amazon SNS *topic*. The following are requirements for notifications:
+ Only one topic can be configured for MemoryDB notifications.
+ The AWS account that owns the Amazon SNS topic must be the same account that owns the cluster on which notifications are enabled.
## MemoryDB Events
The following MemoryDB events trigger Amazon SNS notifications:
| Event Name | Message | Description |
| --- | --- | --- |
| MemoryDB:AddNodeComplete | "Modified number of nodes from %d to %d" | A node has been added to the cluster and is ready for use. |
| MemoryDB:AddNodeFailed due to insufficient free IP addresses | "Failed to modify number of nodes from %d to %d due to insufficient free IP addresses" | A node could not be added because there are not enough available IP addresses. |
| MemoryDB:ClusterParametersChanged | "Updated parameter group for the cluster" In case of create, also send `"Updated to use a ParameterGroup %s"` | One or more cluster parameters have been changed. |
| MemoryDB:ClusterProvisioningComplete | "Cluster created." | The provisioning of a cluster is completed, and the nodes in the cluster are ready to use. |
| MemoryDB:ClusterProvisioningFailed due to incompatible network state | "Failed to create cluster due to incompatible network state. %s" | An attempt was made to launch a new cluster into a nonexistent virtual private cloud (VPC). |
| MemoryDB:ClusterRestoreFailed | "Restore from %s failed for node %s. %s" | MemoryDB was unable to populate the cluster with snapshot data. This could be due to a nonexistent snapshot file in Amazon S3, or incorrect permissions on that file. If you describe the cluster, the status will be `restore-failed`. You will need to delete the cluster and start over. For more information, see [Seeding a new cluster with an externally created snapshot](snapshots-seeding-redis.md). |
| MemoryDB:ClusterScalingComplete | `"Succeeded applying modification to node type to %s."` | Scale up for cluster completed successfully. |
| MemoryDB:ClusterScalingFailed | `"Failed applying modification to node type to %s."` | Scale-up operation on cluster failed. |
| MemoryDB:NodeReplaceStarted | "Recovering node %s" | MemoryDB has detected that the host running a node is degraded or unreachable and has started replacing the node. The DNS entry for the replaced node is not changed. In most instances, you do not need to refresh the server-list for your clients when this event occurs. However, some client libraries may stop using the node even after MemoryDB has replaced the node; in this case, the application should refresh the server-list when this event occurs. |
| MemoryDB:NodeReplaceComplete | "Finished recovery for node %s" | MemoryDB has detected that the host running a node is degraded or unreachable and has completed replacing the node. The DNS entry for the replaced node is not changed. In most instances, you do not need to refresh the server-list for your clients when this event occurs. However, some client libraries may stop using the node even after MemoryDB has replaced the node; in this case, the application should refresh the server-list when this event occurs. |
| MemoryDB:CreateClusterComplete | "Cluster created" | The cluster was successfully created. |
| MemoryDB:CreateClusterFailed | "Failed to create cluster due to unsuccessful creation of its node(s)." and "Deleting all nodes belonging to this cluster." | The cluster was not created. |
| MemoryDB:DeleteClusterComplete | "Cluster deleted." | The deletion of a cluster and all associated nodes has completed. |
| MemoryDB:FailoverComplete | `"Failover to replica node %s completed"` | Failover over to a replica node was successful. |
| MemoryDB:NodeReplacementCanceled | "The replacement of node %s which was scheduled during the maintenance window from start time: %s, end time: %s has been canceled" | A node in your cluster that was scheduled for replacement is no longer scheduled for replacement. |
| MemoryDB:NodeReplacementRescheduled | "The replacement in maintenance window for node %s has been re-scheduled from previous start time: %s, previous end time: %s to new start time: %s, new end time: %s" | A node in your cluster previously scheduled for replacement has been rescheduled for replacement during the new window described in the notification. For information on what actions you can take, see [Replacing nodes](nodes.nodereplacement.md). |
| MemoryDB:NodeReplacementScheduled | "The node %s is scheduled for replacement during the maintenance window from start time: %s to end time: %s" | A node in your cluster is scheduled for replacement during the window described in the notification. For information on what actions you can take, see [Replacing nodes](nodes.nodereplacement.md). |
| MemoryDB:RemoveNodeComplete | "Removed node %s" | A node has been removed from the cluster. |
| MemoryDB:SnapshotComplete | "Snapshot %s succeeded for node %s" | A snapshot has completed successfully. |
| MemoryDB:SnapshotFailed | "Snapshot %s failed for node %s" | A snapshot has failed. See the cluster’s events for more a detailed cause. If you describe the snapshot, see [DescribeSnapshots](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeSnapshots.html), the status will be `failed`. |
# Logging MemoryDB API calls with AWS CloudTrail
MemoryDB is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in MemoryDB. CloudTrail captures all API calls for MemoryDB as events, including calls from the MemoryDB console and from code calls to the MemoryDB API operations. If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket, including events for MemoryDB. If you don't configure a trail, you can still view the most recent events in the CloudTrail console in **Event history**. Using the information collected by CloudTrail, you can determine the request that was made to MemoryDB, the IP address from which the request was made, who made the request, when it was made, and additional details.
To learn more about CloudTrail, see the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
## MemoryDB information in CloudTrail
CloudTrail is enabled on your AWS account when you create the account. When activity occurs in MemoryDB, that activity is recorded in a CloudTrail event along with other AWS service events in **Event history**. You can view, search, and download recent events in your AWS account. For more information, see [Viewing Events with CloudTrail Event History](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
For an ongoing record of events in your AWS account, including events for MemoryDB, create a trail. A trail enables CloudTrail to deliver log files to an Amazon S3 bucket. By default, when you create a trail in the console, the trail applies to all regions. The trail logs events from all regions in the AWS partition and delivers the log files to the Amazon S3 bucket that you specify. Additionally, you can configure other AWS services to further analyze and act upon the event data collected in CloudTrail logs. For more information, see the following:
+ [Overview for Creating a Trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail Supported Services and Integrations](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [Configuring Amazon SNS Notifications for CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [Receiving CloudTrail Log Files from Multiple Regions](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) and [Receiving CloudTrail Log Files from Multiple Accounts](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
All MemoryDB actions are logged by CloudTrail. For example, calls to the `CreateCluster`, `DescribeClusters` and `UpdateCluster` actions generate entries in the CloudTrail log files.
Every event or log entry contains information about who generated the request. The identity information helps you determine the following:
+ Whether the request was made with root or IAM user credentials.
+ Whether the request was made with temporary security credentials for a role or federated user.
+ Whether the request was made by another AWS service.
For more information, see the [CloudTrail userIdentity Element](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).
## Understanding MemoryDB log file entries
A trail is a configuration that enables delivery of events as log files to an Amazon S3 bucket that you specify. CloudTrail log files contain one or more log entries. An event represents a single request from any source and includes information about the requested action, the date and time of the action, request parameters, and so on. CloudTrail log files are not an ordered stack trace of the public API calls, so they do not appear in any specific order.
The following example shows a CloudTrail log entry that demonstrates the `CreateCluster` action.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T17:56:46Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "CreateCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.create-cluster",
"requestParameters": {
"clusterName": "memorydb-cluster",
"nodeType": "db.r6g.large",
"subnetGroupName": "memorydb-subnet-group",
"aCLName": "open-access"
},
"responseElements": {
"cluster": {
"name": "memorydb-cluster",
"status": "creating",
"numberOfShards": 1,
"availabilityMode": "MultiAZ",
"clusterEndpoint": {
"port": 6379
},
"nodeType": "db.r6g.large",
"engineVersion": "6.2",
"enginePatchVersion": "6.2.6",
"parameterGroupName": "default.memorydb-redis6",
"parameterGroupStatus": "in-sync",
"subnetGroupName": "memorydb-subnet-group",
"tLSEnabled": true,
"aRN": "arn:aws:memorydb:us-east-1:123456789012:cluster/memorydb-cluster",
"snapshotRetentionLimit": 0,
"maintenanceWindow": "tue:06:30-tue:07:30",
"snapshotWindow": "09:00-10:00",
"aCLName": "open-access",
"dataTiering": "false",
"autoMinorVersionUpgrade": true
}
},
"requestID": "506fc951-9ae2-42bb-872c-98028dc8ed11",
"eventID": "2ecf3dc3-c931-4df0-a2b3-be90b596697e",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
The following example shows a CloudTrail log entry that demonstrates the `DescribeClusters` action. Note that for all MemoryDB Describe and List calls (`Describe*` and `List*`), the `responseElements` section is removed and appears as `null`.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T18:39:51Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "DescribeClusters",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.describe-clusters",
"requestParameters": {
"maxResults": 50,
"showShardDetails": true
},
"responseElements": null,
"requestID": "5e831993-52bb-494d-9bba-338a117c2389",
"eventID": "32a3dc0a-31c8-4218-b889-1a6310b7dd50",
"readOnly": true,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
The following example shows a CloudTrail log entry that records an `UpdateCluster` action.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T19:23:20Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "UpdateCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.update-cluster",
"requestParameters": {
"clusterName": "memorydb-cluster",
"snapshotWindow": "04:00-05:00",
"shardConfiguration": {
"shardCount": 2
}
},
"responseElements": {
"cluster": {
"name": "memorydb-cluster",
"status": "updating",
"numberOfShards": 2,
"availabilityMode": "MultiAZ",
"clusterEndpoint": {
"address": "clustercfg.memorydb-cluster.cde8da.memorydb.us-east-1.amazonaws.com",
"port": 6379
},
"nodeType": "db.r6g.large",
"engineVersion": "6.2",
"EnginePatchVersion": "6.2.6",
"parameterGroupName": "default.memorydb-redis6",
"parameterGroupStatus": "in-sync",
"subnetGroupName": "memorydb-subnet-group",
"tLSEnabled": true,
"aRN": "arn:aws:memorydb:us-east-1:123456789012:cluster/memorydb-cluster",
"snapshotRetentionLimit": 0,
"maintenanceWindow": "tue:06:30-tue:07:30",
"snapshotWindow": "04:00-05:00",
"autoMinorVersionUpgrade": true,
"DataTiering": "false"
}
},
"requestID": "dad021ce-d161-4365-8085-574133afab54",
"eventID": "e0120f85-ab7e-4ad4-ae78-43ba15dee3d8",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
The following example shows a CloudTrail log entry that demonstrates the `CreateUser` action. Note that for MemoryDB calls that contain sensitive data, that data will be redacted in the corresponding CloudTrail event as shown in the `requestParameters` section below.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T19:56:13Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "CreateUser",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.create-user",
"requestParameters": {
"userName": "memorydb-user",
"authenticationMode": {
"type": "password",
"passwords": [
"HIDDEN_DUE_TO_SECURITY_REASONS"
]
},
"accessString": "~* &* -@all +@read"
},
"responseElements": {
"user": {
"name": "memorydb-user",
"status": "active",
"accessString": "off ~* &* -@all +@read",
"aCLNames": [],
"minimumEngineVersion": "6.2",
"authentication": {
"type": "password",
"passwordCount": 1
},
"aRN": "arn:aws:memorydb:us-east-1:123456789012:user/memorydb-user"
}
},
"requestID": "ae288b5e-80ab-4ff8-989a-5ee5c67cd193",
"eventID": "ed096e3e-16f1-4a23-866c-0baa6ec769f6",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```