亚马逊云支付验证 AWS亚马逊云监控报警自定义

你有没有经历过这样的深夜——手机突然狂震三下，打开一看：「EC2实例CPU使用率持续5分钟超92%」。你一个激灵坐直，抓起咖啡灌一口，手指发颤点开控制台……结果发现，这台实例压根儿是测试环境里被遗忘的“僵尸机”，连SSH都连不上。报警没错，但报了个寂寞。

这就是典型的「告警疲劳」现场：不是没监控，而是监控太糙；不是没报警，而是报警太蠢。AWS CloudWatch 像个尽职但有点耳背的老管家，你得亲自教它听什么、怎么听、听到后该吼多大声、吼完找谁来救火——而不是指望它自动猜中你的心思。

今天咱不聊概念复读机，也不贴官方文档截图充数。咱们就坐下来，泡杯茶（或续命咖啡），用真实操作、真实翻车、真实解法，把「AWS亚马逊云监控报警自定义」这件事，从头到脚盘明白。

一、先别急着建告警，搞懂三个「人话」概念

1. 指标（Metric）不是数据，是「被提炼过的情报」
你在EC2上跑top命令看到的CPU%，是原始数据；CloudWatch里叫CPUUtilization的那个指标，是AWS每60秒采样一次、聚合为平均值、打上实例ID和区域标签后封装好的情报包。它自带时间戳、维度（Dimension）、单位（Percent）、统计周期（1/5/15分钟）。选错维度？比如把InstanceId写成InstanceID（大小写敏感！），告警直接变哑巴。

亚马逊云支付验证 2. 告警（Alarm）不是触发器，是「带记忆的裁判」
很多人以为“CPU > 80% 就报警”——错。CloudWatch告警默认需要「连续N个周期满足条件」才真正触发。比如你设了「5分钟周期 × 3次连续超阈值」，那实际要等15分钟确认真出事了，才拉响警报。这是防抖，不是延迟。想秒级响应？可以调成1分钟周期+1次触发，但小心误报炸群。

3. 动作（Action）不是发消息，是「指定谁来接单」
告警状态变ALARM时，CloudWatch能干的事只有三件：发SNS通知、自动伸缩组扩缩容、发事件给EventBridge。它不会帮你重启实例、不会执行Lambda、更不会给你老板发微信——除非你用SNS兜一圈，再让Lambda监听SNS主题来干活。记住：CloudWatch只喊人，不干活。

二、动手前必做的四件事（少一步，后面全白搭）

① 创建SNS主题并订阅邮箱/短信/钉钉（推荐先用邮箱）
别跳过！很多新手卡在这步，告警明明触发了却收不到通知，最后发现SNS根本没订阅成功，或者邮箱被当成垃圾邮件过滤了。验证订阅时，务必点开邮件里的确认链接——那个链接24小时失效，过期就得重来。

② 给CloudWatch加权限（IAM策略别偷懒）
如果你用的是自定义IAM角色，检查是否含cloudwatch:PutMetricAlarm和cloudwatch:DescribeAlarms。最省事方案：直接附加CloudWatchFullAccess策略（测试环境OK，生产环境请精细化授权）。

③ 确认指标已上报（别监控空气）
进CloudWatch控制台 → Metrics → All metrics → EC2 → Per-Instance Metrics。如果列表里压根看不到你的实例ID，说明基础监控没开！去EC2控制台选中实例 → Actions → Monitor and troubleshoot → Enable detailed monitoring（每1分钟采样，收费；基础监控是5分钟，免费但颗粒度粗）。别心疼那几毛钱，救命时刻差那4分钟可能就是P0事故。

④ 拿到实例的「精确维度」
别凭记忆写{"InstanceId": "i-12345abc"}。进Metrics页面，点开你要监控的指标 → 右上角「Add to dashboard」→ 查看URL里那段dimensions=%7B%22InstanceId%22%3A%22i-12345abc%22%7D，URL解码后才是你该抄的维度JSON。大小写、引号、空格，一个都不能错。

三、命令行党最爱：一条aws cli搞定告警创建

比网页点十次鼠标还快，且可存Git、可批量生成：

aws cloudwatch put-metric-alarm \
  --alarm-name "prod-api-cpu-high" \
  --alarm-description "CPU超过85%持续3个周期（15分钟）" \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --threshold 85 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 3 \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:my-alerts-topic \
  --dimensions Name=InstanceId,Value=i-0abcdef1234567890 \
  --unit Percent

⚠️ 注意坑：
• --period 和 --evaluation-periods 决定总检测时长（300秒×3=15分钟）
• --statistic 必须是Average/Maximum/Minimum/Sum/Count之一，别写“Avg”
• SNS ARN必须和告警在同一区域（跨区不转发！）
• 如果要监控Auto Scaling Group，维度得换成Name=AutoScalingGroupName,Value=my-asg

四、进阶技巧：让告警更聪明的三招

✓ 多指标联合判断（告别单一阈值幻觉）
CPU高但NetworkIn低？可能是死循环。CPU高且DiskReadOps也爆表？大概率是慢SQL拖垮IO。用CloudWatch Synthetics或自定义指标上报业务关键数据（如订单处理延迟），再建「AND」逻辑告警：ALARM when (CPU > 90% AND Latency > 5000ms)。这得用CloudWatch Embedded Metric Format（EMF）或Lambda打点实现。

✓ 动态阈值（拒绝「一刀切」）
电商大促时CPU 70%算健康，平时就是红色警报。CloudWatch支持「异常检测模型」：选指标 → Create alarm → 钩选「Use anomaly detection」→ 它会基于历史数据自动画出±2σ波动带。比固定阈值靠谱十倍，尤其适合有明显波峰波谷的业务。

✓ 告警静默（下班不背锅的尊严）
每周五晚8点到周日早10点，运维同学需要睡觉。用EventBridge规则+Lambda，在时段开始前把告警设为DISABLED，结束后再ENABLED。或者更简单：在SNS主题里加个过滤策略，让非工作时间的通知直接丢弃（需SNS主题启用消息过滤）。

五、最后送你一句保命口诀

「指标要准、维度要死、阈值要试、动作要验、日志要看」
——新建告警后，立刻手动触发一次（比如在实例上跑yes > /dev/null拉高CPU），盯着CloudWatch Alarms页面看状态变色，查SNS收信，翻CloudWatch Logs看Lambda执行痕迹。没验证过的告警，和没装保险丝的电箱一样危险。

监控不是为了填合规表格，也不是为了在复盘会上甩锅截图。它是你系统沉默的哨兵，是你凌晨三点最可靠的战友。而自定义告警的过程，本质上是在教这个哨兵：什么是真正的危险，谁该第一个被叫醒，以及——什么时候，该闭嘴让你睡个好觉。

现在，去你的AWS控制台，删掉那个叫“test-alarm-001”的幽灵告警，然后，亲手建一个真正管用的。