亚马逊云新加坡账号 AWS亚马逊云服务器云监控插件使用
别再让服务器‘黑盒运行’：AWS云监控插件不是选修课，是保命课
朋友，你有没有经历过这种深夜惊魂？凌晨两点，用户疯狂投诉APP卡顿，你冲进控制台一看——CPU 99%、磁盘IO爆表、RDS连接数打满……可问题是什么时候开始的？谁触发的？哪台实例扛不住了？你翻遍日志，像在沙滩上找一根针。更扎心的是，等你连上SSH，服务已经自动恢复了——仿佛系统在跟你玩捉迷藏。
这不是玄学，是监控没到位。AWS自带的CloudWatch不是摆设，但默认只盯着EC2基础指标（CPU、内存、网络），像只给你一副望远镜却塞进抽屉里。真正让它活起来的，是那个叫CloudWatch Agent的插件——它不是什么高冷黑科技，说白了，就是个勤快又记性的“云上哨兵”，能钻进Linux/Windows肚子里，把进程、磁盘、Nginx请求、MySQL慢查询全摸清楚，再打包发给CloudWatch。今天，咱们就把它从说明书里拽出来，擦干净、装上、调好、用熟。
先搞懂三件事：Agent ≠ CloudWatch，也≠ System Manager
1. CloudWatch是‘大脑’，Agent是‘手脚’
CloudWatch本身不主动采集数据，它只负责收、存、画图、告警。就像公司HR不自己去车间盯工人，得靠班组长（Agent）每天报工时、报故障、报产量。没Agent，CloudWatch只能看到EC2外壳温度（基础指标），有了它，才能切开肚子看内脏（应用层指标）。
2. 不是所有Agent都叫‘官方推荐’
AWS历史上出过三款监控工具：旧版CloudWatch Monitoring Scripts（Python脚本，已弃用）、SSM Agent（主打远程管理，监控只是副业）、以及现在的CloudWatch Agent（aka Amazon CloudWatch Agent）。后者才是亲儿子，支持JSON配置、跨平台、细粒度权限、无缝对接Logs和Metrics。别被网上那些教你怎么跑Python脚本的老文章骗了——它们写的可能是三年前的古董。
亚马逊云新加坡账号 3. 安装≠完事，配置才是灵魂
很多人装完Agent就以为大功告成，结果Dashboard里空空如也。真相是：Agent默认只传基础指标！你想看NGINX每秒请求数？得手动告诉它“去/var/log/nginx/access.log里扒日志”；想监控Java堆内存？得加JVM参数并配置收集路径。它不猜你的需求，你得写明白——就像点外卖，不能只说“我要吃的”，得说“要辣子鸡丁盖饭，少油，米饭多一勺”。
动手实操：三步装好Agent，拒绝复制粘贴式失败
第一步：权限——给Agent一张‘身份证’
别急着敲命令！先去IAM创建一个角色，叫CloudWatchAgentServerPolicy（名字随意，但策略必须精准）。重点来了：这个角色必须附加两个托管策略：CloudWatchAgentServerPolicy（专为Agent设计，允许写Metrics/Logs）+ AmazonSSMReadOnlyAccess（Agent启动时会查SSM状态）。如果你图省事直接给AdministratorAccess，恭喜，你刚给黑客开了后门。
第二步：安装——Linux一行，Windows两键
Linux（Ubuntu/CentOS）：
sudo apt-get update && sudo apt-get install -y awscli
curl https://s3.amazonaws.com/amazoncloudwatch-agent/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb -o amazon-cloudwatch-agent.deb
sudo dpkg -i amazon-cloudwatch-agent.debWindows：去AWS官网下.msi包，双击安装，勾选“Install as a Windows Service”——别漏这步，否则重启就消失。
第三步：配置——用JSON写‘监控任务清单’
Agent不吃YAML，只认JSON。生成配置最稳妥的方式是用amazon-cloudwatch-agent-config-wizard交互式向导（Linux下执行即可）。但向导生成的配置太保守，我们得手动升级：
{
"agent": {
"metrics_collection_interval": 60,
"run_as_user": "root"
},
"metrics": {
"metrics_collected": {
"cpu": {"measurement": ["cpu_usage_idle", "cpu_usage_iowait"]},
"disk": {"measurement": ["used_percent"], "resources": ["/"]},
"mem": {"measurement": ["mem_used_percent"]},
"nginx": {"measurement": ["nginx.net.connections", "nginx.http.request.count"]}
}
},
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/var/log/nginx/access.log",
"log_group_name": "nginx-access",
"log_stream_name": "{instance_id}"
}
]
}
}
}
}关键点：log_stream_name里的{instance_id}是占位符，Agent会自动替换，避免不同实例日志混在一起；nginx模块需提前在Nginx配置中开启stub_status，否则指标为空——这点90%的教程不说，导致你配完发现Dashboard全是0。
告警不是‘设置阈值就完事’，是场精密博弈
别再用“CPU > 80% 持续5分钟”这种粗暴规则了！现实很骨感：某次大促，CPU冲到95%但业务丝滑；另一次，CPU才60%，因磁盘IOPS耗尽，整个API响应超时3秒。正确姿势：
- 组合条件：告警触发 = (CPU > 85% AND disk_io_time > 90%) OR (http_5xx_count > 10/min)
- 冷静期：告警后30分钟内重复触发只通知1次，避免微信轰炸
- 分级响应：P0级（数据库连接池满）→ 电话+钉钉；P1级（Nginx 502增多）→ 钉钉+邮件；P2级（磁盘剩余10%）→ 邮件+企业微信
实操命令（创建复合告警）：
aws cloudwatch put-metric-alarm \
--alarm-name "DB-Connection-Exhausted" \
--alarm-description "RDS连接数超95%" \
--metric-name "DatabaseConnections" \
--namespace "AWS/RDS" \
--statistic "Average" \
--period 60 \
--threshold 95 \
--comparison-operator "GreaterThanThreshold" \
--dimensions Name=DBInstanceIdentifier,Value=my-prod-db \
--evaluation-periods 2 \
--alarm-actions arn:aws:sns:us-east-1:123456789012:prod-pagerduty排障锦囊：当Agent‘装死了’，怎么救？
- 日志在哪？ Linux：/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log；Windows：C:\ProgramData\Amazon\AmazonCloudWatchAgent\Logs\
- 常见死法：
• 报错failed to get instance identity document→ IAM角色没绑定或过期；
• 指标全为0 → 检查配置中resources路径是否写错（如/mnt/data写成/data）；
• 日志不上传 → 确认Log Group存在，且Agent有logs:CreateLogStream权限。 - 终极检查法：运行
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m fetch-config -s -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json，看输出是否显示Configuration validation first phase passed。
最后送你一句大实话
监控插件不会让你升职加薪，但它能让你在故障发生前喝杯咖啡，在故障复盘时理直气壮说‘早发现了’，在老板问‘为什么没预警’时，掏出截图甩出精确到秒的告警记录。技术人的体面，有时就藏在那一行没报错的日志里，和那个稳稳亮着绿灯的CloudWatch Dashboard中。现在，去你的EC2上，敲下第一行sudo systemctl start amazon-cloudwatch-agent吧——这次，别让它再睡着了。
