01 它是干嘛的
CloudWatch 是 AWS 的监控与观测服务：把云上各个资源的运行状况集中收集起来，包括数值型的指标（CPU 使用率、请求数）、文本型的日志，以及可以自由查询的分析。它最直接的价值是让你在用户察觉之前发现问题，而不是等投诉进来才手忙脚乱地去查。
02 为什么会有它
机器越多，人反而越「瞎」
一台服务器的时候，出问题登上去看看日志就行了；但当机器变成几十上百台、服务拆成许多个，这种方式立刻失效——没有人能一台台登录去看，等你发现异常，往往已经是用户在投诉了。
更麻烦的是「没有对比就没有判断」。CPU 用到百分之八十算异常吗？不知道，因为你不清楚它平时是多少。没有历史数据，故障排查全靠猜；没有告警，问题只能靠运气发现。
监控服务的思路是给整套系统装上统一的仪表盘：所有资源自动上报数据，超过阈值立刻报警，出问题时能翻出完整的历史记录对比。这样工程师不必守在机器前，也能第一时间知道哪里不对、从什么时候开始不对、当时发生了什么。它把「出了问题才知道」变成「问题刚冒头就被发现」。
03 它怎么工作
监控的流程可以概括为：收集、观察、判断、通知。资源把运行数据源源不断地上报，平台按规则持续观察，一旦越过你设定的界线，就立刻通过预设渠道通知相关人员。
从数据上报到触发告警的完整链路
- 1① 各类资源自动上报指标
云上的服务器、数据库、队列等会自动把运行数据（如占用率、延迟、请求数）定时上报，无需手工配置。
- 2② 应用与系统日志被集中收集
程序打印的日志被统一汇聚到一个地方，不再散落在各台机器上，排查时只需查一处。
- 3③ 设置阈值告警
例如「错误数连续五分钟超过一百就报警」。阈值可以定得细一些，避免频繁误报让人麻木。
- 4④ 越线即通知或自动处理
告警可以通过邮件、短信或消息服务发出；也可以直接触发自动扩容等动作，让系统自己先稳住。
- 5⑤ 用仪表盘与日志查询做复盘
把关键指标放上仪表盘一屏看清；出问题时用查询语句在日志里快速定位「什么时候、哪台机器、报了什么错」。
04 谁在用它
实时观察服务器的占用率、接口的成功率与响应时间，异常第一时间知晓。
当平均 CPU 长时间偏高时自动增加机器，回落后再自动减少，实现无人值守的弹性。
把多台机器的日志汇聚在一起，用查询语句快速找出报错位置，不必逐台登录。
监控各项资源的使用趋势，及时发现闲置资源与异常增长，控制账单。
把订单量、注册数等业务数字也做进仪表盘，让技术团队与业务团队看同一块屏幕。
05 怎么用
基础监控基本都是自动生效的，你真正要花心思的是「设什么告警、报给谁」。
- 01打开控制台确认基础指标已在自动收集，先看看有没有明显异常。
- 02为关键服务建立仪表盘，把最重要的几个指标放在一屏，方便日常扫一眼。
- 03设置告警：先定一个绝对明显异常的阈值，稳住之后再逐步调细。
- 04指定告警触发后通知谁、通过什么渠道，确保消息能送到真正能处理的人手上。
- 05需要自动弹性时，把告警与自动伸缩策略关联起来，让系统自己扩缩容。
- 06定期用日志查询复盘历史故障，把常见问题的排查步骤沉淀成固定套路。
# 查询最近 1 小时内的错误日志，按时间倒序取前 20 条
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20避坑提示
- !告警设得太敏感会让人麻木：天天响的警报很快会被无视，反而错过后面的真问题。
- !日志是要收费的：高频而无用的打印会迅速推高成本，容易出问题的关键路径再打详细日志。
- !监控要覆盖「用户视角」：机器指标正常不等于用户能用，最好同时监控接口成功率与响应时间。
06 关键概念
- 指标
- 随时间变化的数值，如占用率、请求数、响应时间，用来看「有没有异常」。
- 日志
- 程序运行时打印的文字记录，用来看「具体出了什么错」。
- 告警
- 给某个指标设定界线，越线就自动通知，不必人工一直盯着。
- 仪表盘
- 把最重要的若干指标放在一屏的看板，方便一眼扫过全局。
- 自动伸缩
- 根据监控到的负载自动增加或减少机器，让系统自己应对流量变化。