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 52对pg_stat_activity中运行超 30 秒的会话执行pg_cancel_backend()3将诊断报告推送到 OpsGenie 并创建 Jira Incident。这才是 CloudWatch 的价值闭环。提示很多团队卡在“采集层”就放弃了因为觉得“上报自定义指标太麻烦”。我的经验是先用 CloudWatch Agent 打包采集 OS 层指标磁盘 I/O、内存页交换再用 Embedded Metric FormatEMF让应用日志自带结构化指标。一条logger.info(order_processed, {duration_ms: 124, status: success})日志经 Agent 解析后自动产生OrderProcessed.Duration和OrderProcessed.Status两个指标零代码改造。2.2 官方文档没告诉你的“指标陷阱”维度、统计方式与延迟的三角博弈CloudWatch 的核心能力在于“维度Dimension”但它也是最容易被误用的部分。维度不是标签而是指标的“坐标轴”。CPUUtilization是一个指标名InstanceIdi-0a1b2c3d4e5f67890是它的维度值。问题来了当你为 50 个 EC2 实例设置了同一个告警规则却只写了NamespaceAWS/EC2, MetricNameCPUUtilization没有指定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 监控的“黄金三角”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-alertsDiskReadOpsDiskWriteOpsDiskReadBytesDiskWriteBytes需启用 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。NetworkIn与NetworkOut的 95 分位数P95平均值会掩盖突发流量。用 CloudWatch Logs Insights 计算 P95filter 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告警常沦为“狼来了”。真正反映数据库健康的是其内部资源消耗与请求队列状态DatabaseConnectionsvsDBInstanceClassMemory * 0.8连接数不是越多越好。每个连接占用内存约 2-4 MB取决于参数设置。DBInstanceClassMemory可从DescribeDBInstancesAPI 获取。例如db.m5.large 有 8 GiB 内存安全连接数上限 ≈ 8192 MB × 0.8 ÷ 3 MB ≈ 2185。告警阈值设为 2000持续 3 分钟。FreeableMemory 512 MB for 10 minutes注意单位是字节512 MB 536870912 字节。低于此值PostgreSQL 会开始使用 swap性能断崖式下跌。MySQL 则可能触发 OOM Killer 杀死进程。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是更精准的告警信号。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 BalancerALB 告警不是“看错误码”而是“看请求流”ALB 的指标设计哲学是“请求即一切”。HTTPCode_ELB_5XX_Count告警之所以常失效是因为它只统计 ALB 自身返回的 5XX如 502 Bad Gateway而忽略了后端返回的 5XXHTTPCode_Backend_5XX_Count。真正的 ALB 监控必须建立请求流全景视图指标名称维度关键解读黄金告警阈值HTTPCode_ELB_5XX_CountTargetGroupALB 无法连接后端502、超时504 5 per 5minHTTPCode_Backend_5XX_CountTargetGroup后端服务主动返回 5XX500、503 10 per 5minTargetResponseTimeTargetGroup后端处理请求的耗时不含网络P95 1500ms for 5minHealthyHostCountTargetGroup健康实例数 2 for 2min (if min3)特别强调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的组合Duration的 P99 与ConcurrentExecutions的关联分析Duration指标本身无意义必须结合并发数。当ConcurrentExecutions从 100 突增至 500DurationP99 从 200ms 涨到 1200ms说明函数遭遇资源争抢CPU/内存不足。此时应检查MemorySize设置Lambda 的 CPU 配额与内存成正比1792 MB 内存 ≈ 1 vCPU。将内存从 512MB 升至 1024MBCPU 配额翻倍DurationP99 常能回落 40%。Throttles 0 for 1 minute ConcurrentExecutions 90% of Account LimitThrottles表示请求被拒绝原因有两个函数级别并发限制ReservedConcurrentExecutions或账户级并发限制默认 1000。前者是主动限流后者是硬性天花板。告警必须区分若Throttles伴随ConcurrentExecutions接近账户上限需立即申请提升配额若仅接近函数预留并发则是业务流量突增应触发自动扩缩容通过 Application Auto Scaling 调整ReservedConcurrentExecutions。IteratorAgefor Event Source Mappings (Kinesis/DynamoDB Streams)当 Lambda 从 Kinesis 消费数据时IteratorAge表示记录在流中等待处理的时长。 300000 ms5 分钟即告警意味着消费者处理速度远低于生产者写入速度数据积压。此时Duration可能正常但业务 SLA 已被违反。常见误区为 Lambda 配置Errors告警时只设 0。这会导致每次重试Lambda 默认 2 次重试都触发告警。正确做法是Errors的Sum统计阈值设为 10 per 5min并确保告警EvaluationPeriods3避免瞬时抖动误报。4. 告警策略与自动化响应从“收到邮件”到“问题已修复”的完整链路4.1 告警分级不是所有告警都值得半夜打电话我把告警分为三级每级对应不同的通知渠道与响应 SLA级别触发条件通知方式响应 SLA示例P0严重影响核心业务功能用户无法完成关键路径如支付、登录电话 SMS Slack 置顶5 分钟内响应ALB HTTPCode_Backend_5XX_Count 50 per 5minP1高影响非核心功能或性能显著下降用户感知明显Slack Email30 分钟内响应RDS FreeableMemory 256 MB for 5minP2中系统资源预警或非关键组件异常无直接影响Email Internal Dashboard2 小时内响应EC2 StatusCheckFailed_Instance 1 for 2min关键原则P0 告警必须 100% 自动化无需人工介入即可缓解。例如P0 级别的RDS CPUUtilization 95% for 5min不应只发电话而应触发 Lambda 执行1调用ModifyDBInstance升级实例规格2修改DBParameterGroup启用log_min_duration_statement10003向 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 连接数过高为例State 1检测CloudWatch Alarm 触发 Step Function输入包含DBInstanceIdentifier和当前DatabaseConnections值。State 2诊断Lambda A 调用DescribeDBInstances获取DBInstanceClass和DBParameterGroup再调用DescribeDBParameters检查max_connections参数。若当前连接数 max_connections × 0.9进入修复否则发送“误报”通知。State 3修复Lambda B 执行修改DBParameterGroup临时增大max_connections需重启生效故下一步调用RebootDBInstance强制重启对 Multi-AZ 为故障切换无停机启动 CloudWatch Logs Insights 查询提取最近 1 小时slow_log中Rows_examined 10000的 SQL。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 DBInstanceStatusfailed、ALB HealthyHostCount0会同时告警形成信息轰炸。必须用告警抑制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上报一个MaintenanceMode1自定义指标并在所有告警的Metrics中添加ExpressionIF(MaintenanceMode 1, 0, OriginalMetric)。这样维护期间所有告警值被强制设为 0永不触发。基于事件桥接抑制将 CloudWatch Events现为 EventBridge与告警联动。当RDS DBInstanceStatusfailed事件发生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 小时的手动日志翻查。定位“偶发超时”的真实原因当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 次远超其他错误。根因瞬间锁定为数据库连接池耗尽。分析“用户投诉慢”的请求链路结合 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的耗时精确到毫秒级。识别“爬虫攻击”的流量特征当ALB HTTPCode_ELB_4XX_Count暴涨快速识别恶意 UAfilter 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带servicepayment-service, versionv2.1维度MyApp/Payments.SuccessCount同上维度从此你不再需要PutMetricDataAPI日志即指标。支付成功率可直接用SuccessCount / (SuccessCount FailureCount)计算且天然具备所有日志的维度如按countryCN过滤。注意EMF 日志必须是单行 JSON且_aws.CloudWatchMetrics字段必须存在。测试时用aws logs test-metric-filter验证日志是否被正确解析。6. 成本优化与陷阱规避那些让你账单翻倍的“隐形开关”6.1 CloudWatch 的 4 个成本黑洞及应对方案CloudWatch 成本常被低估尤其在高吞吐场景。我帮你揪出最易忽略的四大黑洞Detailed Monitoring 的“甜蜜陷阱”EC2/RDS 启用 Detailed Monitoring1 分钟粒度后指标数量激增 5 倍5 分钟 → 1 分钟。但 90% 的场景5 分钟粒度已足够。对策仅对核心生产实例启用 Detailed Monitoring开发/测试环境一律禁用。用aws ec2 monitor-instances --no-dry-run批量关闭。日志保留期的“永久存储”幻觉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 }Logs Insights 查询的“无限扫描”每次 Logs Insights 查询按扫描的数据量计费$0.005/GB。一个未加时间过滤的filter message like /ERROR/查询可能扫描数月日志单次费用 $50。对策在控制台右上角强制设置默认时间范围如 Last 15 minutes在代码中调用start-query时必须传入startTime和endTime。自定义指标的“高频上报”每个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 “告警不触发”问题排查速查表现象可能原因排查命令/步骤解决方案告警状态始终INSUFFICIENT_DATA指标无数据上报aws cloudwatch list-metrics --namespace AWS/EC2 --metric-name CPUUtilization检查 EC2 是否启用 Detailed Monitoring确认实例角色有cloudwatch:PutMetricData权限告警状态ALARM但无通知SNS 主题无订阅者或订阅未确认aws sns list-subscriptions-by-topic --topic-arn arn:aws:sns:...检查订阅者邮箱是否点击确认链接确认 SNS 主题策略允许 CloudWatch 发布告警频繁在OK和ALARM间抖动阈值过于敏感或统计周期过短查看告警的EvaluationPeriods和DatapointsToAlarm增加EvaluationPeriods如从 1 改为 3要求连续 3 个周期达标才触发自定义指标不显示在控制台指标命名含非法字符空格、斜杠aws cloudwatch list-metrics --dimensions Nameservice,Valuepayment指标名仅支持字母、数字、点、下划线、连字符维度值同理独家技巧用aws cloudwatch get-metric-alarm-history查看告警状态变更历史精确到毫秒。比控制台的“最近活动”更详细。7.2 “日志查不到”问题的 3 个致命疏漏CloudWatch Agent 配置中的force_flush_intervalAgent 默认每 10 秒刷一次日志到 CloudWatch。若实例在 5 秒时宕机这 5 秒日志永远丢失。解决方案在
 获取与实战)
