DynamoDB作为全托管的NoSQL数据库服务，虽然免去了运维底层基础设施的麻烦，但应用层面的监控依然不可忽视。表级限流、容量规划不足、热点分区等问题都可能悄无声息地拖垮业务。CloudWatch默认会为每张DynamoDB表收集一组关键指标，如果只是偶尔登录控制台看看图表，往往要等用户投诉后才发现问题。为这些指标配置告警，才能把被动的故障排查变成主动的运维响应。
一、DynamoDB核心监控指标解读
CloudWatch为DynamoDB提供的指标按维度可以分为表级别和全局二级索引（GSI）级别，每张表和每个索引都会独立上报数据。理解这些指标的含义是设置合理告警阈值的前提，否则告警要么频繁误报，要么形同虚设。
首先要关注的是ConsumedCapacityUnits和ThrottledRequests这一对指标。前者表示实际消耗的读写容量单元，对于配置了预置容量的表，如果消耗量长期逼近预置值，就说明容量即将不够用，需要提前扩容或切换到按需模式；后者则表示被限流的请求数量，只要这个数字大于0，就意味着部分请求被DynamoDB拒绝了，客户端需要重试。对于按需计费的表，虽然理论上不会被限流，但仍然存在超过配额上限被限流的场景，同样值得监控。
其次是错误类指标。SystemErrors统计DynamoDB内部产生的服务端错误（通常是HTTP 500系列），如果这个指标持续非零，大概率是服务端异常或者请求超时导致；UserErrors统计的是客户端错误（HTTP 400系列），常见原因是查询条件写错、缺少必要的参数等。一般建议对SystemErrors配置告警，而UserErrors更适合用于排查应用代码问题。
另外还有SuccessfulRequestLatency表示成功请求的延迟，按操作类型分别统计（GetItem、Query、Scan等），如果P99延迟明显上升，可能是热点分区或者表数据量增长导致的性能退化，也值得纳入告警范围。
二、通过控制台和CLI创建告警
在控制台配置告警比较直观：进入CloudWatch服务，选择告警菜单，创建告警时选择DynamoDB的表指标命名空间AWS/DynamoDB，再按表名和操作维度挑选具体指标。设置阈值时要结合业务特点，比如限流告警的阈值可以设为5分钟内限流请求数大于10，而不是简单的大于0，因为偶发的限流配合客户端重试机制通常不会影响业务，阈值设得太低反而会产生大量噪音。
如果需要批量创建或者纳入自动化管理，用AWS CLI更合适。下面是一个创建限流告警的示例命令：
aws cloudwatch put-metric-alarm \
--alarm-name "my-table-throttled-requests" \
--alarm-description "DynamoDB表限流请求数告警" \
--metric-name "ThrottledRequests" \
--namespace "AWS/DynamoDB" \
--statistic "Sum" \
--period 300 \
--threshold 10 \
--comparison-operator "GreaterThanThreshold" \
--evaluation-periods 1 \
--dimensions Name=TableName,Value=my-table \
--alarm-actions "arn:aws:sns:us-east-1:123456789012:alert-topic" \
--treat-missing-data "notBreaching"参数中有几个细节需要注意。--period是指标的聚合周期，设为300秒表示每5分钟统计一次；--evaluation-periods表示连续几个周期超过阈值才触发告警，设为2可以有效过滤瞬时抖动；--treat-missing-data建议显式设置为notBreaching，因为DynamoDB在没有流量时可能不上报数据点，默认的missing处理方式会导致告警状态变成数据不足，干扰判断。
对于SystemErrors的告警，可以把--metric-name换成SystemErrors，阈值设为大于0并连续两个周期评估。如果表开启了按需容量，还可以对ConsumedCapacityUnits设置一个基于消费金额的告警，避免账单突然暴涨。
三、生产环境的告警策略与最佳实践
在实际生产中，告警体系不是指标越多越好，而是要围绕业务影响来设计。建议把告警分成两个层级：第一层是紧急告警，包括限流请求数激增、SystemErrors持续非零、表被意外删除等，这类告警直接电话或短信通知值班人员；第二层是预警，包括容量使用率超过80%、延迟P99超过某个基线等，这类通过邮件或即时通讯工具通知即可，供容量规划参考。
容量使用率告警通常需要基于两个指标做计算，比如用ConsumedCapacityUnits除以ProvisionedCapacityUnits。CloudWatch支持基于数学表达式的告警，可以直接在put-metric-alarm中使用--metrics参数配置：
aws cloudwatch put-metric-alarm \
--alarm-name "my-table-capacity-usage" \
--alarm-description "预置容量使用率超过85%" \
--threshold 85 \
--comparison-operator "GreaterThanThreshold" \
--period 300 \
--evaluation-periods 2 \
--treat-missing-data "notBreaching" \
--metrics '[{"Id":"e1","Expression":"m1/m2*100","Label":"容量使用率","ReturnData":true},
{"Id":"m1","MetricStat":{"Metric":{"Namespace":"AWS/DynamoDB","MetricName":"ConsumedCapacityUnits","Dimensions":[{"Name":"TableName","Value":"my-table"}]},"Period":300,"Stat":"Sum"}},
{"Id":"m2","MetricStat":{"Metric":{"Namespace":"AWS/DynamoDB","MetricName":"ProvisionedCapacityUnits","Dimensions":[{"Name":"TableName","Value":"my-table"}]},"Period":300,"Stat":"Average"}}]' \
--alarm-actions "arn:aws:sns:us-east-1:123456789012:alert-topic"除了直接使用CLI，更推荐把告警配置纳入基础设施即代码管理。使用Terraform时可以通过aws_cloudwatch_metric_alarm资源批量声明告警，配合变量循环为多张表统一创建规则，避免手工操作遗漏。团队如果已经在用CloudFormation或CDK，也有对应的资源类型可以复用。这样告警配置会随代码一起做版本评审和回滚，可靠性远高于控制台手工点击。
最后还有几个常见的坑值得提醒。一是告警依赖SNS主题，要确保订阅者的邮箱或手机号已完成确认，否则告警触发了却没人收到；二是GSI有独立的容量配置，主表没问题不代表索引不限流，需要为每个GSI单独创建告警；三是DynamoDB指标是免费的，但跨区域的告警或者高频率的自定义指标会产生少量费用，规划时要留意；四是建议定期演练告警流程，比如人为制造一次限流场景，验证从指标触发到通知送达的整条链路是否通畅，监控体系只有经过验证才真正可信。
DynamoDBCloudWatch指标告警修改时间：2026-09-09 03:28:36