AWS CloudWatch 实战：从指标采集到自动化修复的监控体系

1. 这不是“又一篇CloudWatch教程”，而是一份我用三年踩坑换来的监控实战手册

AWS CloudWatch 不是那个藏在 AWS 控制台角落里、点开就弹出一堆图表、关掉就松一口气的“监控面板”。它是你整个云上系统的呼吸传感器、血压计和心电图仪三合一。我第一次把它当成“看看CPU用了多少”的玩具，结果在凌晨三点被一个未配置告警的 Lambda 冷启动超时打醒——那条本该提前两小时触发的Duration > 900ms告警，因为阈值单位写成了毫秒却误设为秒，彻底失效。从那天起，我开始把 CloudWatch 当成基础设施里最不可妥协的一环来设计，而不是事后补救的“锦上添花”。

这篇指南不讲官方文档里已有的定义，比如“CloudWatch 是 AWS 的监控与可观测性服务”——这种话连我实习生都能背出来。我要讲的是：当你面对一个刚上线的微服务集群，日均处理 200 万次 API 请求，后端依赖 RDS、ElastiCache 和 SQS，前端跑在 ALB 后面，你到底该盯哪 7 个指标？哪些告警必须设置为“立刻电话通知”，哪些可以只发 Slack？为什么你按文档配了HTTPCode_ELB_5XX_Count告警，却在真实故障中一无所获？答案往往不在控制台里，而在指标的采集粒度、维度组合、统计周期与业务语义的错位之中。

它适合三类人：刚考过 AWS SAA 的新人，想把“知道 CloudWatch 有指标”升级为“能靠它守住生产环境”；中小团队的 DevOps 工程师，没有专职 SRE，需要一套可落地、低维护、不烧钱的监控基线；还有架构师，在做技术选型时真正评估 CloudWatch 是否能承载你未来 18 个月的可观测性需求。全文所有配置、参数、阈值、脚本，全部来自我在金融、电商、SaaS 三类高可用场景下的真实部署记录，不是实验室里的理想模型。接下来的内容，每一行都对应着一次线上事故的复盘，或一次成本优化的实测数据。

2. 监控不是“看图说话”，而是构建三层防御体系：采集层、分析层、响应层

2.1 为什么 90% 的 CloudWatch 部署从第一步就错了？

绝大多数团队把 CloudWatch 当成“被动看板”：等系统出问题了，再打开控制台查 CPU、查错误率。这就像给汽车装了个豪华仪表盘，却不接油压传感器、不连胎压监测、不设发动机温度红线——只靠司机凭经验“感觉不对劲”。真正的 CloudWatch 实施，必须从架构设计第一天就嵌入三层防御：

• 采集层（Data Ingestion）：决定你能“看见什么”。不是所有指标都默认开启，也不是所有日志都自动转发。EC2 的基础指标（CPU、网络）是 5 分钟粒度免费提供，但你要 1 分钟粒度？得开 Detailed Monitoring，每实例每月多花 $1.20。RDS 的DatabaseConnections指标默认关闭，要手动启用 Performance Insights，且仅限 db.t3 及以上实例类型。更关键的是，自定义指标（比如订单创建耗时、支付成功率）必须由你的应用主动调用PutMetricDataAPI 上报——没人替你写这段代码。

• 分析层（Data Contextualization）：决定你“看懂什么”。同一个HTTPCode_Backend_5XX_Count指标，在 ALB 维度下代表后端服务整体崩溃；在 Target Group 维度下能定位到具体某组 EC2 实例；加上Path维度（需启用访问日志并解析），才能发现是/api/v2/payment接口批量失败，而非全站瘫痪。我见过太多团队只看聚合值，结果花了 4 小时排查负载均衡器，最后发现只是某个新上线的 /healthz 探针因路径变更返回了 500。

• 响应层（Action Orchestration）：决定你“做什么”。告警（Alarm）不是终点，而是自动化流程的起点。一个RDS_CPUUtilization > 90% for 5 minutes告警，不该只发邮件，而应触发 Lambda 自动执行：1）检查慢查询日志 top 5；2）对pg_stat_activity中运行超 30 秒的会话执行pg_cancel_backend()；3）将诊断报告推送到 OpsGenie 并创建 Jira Incident。这才是 CloudWatch 的价值闭环。

提示：很多团队卡在“采集层”就放弃了，因为觉得“上报自定义指标太麻烦”。我的经验是：先用 CloudWatch Agent 打包采集 OS 层指标（磁盘 I/O、内存页交换），再用 Embedded Metric Format（EMF）让应用日志自带结构化指标。一条logger.info("order_processed", {"duration_ms": 124, "status": "success"})日志，经 Agent 解析后自动产生OrderProcessed.Duration和OrderProcessed.Status两个指标，零代码改造。

2.2 官方文档没告诉你的“指标陷阱”：维度、统计方式与延迟的三角博弈

CloudWatch 的核心能力在于“维度（Dimension）”，但它也是最容易被误用的部分。维度不是标签，而是指标的“坐标轴”。CPUUtilization是一个指标名，InstanceId=i-0a1b2c3d4e5f67890是它的维度值。问题来了：当你为 50 个 EC2 实例设置了同一个告警规则，却只写了Namespace=AWS/EC2, MetricName=CPUUtilization，没有指定InstanceId维度，那么这个告警实际监控的是 50 个实例的平均值。这意味着：49 台实例 CPU 20%，1 台飙到 100%，平均值才 21.6%，告警永远不会触发——而那台 100% 的实例早已服务降级。

更隐蔽的是统计方式（Statistic）与时间粒度（Period）的组合陷阱。Average统计在 5 分钟周期内取所有采样点的均值，适合看趋势；但Maximum才能捕获瞬时毛刺。我们曾遇到支付网关偶发 200ms 超时，Average在 5 分钟内被大量 20ms 请求拉低到 35ms，完全淹没异常；改用Maximum后，200ms 毛刺立刻暴露。但Maximum也有代价：它对噪声极度敏感。ALB 的HTTPCode_ELB_4XX_Count在正常流量下每分钟可能有 3-5 个 400 错误（客户端参数错误），Maximum会频繁误报；此时必须结合Sum统计——看 5 分钟内总错误数是否超过阈值（如 > 100），既过滤噪声，又捕捉真实异常。

最后是延迟（Latency）。CloudWatch 指标从采集到可查询，存在固有延迟：基础指标约 1-2 分钟，自定义指标约 2-3 分钟，日志指标（通过 Logs Insights 查询）可达 5-10 分钟。这意味着：你无法用 CloudWatch 做亚秒级故障自愈。当数据库连接池耗尽，RDS_FreeableMemory指标下降到临界值，到告警触发、Lambda 启动、执行扩容，整个链路至少 3 分钟。所以，真正的高可用架构必须分层：CloudWatch 负责分钟级趋势预警与根因分析，而应用层需内置毫秒级熔断（如 Hystrix）、连接池健康检查（如 HikariCP 的connection-test-query）作为第一道防线。

3. 核心指标配置实操：从“能用”到“敢用”的 7 个黄金组合

3.1 EC2 实例：别再只看 CPU，这 3 个维度才是生死线

CPU 利用率是入门指标，但生产环境真正致命的是资源争抢与 I/O 瓶颈。我为你梳理出 EC2 监控的“黄金三角”：

1. StatusCheckFailed_System与StatusCheckFailed_Instance
   这是 AWS 底层健康检查，比任何应用层探针都可靠。System检查宿主机状态（如硬件故障、Hypervisor 问题），Instance检查实例操作系统是否响应。两者任一持续 2 分钟为 1，即触发严重告警。注意：此指标无维度，直接监控整个实例。配置示例：

   aws cloudwatch put-metric-alarm \ --alarm-name "EC2-System-Health-Failed" \ --alarm-description "EC2 system status check failed" \ --metric-name StatusCheckFailed_System \ --namespace AWS/EC2 \ --statistic Maximum \ --period 60 \ --threshold 0.9 \ --comparison-operator GreaterThanOrEqualToThreshold \ --evaluation-periods 2 \ --alarm-actions arn:aws:sns:us-east-1:123456789012:prod-ops-alerts

2. DiskReadOps+DiskWriteOps+DiskReadBytes+DiskWriteBytes（需启用 Detailed Monitoring）
   关键不是看绝对值，而是看IOPS 与吞吐量的比值。例如，gp3 卷理论最大 IOPS 16,000，最大吞吐 1,000 MB/s。若DiskReadOps达到 15,000 但DiskReadBytes仅 100 MB/s，说明是小文件随机读（如数据库 WAL 日志），IOPS 成瓶颈；若DiskReadBytes达到 950 MB/s 但DiskReadOps仅 2,000，说明是大文件顺序读（如视频转码），吞吐成瓶颈。告警策略：DiskReadOps> 90% of provisioned IOPS for 5 minutes。

3. NetworkIn与NetworkOut的 95 分位数（P95）
   平均值会掩盖突发流量。用 CloudWatch Logs Insights 计算 P95：

   filter @message like /NetworkIn/ | stats p95(@message) as p95_network_in by bin(5m)

   对于 Web 服务器，若 P95NetworkIn持续超过 ENI 带宽的 70%（如 c5.2xlarge 的 1.25 Gbps），预示网络拥塞风险。此时应检查是否被 DDoS 或爬虫冲击，而非盲目升级实例规格。

注意：StatusCheckFailed_*指标在实例启动后约 5 分钟才开始上报，首次部署时需预留此窗口期，避免误报。

3.2 RDS 数据库：超越CPUUtilization的 4 个核心指标

RDS 的CPUUtilization告警常沦为“狼来了”。真正反映数据库健康的是其内部资源消耗与请求队列状态：

1. DatabaseConnectionsvsDBInstanceClassMemory * 0.8
   连接数不是越多越好。每个连接占用内存（约 2-4 MB，取决于参数设置）。DBInstanceClassMemory可从DescribeDBInstancesAPI 获取。例如，db.m5.large 有 8 GiB 内存，安全连接数上限 ≈ 8192 MB × 0.8 ÷ 3 MB ≈ 2185。告警阈值设为 2000，持续 3 分钟。

2. FreeableMemory< 512 MB for 10 minutes
   注意单位是字节！512 MB = 536870912 字节。低于此值，PostgreSQL 会开始使用 swap，性能断崖式下跌。MySQL 则可能触发 OOM Killer 杀死进程。

3. ReadIOPS/WriteIOPS> 90% of Provisioned IOPS (for gp2/gp3)
   gp2 卷的 IOPS = 3 × volume size (GB)，最小 100。gp3 卷可独立设置 IOPS（最高 16,000）。当ReadIOPS持续接近上限，ReadLatency必然升高。此时ReadLatency > 10 ms for 5 minutes是更精准的告警信号。

4. ReplicaLag> 30 seconds for 5 minutes (for Multi-AZ or Read Replicas)
   主从延迟是数据一致性的命脉。30 秒是经验值：短于此值，应用可容忍最终一致性；长于此值，意味着从库可能已落后多个 WAL 文件，故障切换后数据丢失风险陡增。注意：此指标仅对 Multi-AZ 部署或显式创建的 Read Replica 有效。

实操心得：DatabaseConnections和FreeableMemory必须配合 Performance Insights 启用。否则，你只能看到“连接数高”，却不知是哪个 SQL 语句（SELECT * FROM users WHERE name LIKE '%a%'）在疯狂建连接。Performance Insights 的Top SQL视图，是定位慢查询的黄金入口。

3.3 Application Load Balancer：ALB 告警不是“看错误码”，而是“看请求流”

ALB 的指标设计哲学是“请求即一切”。HTTPCode_ELB_5XX_Count告警之所以常失效，是因为它只统计 ALB 自身返回的 5XX（如 502 Bad Gateway），而忽略了后端返回的 5XX（HTTPCode_Backend_5XX_Count）。真正的 ALB 监控，必须建立请求流全景视图：

特别强调TargetResponseTime：这是唯一能穿透 ALB、直达应用层性能的指标。它排除了客户端网络延迟、ALB 自身处理开销，纯粹反映你的 Java/Python 服务处理逻辑的效率。我们曾用此指标发现：一个 Spring Boot 应用因@Transactional注解滥用，导致单个请求持有数据库连接长达 8 秒，TargetResponseTimeP95 突增至 8200ms，而HTTPCode_Backend_5XX_Count为 0——因为服务还在“努力处理”，只是慢得离谱。

提示：ALB 指标默认按TargetGroup维度聚合。如果你有多个 Target Group（如web-tg,api-tg），务必为每个维度单独配置告警，避免api-tg的 503 淹没在web-tg的海量 200 中。

3.4 Lambda 函数：无服务器监控的“冷启动悖论”

Lambda 的监控难点在于：函数无状态、生命周期短、冷启动不可控。Invocations和Errors是基础，但真正致命的是Duration与Throttles的组合：

1. Duration的 P99 与ConcurrentExecutions的关联分析
   Duration指标本身无意义，必须结合并发数。当ConcurrentExecutions从 100 突增至 500，DurationP99 从 200ms 涨到 1200ms，说明函数遭遇资源争抢（CPU/内存不足）。此时应检查MemorySize设置：Lambda 的 CPU 配额与内存成正比（1792 MB 内存 ≈ 1 vCPU）。将内存从 512MB 升至 1024MB，CPU 配额翻倍，DurationP99 常能回落 40%。

2. Throttles> 0 for 1 minute +ConcurrentExecutions> 90% of Account Limit
   Throttles表示请求被拒绝，原因有两个：函数级别并发限制（ReservedConcurrentExecutions）或账户级并发限制（默认 1000）。前者是主动限流，后者是硬性天花板。告警必须区分：若Throttles伴随ConcurrentExecutions接近账户上限，需立即申请提升配额；若仅接近函数预留并发，则是业务流量突增，应触发自动扩缩容（通过 Application Auto Scaling 调整ReservedConcurrentExecutions）。

3. IteratorAgefor Event Source Mappings (Kinesis/DynamoDB Streams)
   当 Lambda 从 Kinesis 消费数据时，IteratorAge表示记录在流中等待处理的时长。> 300000 ms（5 分钟）即告警，意味着消费者处理速度远低于生产者写入速度，数据积压。此时Duration可能正常，但业务 SLA 已被违反。

常见误区：为 Lambda 配置Errors告警时，只设> 0。这会导致每次重试（Lambda 默认 2 次重试）都触发告警。正确做法是：Errors的Sum统计，阈值设为> 10 per 5min，并确保告警EvaluationPeriods=3，避免瞬时抖动误报。

4. 告警策略与自动化响应：从“收到邮件”到“问题已修复”的完整链路

4.1 告警分级：不是所有告警都值得半夜打电话

我把告警分为三级，每级对应不同的通知渠道与响应 SLA：

关键原则：P0 告警必须 100% 自动化，无需人工介入即可缓解。例如，P0 级别的RDS CPUUtilization > 95% for 5min，不应只发电话，而应触发 Lambda 执行：1）调用ModifyDBInstance升级实例规格；2）修改DBParameterGroup启用log_min_duration_statement=1000；3）向 Slack 发送“已自动升级 RDS 至 db.m5.2xlarge，预计 3 分钟生效”。这样，运维人员接到电话时，问题已在修复中。

注意：CloudWatch Alarms 的ActionsEnabled默认为true，但跨区域告警（如 us-east-1 的 Alarm 触发 us-west-2 的 Lambda）需手动启用。务必在创建后验证aws cloudwatch describe-alarms --alarm-names <name>中的"ActionsEnabled": true。

4.2 自动化响应：用 Lambda 编排“无人值守修复”

CloudWatch Alarms 可直接触发 Lambda，但复杂修复需编排。我推荐使用 Step Functions 构建状态机，实现“检测-诊断-修复-验证”闭环。以 RDS 连接数过高为例：

1. State 1：检测
   CloudWatch Alarm 触发 Step Function，输入包含DBInstanceIdentifier和当前DatabaseConnections值。

2. State 2：诊断
   Lambda A 调用DescribeDBInstances获取DBInstanceClass和DBParameterGroup，再调用DescribeDBParameters检查max_connections参数。若当前连接数 >max_connections × 0.9，进入修复；否则发送“误报”通知。

3. State 3：修复
   Lambda B 执行：

   • 修改DBParameterGroup，临时增大max_connections（需重启生效，故下一步）；
   • 调用RebootDBInstance强制重启（对 Multi-AZ 为故障切换，无停机）；
   • 启动 CloudWatch Logs Insights 查询，提取最近 1 小时slow_log中Rows_examined > 10000的 SQL。

4. State 4：验证
   Lambda C 等待 2 分钟后，调用DescribeDBInstances检查DBInstanceStatus是否为available，并查询DatabaseConnections是否回落至阈值以下。成功则结束；失败则触发人工介入流程。

整个流程代码量不到 200 行 Python，却将 RDS 连接风暴的 MTTR（平均修复时间）从 45 分钟压缩至 3 分钟。Step Functions 的可视化状态图，也让故障排查一目了然——哪一步失败，直接跳转到对应 Lambda 的 CloudWatch Logs。

4.3 告警去重与抑制：避免“告警海啸”摧毁运维心智

当一个底层故障（如 AZ 断电）引发连锁反应，EC2 StatusCheckFailed_Instance、RDS DBInstanceStatus=failed、ALB HealthyHostCount=0会同时告警，形成信息轰炸。必须用告警抑制（Alarm Suppression）机制：

• 基于指标相关性抑制：创建一个“根因告警”（Root Cause Alarm），如EC2 StatusCheckFailed_System = 1 for 2min。当它触发时，自动禁用所有依赖它的告警（如该 EC2 上的 RDS、ALB Target）。这需通过 Lambda 实现：告警触发时，调用disable-alarm-actionsAPI。

• 基于时间窗口抑制：对已知的维护窗口（如每周二 2:00-3:00 的数据库备份），提前调用put-metric-data上报一个MaintenanceMode=1自定义指标，并在所有告警的Metrics中添加Expression：IF(MaintenanceMode == 1, 0, OriginalMetric)。这样，维护期间所有告警值被强制设为 0，永不触发。

• 基于事件桥接抑制：将 CloudWatch Events（现为 EventBridge）与告警联动。当RDS DBInstanceStatus=failed事件发生，EventBridge 规则自动触发 Lambda，向 SNS 主题发送“RDS 故障，暂停 ALB 告警”，ALB 告警订阅该主题并执行禁用操作。

实操心得：告警抑制不是“关掉告警”，而是“让告警更聪明”。我建议每季度做一次告警审计：列出所有 P0/P1 告警，模拟一个 AZ 故障场景，画出告警触发树，找出哪些是冗余的“回声告警”，然后用上述方法逐一消除。一次审计通常能砍掉 30% 的无效告警。

5. 日志分析与根因定位：用 Logs Insights 替代“grep 一百遍”

5.1 从“大海捞针”到“精准定位”：Logs Insights 的 3 个杀手级查询

CloudWatch Logs Insights 不是高级版 grep，而是时序数据库 + SQL 引擎的融合体。它的威力在于：用 1 条查询，替代过去 1 小时的手动日志翻查。

1. 定位“偶发超时”的真实原因
   当ALB TargetResponseTimeP99 突增，传统做法是下载所有应用日志，用grep "ERROR"、grep "timeout"海量筛选。Logs Insights 一行解决：

   filter @message like /ERROR|timeout|500|503/ | filter @timestamp > now() - 15m | stats count(*) as error_count by bin(1m), @message | sort error_count desc | limit 20

   结果直接显示：过去 15 分钟，Connection refused to database错误在 14:02-14:03 高峰，共 127 次，远超其他错误。根因瞬间锁定为数据库连接池耗尽。

2. 分析“用户投诉慢”的请求链路
   结合 X-Ray 追踪 ID，查询特定慢请求的完整日志：

   filter @message like /xray-trace-id/ and @message like /14:05/ | fields @timestamp, @message, xray_trace_id | sort @timestamp asc | limit 100

   配合 X-Ray 控制台，可下钻到每个子分段（Subsegment）的耗时，精确到毫秒级。

3. 识别“爬虫攻击”的流量特征
   当ALB HTTPCode_ELB_4XX_Count暴涨，快速识别恶意 UA：

   filter @message like /400|403|404/ | parse @message /"user-agent":"(?<user_agent>[^"]*)"/ | stats count(*) as request_count by user_agent | sort request_count desc | limit 10

   若发现python-requests/2.28.1占比 92%，且request_count> 1000/minute，立即加入 WAF 规则封禁。

提示：Logs Insights 查询默认扫描最近 1 小时日志。对历史分析，需在查询前加fields @timestamp | filter @timestamp > '2023-10-01T00:00:00'显式指定时间范围，否则可能超时失败。

5.2 日志指标化：让日志自己“说话”

Logs Insights 的终极用法是Embedded Metric Format (EMF)。它允许你在日志中直接嵌入结构化指标，CloudWatch 自动提取并创建指标。例如，Node.js 应用：

console.log(JSON.stringify({ "service": "payment-service", "version": "v2.1", "message": "Payment processed successfully", "payment_status": "success", "processing_time_ms": 142, "_aws": { "Timestamp": Date.now(), "CloudWatchMetrics": [{ "Namespace": "MyApp/Payments", "Dimensions": [["service", "version"]], "Metrics": [ {"Name": "ProcessingTime", "Unit": "Milliseconds"}, {"Name": "SuccessCount", "Unit": "Count"} ] }] } }));

这条日志会自动创建两个指标：

• MyApp/Payments.ProcessingTime（带service=payment-service, version=v2.1维度）
• MyApp/Payments.SuccessCount（同上维度）

从此，你不再需要PutMetricDataAPI，日志即指标。支付成功率可直接用SuccessCount / (SuccessCount + FailureCount)计算，且天然具备所有日志的维度（如按country=CN过滤）。

注意：EMF 日志必须是单行 JSON，且_aws.CloudWatchMetrics字段必须存在。测试时，用aws logs test-metric-filter验证日志是否被正确解析。

6. 成本优化与陷阱规避：那些让你账单翻倍的“隐形开关”

6.1 CloudWatch 的 4 个成本黑洞及应对方案

CloudWatch 成本常被低估，尤其在高吞吐场景。我帮你揪出最易忽略的四大黑洞：

1. Detailed Monitoring 的“甜蜜陷阱”
   EC2/RDS 启用 Detailed Monitoring（1 分钟粒度）后，指标数量激增 5 倍（5 分钟 → 1 分钟）。但 90% 的场景，5 分钟粒度已足够。对策：仅对核心生产实例启用 Detailed Monitoring；开发/测试环境一律禁用。用aws ec2 monitor-instances --no-dry-run批量关闭。

2. 日志保留期的“永久存储”幻觉
   CloudWatch Logs 默认无限期保留。一个日均 10 GB 的应用日志，一年就是 3.6 TB，费用高达 $360（$0.03/GB/month）。对策：所有日志组强制设置保留期。生产环境设为 90 天，开发环境 7 天。用 Terraform 管控：

   resource "aws_cloudwatch_log_group" "app_logs" { name = "/var/log/app" retention_in_days = 90 }

3. Logs Insights 查询的“无限扫描”
   每次 Logs Insights 查询按扫描的数据量计费（$0.005/GB）。一个未加时间过滤的filter @message like /ERROR/查询，可能扫描数月日志，单次费用 $50+。对策：在控制台右上角强制设置默认时间范围（如 Last 15 minutes）；在代码中调用start-query时，必须传入startTime和endTime。

4. 自定义指标的“高频上报”
   每个PutMetricData请求最多含 10 个指标，但每秒最多 150 个请求。若你的应用每毫秒上报一次指标，不仅触发限流，还产生巨额请求费（$0.01/1000 个请求）。对策：客户端聚合。应用层缓存 10 秒内的duration_ms，计算Average、Maximum、SampleCount后，每 10 秒调用一次PutMetricData上报聚合值。

实操心得：每月初，运行aws cloudwatch get-metric-statistics查询各命名空间的指标数量，重点关注AWS/EC2、AWS/RDS、AWS/ApplicationELB。若某命名空间指标数月增 200%，立即审计是否误开了 Detailed Monitoring 或日志指标化。

6.2 免费额度的“精打细算”：如何把 $10 免费额度用到极致

AWS 新账户有 $10/月 CloudWatch 免费额度（含 1000 万指标摄取、10 GB 日志存储、1000 万 Logs Insights 查询扫描量）。最大化利用技巧：

• 指标摄取：优先用于自定义指标（如业务 KPI），基础指标（CPU、内存）用免费的 5 分钟粒度。
• 日志存储：将调试日志（DEBUG级别）写入本地文件，仅INFO及以上级别上传 CloudWatch；用 Log4j2 的ThresholdFilter实现。
• Logs Insights：创建常用查询为 Saved Queries，复用而非重写；对高频查询（如每日巡检），用 Lambda 定时执行并存入 S3，避免重复扫描。

7. 常见问题与独家避坑指南：那些文档里找不到的答案

7.1 “告警不触发”问题排查速查表

独家技巧：用aws cloudwatch get-metric-alarm-history查看告警状态变更历史，精确到毫秒。比控制台的“最近活动”更详细。

7.2 “日志查不到”问题的 3 个致命疏漏

1. CloudWatch Agent 配置中的force_flush_interval
   Agent 默认每 10 秒刷一次日志到 CloudWatch。若实例在 5 秒时宕机，这 5 秒日志永远丢失。解决方案：在