EC2性能卡顿？CloudWatch全链路排查实操指南

EC2 突然卡顿，但控制台上的 CPU 利用率曲线看着并不高——这类“表面正常、实际缓慢”的故障，单靠基础监控很难破局。本文将围绕 EC2 性能卡顿 CloudWatch 排查全链路，梳理从资源指标、日志分析到链路追踪的完整诊断路径，帮助你避开平均指标的陷阱，直接定位真正的性能瓶颈。

一、一、EC2 性能卡顿的常见原因与排查思路

1.  CPU 与内存瓶颈如何判断

CPU 使用率高是卡顿的表层信号，但更致命的往往是看不见的瓶颈。突发性能实例（如 T3、T4g）的 CPU 积分耗尽后，即使利用率显示 20%，实例也会被强制限速，应用程序响应明显变慢。内存问题同样隐蔽：EC2 默认不推送内存使用率，当物理内存不足触发 OOM Killer 或大量 swap 换页时，CPU 的 iowait 占比会急剧升高，系统整体卡顿。没有 CloudWatch Agent 的内存指标，这类故障几乎无法从图表中直接发现。

2.  磁盘 I/O 与网络延迟影响

磁盘 I/O 的等待时间（iowait）飙升，常见于数据库突然执行全表扫描、日志集中刷盘或 AWS 上的 EBS 卷规格不足以承载突增流量。网络延迟的影响则更细腻：跨可用区或跨区域调用时，几毫秒的累积延时可能被放大为数百毫秒的请求排队。CloudWatch 提供 DiskReadOps、NetworkIn 等基础指标，但真正定位到具体进程和调用方，需要把 VPC Flow Logs 或 X-Ray 追踪链路关联起来，避免陷入“网络指标正常，业务却超时”的盲区。

3.  从症状到根因的排查路径

性能抖动很少是单一原因。一条成熟的排查路径是：先确认症状范围——是单个实例还是整个服务组；再查 CloudWatch 的百分位指标（p99 延迟）而非平均值，定位异常时间窗口；随后在该时间段内，交叉比对 CPU Credit、iowait、内存使用率等自定义指标；有微服务依赖时，通过 X-Ray 服务地图明确哪个下游调用出现陡增；最后，利用 CloudWatch Logs Insights 检索对应时间段的 ERROR 或超时日志，锁定具体事务或 SQL 语句。这条路径能绕开“告警疲劳”，让每次排查都有据可循。

二、二、CloudWatch核心指标监控与解读

不少团队对 EC2 的监控仍停留在“CPU 没打满就没事”的阶段，但线上卡顿的真凶往往藏在那几个默认不开的指标里。在一次电商大促后的复盘里，我们跟踪到一个奇怪现象：某台 c5.large 实例在 CPU 利用率仅 35% 时，业务侧 p99 响应时间却从 200ms 飙升到 1.2s。事后对照 CloudWatch 的 Extended Statistics 才发现，同一时段的磁盘 iowait 时间接近 120ms，而标准监控面板只展示了平均值，完全抹掉了那根要命的尖刺。

1.  EC2 关键指标有哪些

默认推送的 CPUUtilization、NetworkIn/Out、DiskReadOps/WriteOps 等指标只够做第一层健康检查。想要排查“性能卡顿”这种模糊故障，必须把视野扩大到三个容易被忽略的维度。

第一个是突发性能实例的 CPU 积分余量。T3/T4g 这类实例在积分耗尽后，即使 CPU 利用率远未触及基线，vCPU 也会被强制限速到基准性能的 10%~20%。CloudWatch 中的 CPUCreditBalance 就是直接的命门——当这个值连续 5 分钟低于 1，几乎所有磁盘和网络操作都会感知到明显延迟，而基础利用率指标毫无异常。

第二个是内存与交换区压力。默认监控不包含内存指标，但 OOM Killer 和重度 swap 引发的连锁反应远比想象中普遍。一旦可用内存跌破 512MB 且 SwapUsage 飙高，系统会将大量内存页置换到磁盘，此时 CPU 的 iowait 时间会从正常的小于 10ms 瞬间拉升至上百毫秒，直接拖慢所有依赖磁盘 I/O 的线程。这种现象在 Java 应用未设置堆上限的场景中尤其高发。

第三个是请求级别的百分位延迟。CloudWatch 虽然不直接提供应用层延迟，但通过 CloudWatch Agent 采集的 procstat 插件或应用自定义指标，配合 Extended Statistics 查看 p99 或 p95 值，就能暴露间歇性的排队阻塞。一次压测中我们发现，某 Node.js 服务的平均请求延迟稳定在 85ms，但 p99 每隔 20 秒就跳至 3.8s，根源是单线程事件循环被一次慢查询阻塞，而平均指标完全隐匿了这个问题。

2.  如何自定义 EC2 监控项

补齐上述指标，不能靠“有空再看”，应当作为实例初始化流程的一部分固化下来。

内存与磁盘使用率的采集方案已经很成熟：通过统一安装 CloudWatch Agent，在配置文件中启用 metrics_collected 下的 mem 和 disk 插件，每分钟推送 mem_used_percent、disk_used_percent 等指标。实际操作中一个常见的坑是忘记给 disk 指定 fstype 排除临时文件系统，导致 /run 或 devtmpfs 满告警误报。建议在所有 Linux 实例的配置中锁定 fstype: ext4 和 xfs，并额外监控 disk_free 的绝对值，当剩余空间低于 10GB 时就触发告警，而不是等到 95% 占用。

应用日志转指标是另一个高杠杆操作。在 CloudWatch Agent 的 logs 段中定义 metric_filters，可以将 nginx 的 499/502 状态码、Java 应用的 OutOfMemoryError、或者业务日志中“order_process_timeout”这类特定模式直接计数并生成自定义指标。相比事后翻 Logs Insights，这种实时化的指标可以直接设置告警并在 Dashboard 上与 CPU、内存曲线叠加，一眼就能判断故障是资源层还是应用层引发。

如果已经进入微服务架构，还要把分布式追踪纳入监控体系。对于 Java 或 Python 服务，最简单的切入点是在入口和出口处集成 X-Ray SDK，通过 AWSXRayRecorder.beginSegment 和 HTTP 客户端拦截器，自动记录下游调用耗时。关键策略是采样——非生产调试期，采样率设置在 5% 并开启 samplingRules，仅对状态码 5xx 或延迟超过 2 秒的请求全量采集。这样既抓得住罕见故障的完整调用链，又不会因为 trace 数据膨胀而吃掉实例的网络带宽和 CPU。

3.  指标异常阈值设定方法

一刀切的“CPU > 80% 就告警”已经证明是告警疲劳的主要制造者。更可靠的做法是把阈值分成两类：静态基线告警和动态异常检测。

静态基线适用于那些“一旦达到就必然出事”的硬资源边界。比如 CPUCreditBalance < 1 持续 2 个数据点、disk_used_percent >= 90 持续 5 分钟、SwapUsage > 1GB 等。这些告警动作可以绑定到 SNS 或自动化脚本，直接触发实例规格变更或磁盘清理流程。

动态异常检测则适合 CPU、网络流量、请求延迟这些随业务周期波动的指标。CloudWatch Anomaly Detection 会基于过去两周的数据自动建立预测带，只有偏离正常模式时才发出告警。一个典型实践是：先用一周的低峰期流量构建基线，然后将异常检测的 Band 宽度设为 2 倍标准差，上线后再根据误报率逐步收紧。曾有一个 SaaS 团队在启用此功能当天就抓出一个隐藏问题——凌晨 3 点 CPU 利用率突然飙至峰值 90%，而固定阈值从未触发，因为白天平均利用率一直在 45% 左右；事后排查发现是数据库备份脚本错误地执行了全量扫描。

最后，任何阈值都要配合 Canary 用户视角验证。用 CloudWatch Synthetics 编写一个模拟用户关键路径的脚本（如登录→搜索→加购），并将成功率和响应时间作为告警条件。当 Canary 的 Duration p95 超过 3 秒或 SuccessPercent 低于 99%，同时关联到后端 CPU 或内存正常，基本可以排除基础设施问题，将排查重心转向应用逻辑或第三方依赖。这种“指标+日志+真实用户模拟”的三角校验，才是真正意义上的全链路可观测，而不再是围绕几个孤立数字的猜谜。

三、三、CloudWatch Logs日志分析实战

多数EC2性能卡顿的排查最后都会落到同一个尴尬的境地：监控大屏上的CPU、内存、网络曲线看起来没毛病，但应用就是慢。这时候真正能撕开表象的，是埋在日志流里的证据。CloudWatch Logs本身不是银弹，但结合指标关联与查询语言，它可以把分散在操作系统、应用、中间件里的碎片信息复原成一条完整的故障链路。这个复原过程，需要先解决“有没有日志”的问题，再解决“怎么找线索”的问题。

1.  如何启用EC2日志流：不只是一行 agent 配置

EC2默认只往外推送虚拟化层面的基础指标，操作系统内部的日志必须由用户自行采集。实践中，用 CloudWatch Agent 统一收集应用日志和系统日志是最可控的方式——远比手动 rsync 到 S3 再临时翻找可靠。关键在于，Agent 的部署要嵌入到不可变基础设施的构建流程里，而不是等出故障了再手动补救。建议在启动模板或者镜像烘烤阶段就完成两点：一是为实例赋予一个受限的 IAM 角色，只包含 CloudWatchAgentServerPolicy 及写入指定日志组的权限，避免权限过度开放；二是在 Agent 配置文件中显式声明需要采集的日志路径，例如 /var/log/messages、/var/log/secure、应用本身的 *.log 文件，并设定日志组和日志流的命名规则，用实例 ID 或主机名区分流，避免所有实例混在一个日志流里导致查询时全量扫描。

值得注意的是，不少团队只配了应用日志，却漏掉了操作系统级日志。在一次由磁盘 I/O 耗尽引发的卡顿中，应用自身的日志可能只记录到“DB query timeout”，但 /var/log/messages 中的 kernel: nvme nvme0: I/O timeout 才是那条直接指向 EBS 卷异常的关键记录。所以，在 CloudWatch Agent 里增加类似 disk 和 procstat 的指标采集之外，确保系统日志同步推送到 CloudWatch Logs，能在故障复盘时少走很多弯路。

2.  通过日志过滤故障线索：把“查日志”变成“查数据”

日志进到 CloudWatch Logs 之后，最忌讳的行为是在控制台里逐页翻看原始文本。真正工业化的做法，是用 CloudWatch Logs Insights 查询把问题模式“挖”出来。比如当观察到某台 EC2 实例的 CPU iowait 突然飙高时，马上打开 Logs Insights，选定对应日志组和这 5 分钟的时间窗口，执行：

fields @timestamp, @message
| filter @message like /IO timeout/i or @message like /reset by peer/i
| sort @timestamp desc
| limit 50

这个查询会立刻筛出所有与 I/O 超时、连接重置相关的日志行，并按照时间倒序排列。多数情况下，性能故障的共性线索会在几秒钟内浮现：某一类数据库查询的耗时从毫秒级陡增到秒级；某个微服务反复抛出Connection reset；或者 Java 应用的OutOfMemoryError正在以每分钟几十次的频率刷屏。

另一个被低估的手段是 Metric Filter。可以把日志中特定模式的字符串直接转化为指标，比如统计 /OutOfMemoryError/ 的出现次数，并在这个派生指标上设置告警。这能绕过传统内存告警的延迟——当 CloudWatch 自带的内存指标还在显示尚有 30% 空闲时，日志里的 OOM 计数器已经跳变，比操作系统 OOM Killer 动手更快。某次线上事故中，正是这种日志派生指标在故障扩散前 2 分钟发出了 SNS 通知，抢出了宝贵的止损时间。

3.  结合指标关联分析技巧：在同一根时间轴上对话

单看日志经常陷入“局部正确”的陷阱：日志写明了慢在数据库，但数据库自己没告警。这时候需要把日志放进指标的上下文中交叉验证。AWS 控制台提供了一个被严重低估的入口：在 CloudWatch 指标图表上选中某个异常凸起的时间点，右键菜单里可以直接“View in Logs”，跳转到对应日志组的 Insights 页面，并自动填充该时间窗口。这个操作把原本需要手动对齐时区、频繁切换界面的工作压缩成了一次点击，让“这个时刻到底发生了什么”变得即时可查。

更进一步，可以构建一个固定排查路径：收到 CloudWatch 复合告警（例如网络出流量陡降 + 磁盘队列深度飙升）→ 在监控面板上标记异常时段 → 从指标图跳入 Logs Insights → 用 filter 语法并行搜索多个日志组。在一次典型的“高峰期卡顿”案例里，通过这种方法发现磁盘 DiskQueueDepth 指标在 14:03 突破 256 的同时，应用日志中 waiting for table metadata lock 的密度突然增加 40 倍，而数据库日志里没有任何死锁记录。最终根因是某个后台报表任务的 ALTER TABLE 操作未被提交，堵住了所有读写。这里如果只看指标，会误判为 EBS 卷性能不足；只看应用日志，又会以为是数据库代码缺陷。只有把指标异常点和日志字符串在同一个时间轴上对齐，才能得出可验证的结论，而不是靠直觉猜测。

四、四、CloudWatch Synthetics与Canary测试

Canary并非新概念，但将其植入云监控体系后，它的角色已从简单的“拨测工具”演变为全链路排查中承接“用户视角”的关键拼图。在EC2性能卡顿的排查场景中，一个常被忽略的问题是：基础设施指标明明正常，但真实用户已经在投诉“页面打不开”。此时，CloudWatch Synthetics的Canary测试能提供最直接的证据——它模拟用户行为，对指定端点持续发起请求，并记录每一次的响应时间、成功率及失败时的截图或日志。这不再是“服务器有没有活着”的探测，而是“我的业务此刻对用户是否可用”的量化度量。

1.  Canary检测API响应延迟

我们观察到，多数团队对Canary的使用停留在简单的HTTP 200检查上，但这远不足以暴露性能退化。真正有价值的Canary脚本应该植入业务语义：调用一个涉及数据库查询、缓存读取和下游服务组装的复合API，并断言其响应时间不超过某个阈值。比如，一个订单详情接口在低峰期p95通常低于800ms，如果在非促销时段Canary检测到该接口耗时突破2000ms，且伴随Failed指标波动，那么即使EC2的CPU使用率显示只有35%，也极有可能发生了线程池耗尽、数据库慢查询或外部依赖超时。

这里有一个实践中反复验证的关键技巧：不要依赖CloudWatch的默认指标聚合。Synthetics控制台默认展示的是每分钟平均持续时间，它会掩盖瞬时毛刺。必须利用CloudWatch Metrics的Extended Statistics功能，单独拉出Canary运行时的p50、p90和p99指标。一次典型的卡顿案例中，平均响应时间仅从300ms上升到450ms，触发不了告警，但p99已经飙升至6秒，而有12%的请求失败。排查后发现是EC2实例上某个连接的Redis集群发生了选举抖动。Canary正是抓住这类间歇性故障最有效的探头——它来自外部视角，不受实例内部监控盲区的影响。

2.  模拟用户行为监控卡顿

单纯测量API延迟还不够。现代Web应用卡顿往往体现在多步交互流程的累积时延上。我们建议将Canary脚本编写为有状态的业务流程：登录获取Token → 搜索商品 → 加入购物车 → 发起结算。每一步都设定合理的超时时间和预期响应，任何一步的退化都可以单独分离，而不是笼统地报“网站慢”。在脚本中写入自定义指标（如executeStep成功计数的同时上报每一步的单步耗时），能让告警精准到具体环节。

一个不太被提及但效果显著的做法是，在VPC私有子网内部署Canary。公共网络发起的测试固然能模拟外网用户，但当排查内网性能瓶颈时——尤其是怀疑ALB到EC2、EC2到RDS之间的网络延迟——私有Canary的测量值更具诊断价值。它会经过同样的安全组、路由表和负载均衡器，如果私有Canary显示延迟正常，而公共Canary延迟异常，问题大概率出在ALB入口或CDN边缘节点；反之，如果两个指标同步恶化，则需重点检查EC2上的应用堆栈。AWS全球区域提供测试节点，但私有Canary需要附加VPC权限，并选择合适子网，这项工作无法省略。

关于测试频率，成本与发现速度之间需要权衡。每分钟一次是不少团队的默认选项，但对于排查偶发卡顿，这样的频率可能错失关键证据。如果故障持续仅40秒而恢复，每分钟的测试有60%概率采样不到。预算允许的情况下，对核心业务接口可以采用30秒甚至更短间隔，同时利用CloudWatch Composite Alarm将多个Canary任务的状态合并，避免单点误报造成告警风暴。当成功率下降至95%以下且p90延迟超过2秒时，便可触发高优先级通知。这比依靠EC2的基础资源报警更贴近业务损益，也更容易让非技术的运营团队理解当前的真实状态。

五、五、X-Ray全链路追踪定位瓶颈

当 CPU、内存和磁盘指标都指向“正常”，但终端用户依然抱怨超时，问题大概率出在调用链上——尤其是在微服务架构中，一次请求要穿过 API 网关、鉴权、订单、库存、支付等七八个服务，单点的高可用看板根本解释不了延迟的来源。X-Ray 正是在这个层面补上了关键信息缺口：它不关心虚拟机是否繁忙，而关心一个请求到底在哪个环节被“卡住”了。从多家 SaaS 团队的实践经验来看，接入 X-Ray 后定位根因的平均时间可以从小时级压缩到十分钟以内，前提是集成方式正确，并且你愿意为足够的采样精度买单。

1.  集成不是“勾选启用”，代码埋点与权限决定了追踪的完整性

一个反复出现的误判是：以为给 EC2 装好 X-Ray 守护进程、配上 IAM 角色就算完成了接入。实际上，光有守护进程只能传递由 AWS SDK 自动发起的服务端请求（比如 EC2 调用 DynamoDB），业务逻辑内部的调用——HTTP 客户端向订单服务发起的请求、SQL 查询、甚至代码中自行 sleep 的逻辑——完全不会出现在追踪图中。要让 X-Ray 真正“看清”一条链路，必须在应用代码的入口和出口处显式创建子分段。例如在 Python Flask 应用中，除了用 aws_xray_sdk 中间件捕获请求，还需要对 requests 库打补丁，或手动包装发给支付服务的 HTTP 调用；Java 用户如果使用 Spring Boot，除了引入 aws-xray-recorder-sdk-spring 外，还必须确保过滤器和拦截器没有被自定义的安全链跳过。权限方面，EC2 实例角色至少需要 AWSXRayDaemonWriteAccess 策略，但很多人忽略了子网和 VPC 端点的影响——如果 X-Ray 守护进程通过私有子网上传数据，缺少正确的 VPC 端点或 NAT 网关路由，追踪数据只会被静默丢弃，服务地图上永远看不到完整的扇出。一个值得采用的验证方法是在开发环境用 GetSamplingRules API 手动检查连通性，确认守护进程能正常接收来自 X-Ray 后端的采样规则，避免生产环境出现“没数据反而认为一切正常”的错觉。

2.  服务地图揭露的往往不是慢服务，而是藏在串行调用里的阻塞点

X-Ray 控制台的服务地图提供了极其直观的调用拓扑：每个节点代表一个微服务或外部资源，节点大小反映延迟或请求量。但我们从众多故障复盘中发现，地图上最显眼的延迟来源未必是最终需要优化的对象——它常常只是一个“受害者”。更隐蔽的问题是，表面上看各服务响应时间都在可接受范围内，但地图边缘的圆环宽度和虚线异常节点揭示出：上游在等待一个非关键的下游返回，而该下游的内部实现存在隐性串行阻塞。例如某次电商大促中，订单服务在调用风控服务的平均延迟只有 120ms，但服务地图显示订单→风控的边存在大量状态码为 429 的限流响应，进一步下钻 trace 后发现，风控内部在 5% 的请求中会同步调用一个外部信用评分 API，该 API 的 p99 延迟达到 2.3 秒。结果就是，尽管风控服务的平均性能指标“健康”，但订单服务的空闲超时却集中在这 5% 的长尾请求上，导致了用户侧不可预测的慢体验。因此，看服务地图时不应只盯住延迟最高的圈，而要结合 trace 列表按 “错误/故障” 过滤，并启用延迟分布视图，重点扫描那些延迟标准差突然放大的边——那通常是同步阻塞调用的特征。

3.  采样不是省成本的附加项，而是避免诊断失焦的控制阀

X-Ray 按记录并存储的追踪数量计费，无差别全量采样在一个中等体量（每秒数千请求）系统中会造成每分钟上百 MB 的追踪数据，这不仅会让月度账单迅速超过监控预算，更关键的是，海量的正常请求会淹没真正需要分析的异常 trace。合适的默认采样率在非调试期应当设置为 5%~10%，但切忌一概而论。更有效的做法是建立两级采样规则：例如在 sampling rule 中设定固定速率 5%，并增加一条高优先级的规则——“对响应状态码为 5xx 或延迟超过 2 秒的请求强制全量采样”。这样，正常快速请求只保留少量样本用于宏观性能画像，而所有异常慢请求都会被完整捕获。一个经常被忽略的成本陷阱是，Java SDK 如果开启了堆栈跟踪捕获（setTraceIdInjection 相关配置混乱时可能隐式开启），每一次请求的分段元数据都会膨胀数倍。我们在多个团队里验证过，关闭不必要的堆栈注入并将采样策略收敛后，X-Ray 成本可降低 60% 以上，同时诊断效率反而提升，因为 Saas 运维团队不再需要从噪音中手动筛选故障样本。

六、六、告警策略与持续性能优化

排查出一次故障的根因，只是止损的起点。真正让团队摆脱“EC2性能卡顿—紧急处理—再卡顿”循环的，是一套能反映业务真实受损程度、又能自动收窄排查范围的告警体系。过去一年我们在不同行业的上百个案例回溯中发现，超过四成的性能事故其实在恶化前就有典型信号，但要么被单一阈值忽略，要么淹没在告警噪音里，运维直到用户投诉才被动响应。下面这三件事，是把监控从“看板”升级为“免疫系统”的关键切口。

1.  复合告警规则如何配置

单指标告警的失灵，在 EC2 的卡顿场景中尤为明显。一个典型例子：T3 实例的 CPU 使用率长期稳定在 30%，业务却突然大面积超时。事后才发现 CPUCreditBalance 已耗尽，vCPU 被强制限频到基线以下，而 CPU 使用率这条曲线本身纹丝不动。这类故障如果只看 CPU，告警永远都不会触发。更有效的方法是将“现象指标”与“根因指标”绑定成复合告警。例如，当 CPUCreditBalance < 50 且应用程序 p99 延迟超过 2 秒时，才判定为需人工介入的性能劣化，这就排除了积分下降但延迟正常（比如低负载时）的误报。另一个常被忽略的组合是磁盘与内存：内存耗尽触发的大量 Swap I/O，会让 iowait 飙升而 CPU %user 未必走高。此时应该配置“EBS BurstBalance 低于 30% 同时 disk_io_await 大于 50ms”的复合告警，再通过 CloudWatch Logs Metric Filter 把“OutOfMemoryError”日志实时转成指标，作为第三个条件加入。这种三维交叉告警在实际执行中，比一刀切的“内存使用率 > 90%”早 5～15 分钟给出预警，够自动化流程完成一次优雅的进程重启或横向扩容，而不是等 OOM Killer 随机杀掉业务线程。

2.  自动伸缩应对突发负载

弹性伸缩（Auto Scaling）在很多团队手里被简化成“CPU 到 70% 就加机器”，但生产环境的突发负载往往不是计算密集型。我们见过的一个金融平台事故中，流量高峰时 CPU 利用率刚好卡在扩缩容阈值以下，但数据库连接池已用满，新上线的 EC2 实例反而拿到一连串“connection timeout”报错，实际吞吐量不升反降。所以伸缩策略必须从“盯住实例”转向“盯住业务可用性”。目标跟踪策略可以直接绑定应用程序的请求排队深度或 Canary 成功率——CloudWatch Synthetics 运行登录下单脚本，一旦 Failed 占比在 3 分钟内超过 1%，就触发伸缩组扩容，同时通过 SNS 通知 DBA 检查连接池。这种方法天然避开了 T 系列实例的 CPU 积分陷阱：积分耗尽时 CPU 使用率可能不升，但 Canary 的 Duration 指标会首先表现出 p90 恶化，足以驱动伸缩决策。此外，需要为伸缩设置“冷却期 + 步进”双重保护，避免因指标瞬时抖动反复创建和回收实例，额外加重负载均衡和数据库的冷启动压力。

3.  建立性能基线与定期巡检

临时救火能解决单点问题，却无法发现慢性退化。一个运行 18 个月的电商群集曾遇到一种诡异现象：每周三凌晨 3 点，少量订单的结算接口会规律性超时，持续时间不到 2 分钟，日常告警从未捕获。直到打开 CloudWatch Anomaly Detection，让算法学习了过去 6 周的同时段 EBS VolumeQueueLength 和 NetworkOut 波段，才发现该时段恰好是备份窗口，EBS 突发性能被短暂挤占。类似这种“常规操作导致的预期外抖动”，靠人工巡检阈值几乎不可能发现。因此，应该以周为单位建立性能基线：选取任意平稳的 7 天，采集 CPU、iowait、网络吞吐以及自定义的 p99 延迟指标，用 CloudWatch 的 Extended Statistics 生成百分位曲线，然后启用异常检测模型。之后每月定期跑一次全量检查清单：磁盘使用率超过 80% 但未配置告警的实例有多少，X-Ray 采样率是否被误调成 100% 导致追踪费用暴涨，关键业务流程 Canary 的 95% 响应时间是否偏离基线超过 20%。这些动作会比盯着红色告警更有预判价值，也让每次性能优化的效果可量化——例如优化某段代码后，能直接对比相同时段相同流量下的 p99 降低幅度，而不是只看工程师“感觉快多了”。