AWS 五大核心服务监控与告警实战指南（2026最新版）

Meta Description: 全面掌握AWS S3、CloudFront、RDS、DynamoDB、ElastiCache五大核心服务的CloudWatch监控与告警配置。从指标选型到SNS告警通道，构建7×24可观测性体系。

关键词：AWS CloudWatch监控、S3监控指标、CloudFront日志分析、RDS Performance Insights、DynamoDB告警、ElastiCache缓存监控、AWS可观测性

前言

在上一篇文章中，我们深入探讨了AWS五大核心服务（S3、CloudFront、RDS、DynamoDB、ElastiCache）的性能调优策略。然而，调优的前提是你能"看到"问题——没有一套健壮的监控与告警体系，再好的架构也只是在黑暗中摸索。据AWS官方统计，配置了合理告警的生产环境，故障平均恢复时间（MTTR）比未配置告警的环境缩短67%。

本文将逐一拆解五大服务的核心监控指标、CloudWatch告警阈值设置、以及SNS多渠道通知的最佳实践。

五大服务监控全景对比

S3 存储桶深度监控

一、必设的 6 个核心指标与告警

S3 的监控远比想象中丰富。除了常见的 BucketSizeBytes 和 NumberOfObjects，以下指标对于生产环境至关重要：

二、S3 Access Logs 审计分析

单靠CloudWatch指标只能看到"发生了什么"，而S3 Access Logs能告诉你"谁做了什么"。开启日志投递后，每条记录包含：

BucketOwner RequestTime RemoteIP Requester Operation Key RequestURI HTTPStatus ErrorCode

配合 Athena 进行查询，典型分析场景包括：

-- 查询过去24小时内被拒绝的请求Top10
SELECT Requester, Operation, COUNT(*) as cnt
FROM s3_access_logs
WHERE HTTPStatus = 403
  AND RequestDateTime > current_timestamp - interval '24' hour
GROUP BY Requester, Operation
ORDER BY cnt DESC
LIMIT 10;

🔴 实战踩坑：S3 请求指标与计费指标的差异

S3的 AllRequests 指标不包括免费的请求类型（如 ListObjects 的部分免费额度），因此该指标数值可能低于实际请求数。不要直接用 AllRequests 做成本推算，应结合 Cost Explorer 或 AWS CUR报告 来精确核算。

CloudFront CDN 实时日志与监控

一、标准日志 vs 实时日志的选择

二、关键监控指标

# CloudFront 告警推荐配置（YAML示例）
CloudFrontHighErrorRate:
  Metric: 5xxErrorRate
  Threshold: 1%  # 错误率超过1%
  Period: 300    # 5分钟评估周期
  EvalPeriods: 2 # 连续2个周期触发

CloudFrontHighOriginLatency:
  Metric: OriginLatency (p90)
  Threshold: 500ms
  Period: 300
  EvalPeriods: 3

CloudFrontCacheHitRateDrop:
  Metric: CacheHitRate
  Threshold: < 80%  # 缓存命中率过低
  Period: 900       # 15分钟
  EvalPeriods: 2

三、实战：利用实时日志做异常流量拦截

通过 Kinesis → Lambda 的处理链，可以在秒级识别并阻断恶意请求：

import json, boto3

WAF_IP_SET_ID = 'your-ip-set-id'
waf = boto3.client('wafv2')

def lambda_handler(event, context):
    for record in event['Records']:
        log_entry = json.loads(record['Data'])
        # 针对单一IP高频率404请求的模式识别
        if log_entry['sc-status'] == '404':
            check_and_block(log_entry['c-ip'])

RDS 数据库三层监控体系

RDS 提供了从粗到细的三层监控，每一层解决不同的问题：

第一层：CloudWatch 标准指标（免费，60秒粒度）

适用于全局健康检查：CPUUtilization、DatabaseConnections、FreeableMemory、FreeStorageSpace。

# 使用AWS CLI创建RDS高CPU告警
aws cloudwatch put-metric-alarm \
  --alarm-name "RDS-High-CPU" \
  --metric-name CPUUtilization \
  --namespace AWS/RDS \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 3 \
  --dimensions Name=DBInstanceIdentifier,Value=prod-mysql-01

第二层：Enhanced Monitoring（1秒粒度，OS层级）

提供操作系统级别指标——进程列表、内存使用细节、文件系统I/O等。这是排查"数据库没报错但整体变慢"类问题的利器。

关键增强指标：

第三层：Performance Insights（数据库引擎层级）

直接显示等待事件和SQL语句级别的瓶颈。最具价值的功能是 db.load 指标的按维度切片：

-- 通过Performance Insights API查询Top SQL
SELECT sql.sql_text, sql.calls_per_sec, sql.avg_latency_in_ms
FROM performance_insights.metrics
WHERE sql.load_by_sql > 0.1
ORDER BY sql.load_by_sql DESC
LIMIT 10;

DynamoDB NoSQL 专属监控

一、核心指标矩阵

DynamoDB 的自动扩缩容使其监控逻辑与其他服务不同——重点关注限流和延迟，而非资源利用率：

二、Contributor Insights —— DynamoDB专属观测利器

Contributor Insights 是CloudWatch中专门为DynamoDB设计的工具，能按分区键或GSI键分析流量分布，快速定位热分区。

// 启用Contributor Insights（CLI）
aws dynamodb update-contributor-insights \
  --table-name Orders \
  --contributor-insights-action ENABLE

配置后，可以在CloudWatch控制台看到每个分区键的读写流量占比。如果某个键占比超过30%，说明存在热分区，需要重新设计分区策略或引入DAX。

ElastiCache 缓存监控与容量规划

一、Redis 核心指标

二、🔴 关键认知：Redis是单线程的

Redis在单线程模型下，CPU多核优势无法充分发挥。当 CPUUtilization 超过70% 时，即使还有内存余量，延迟也会显著上升。因此ElastiCache的CPU告警阈值应设为75%（而非通常的80%-90%），比RDS更保守。

三、Memcached 补充指标

如果你使用的是Memcached引擎，额外关注：

# Memcached 特有指标
aws cloudwatch get-metric-statistics \
  --namespace AWS/ElastiCache \
  --metric-name NewConnections \
  --dimensions Name=CacheClusterId,Value=prod-memcached \
  --period 300 \
  --statistics Sum

SNS告警通道多路分发

监控指标配置完毕只是第一步，告警触达人才是最终闭环。推荐的多通道架构：

                    ┌─→ Email（SNS Topic Subscription）
CloudWatch Alarm ──┤
                    ├─→ Lambda → 企业微信/钉钉 Webhook
                    │
                    ├─→ Lambda → Slack Channel
                    │
                    └─→ SNS → SQS → 自建告警聚合平台

# Lambda函数：CloudWatch告警 → 企业微信通知
import json, urllib.request

WEBHOOK_URL = "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_KEY"

def lambda_handler(event, context):
    msg = json.loads(event['Records'][0]['Sns']['Message'])
    alarm_name = msg['AlarmName']
    new_state = msg['NewStateValue']
    reason = msg['NewStateReason']
    
    markdown = f"## ⚠️ AWS告警触发\n> 告警: {alarm_name}\n> 状态: {new_state}\n> 原因: {reason}"
    urllib.request.urlopen(urllib.request.Request(
        WEBHOOK_URL,
        data=json.dumps({"msgtype": "markdown", "markdown": {"content": markdown}}).encode()
    ))

总结

AWS五大核心服务的监控体系可以归纳为三层：CloudWatch基础指标做健康巡检 → 增强监控指标定位性能瓶颈 → 专属工具（Performance Insights / Contributor Insights）精准到SQL或分区键级别。告警配置切忌"狼来了"——阈值太敏感会导致告警疲劳，太迟钝会错过黄金恢复窗口。建议每个服务保留2-3个核心告警，其余指标用Dashboard聚合展示，定期巡检而非实时告警。

---

本文由 6.chengzicloud.cloud 提供，点击访问首页了解更多