北京
运维过EC2的工程师都经历过这种时刻：实例跑着Nginx，默认的CloudWatch仪表盘上CPU、网络吞吐、磁盘I/O都正常，一条报警也没响，但用户已经在反馈页面加载变慢了。翻开操作系统一看，内存用了90%，根磁盘只剩几百兆，Nginx进程不知什么时候挂掉，错误日志里已经堆了半天的警告。默认监控把这些全漏了——它只能站在虚拟机外面看，内部发生什么一概不知。
这次我们直接用CloudWatch Agent搭一条管穿内外的观测管道，把里面看不见的数字全拉出来。整体的信息流很清晰：EC2实例内跑着Agent，它读取操作系统的内存占用、磁盘使用量，还紧盯着Nginx的access和error日志，然后把指标和日志分别推给CloudWatch Metrics和Logs；上层再用Dashboard汇成一张视图，配上Alarm的阈 值触发和SNS的邮件通知。整个链路从实例肚子里出发，到告警发到手机上，没有一句是靠猜的。
Agent的价值很简单：EC2 basic monitoring看到的是hypervisor给出的一层壳，所以能抓到CPU steal time、网络包数、磁盘吞吐，但永远够不着操作系统里面的内存、文件系统容量、进程存活状态、应用日志这类信息。一旦把这层壳敲开，Agent以守护进程的形式直接跑在实例上，就能实时把真正的运行状况推出来。想让内存告警、磁盘告警、日志里特定关键词告警真正生效，这步是绕不开的。
这次实验拆成了两个场景。第一种是已经在线运行Nginx的EC2实例，之前没装Agent，直接补装、配置、串联告警，看的是对存量环境的零停机接入；第二种是从零创建实例，把Agent的安装和配置写进User Data，启动那一刻起观测就随实例一起就位。两种方式跑完，对应的证据页会分别看到IAM角色附加、SSM托管节点在线、Agent安装状态、cwagent指标上报、Dashboard表单和告警邮件到达的全流程截图，让每一步都有迹可循。
整个架构刻意避开了SSH，实例的远程操作全部走Systems Manager Session Manager，端口不开、密钥对不用，只靠IAM精细控制权限。Agent配置里要重点关心的是磁盘指标——比如根分区使用率、内存指标、Nginx日志的采集路径和格式解析规则，这些直接决定最终Dashboard和告警的数据准确度。当某条error log突然暴增、或者内存连续5分钟破80%时，SNS的邮件通知会立刻把提示推到面前，这时候才觉得之前的盲区终于被补上了。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
