阿里云国际 ECS 监控告警怎么配置？CPU、内存、磁盘与通知排查

阿里云国际 ECS 监控告警的关键，不是把所有指标都设成同一个阈值，而是先确认监控数据来自哪里，再让告警能够准确到达负责人。ECS 控制台默认可以查看 CPU、磁盘 I/O、网络等基础指标；内存、磁盘使用率和进程等操作系统指标，则需要 CloudMonitor Agent 正常运行。

一套可用的告警流程至少包含四个环节：指标持续上报、规则连续触发、联系人组能够接收通知、收到通知后可以沿实例与时间窗口定位原因。任何一环缺失，都可能出现“业务已经异常，但没有收到有效告警”。

基础监控和操作系统监控有什么区别

• 基础监控：无需在实例内安装 Agent，可查看 CPU 利用率、网络流量、云盘 IOPS 和吞吐等云资源指标；
• 操作系统监控：由 CloudMonitor Agent 在实例内采集，常见内容包括内存、文件系统使用率、负载和进程信息；
• 事件监控：用于关注实例系统事件、运维事件或服务异常，不应由资源阈值告警代替；
• 日志与应用监控：HTTP 错误率、接口延迟、业务队列等应用指标，需要日志、APM 或自定义监控补充。

CPU 很低不代表业务一定健康：进程可能退出、磁盘可能只读、域名可能解析错误，应用也可能持续返回 5xx。基础资源告警是底线，不是完整可用性监控。

先建立告警联系人和联系人组

1. 进入 CloudMonitor 控制台的 Alert Service；
2. 创建告警联系人并填写真实可用的通知方式；
3. 完成需要的验证，再建立联系人组；
4. 将值班人员或业务负责人加入联系人组；
5. 使用一条可控的测试规则验证通知链路。

规则中选择的是联系人组，而不是“创建后自然会通知所有管理员”。人员调整时应维护联系人组，避免规则仍指向已离职或停用的联系方式。用于自动化处理时，可以配置公网可访问的 HTTP 回调地址，但回调服务本身要验证来源、限制权限并具备重试和审计能力。

CloudMonitor Agent 怎么安装和验证

在 CloudMonitor 的 Host Monitoring 页面找到目标 ECS，优先使用控制台自动安装。官方当前推荐 C++ 3.X Agent；自动安装依赖 Cloud Assistant，安装通常需要数分钟，状态变为 Running 后才表示采集端正常。

Linux 可以用以下只读命令确认进程是否存在：

ps aux | grep argusagent | grep -v grep

如果需要确认实例所在地域，可从实例元数据服务读取：

curl http://100.100.100.200/latest/meta-data/region-id

执行安装和服务管理需要 root 或 Windows Administrator 权限。Agent 不上报时，应依次检查 Cloud Assistant、Agent 进程、DNS、出站网络以及安全组或系统防火墙，而不是反复创建相同告警规则。

第一批告警应该覆盖哪些指标

• CPU：关注持续高负载，不要因单个采样点尖峰频繁通知；
• 内存：结合可用内存、Swap 和 OOM 记录判断，避免只看单一百分比；
• 磁盘使用率：为系统盘、日志盘和数据盘分别设置规则，并关注 inode；
• 网络：以实例带宽和历史基线为参照，区分业务增长、攻击和异常出站；
• 实例与系统事件：订阅停机、维护或故障相关事件，避免只监控性能曲线；
• 应用可用性：补充端口、HTTP 状态码、延迟和关键业务动作探测。

阈值不能脱离实例规格和业务基线。持续运行的计算任务与面向用户的 Web 服务，对 CPU、延迟和通知时效的要求不同。建议先观察一段有代表性的历史数据，再按业务风险配置不同级别。

自定义告警规则怎样配置

1. 进入 CloudMonitor 的 Alert Rules，选择 Create Alert Rule；
2. 产品选择 ECS，并确定作用于全部资源、应用分组还是指定实例；
3. 选择指标、统计方式、阈值和连续周期；
4. 设置生效时段、告警级别和静默周期；
5. 选择已经验证的告警联系人组；
6. 保存后用受控方式触发一次，并验证恢复通知。

“连续周期”用于过滤瞬时抖动，“静默周期”用于控制同一异常持续存在时的重复通知频率。静默周期不是忽略故障；值班流程仍需记录告警是否被确认、处理和恢复。

多指标组合规则要求目标资源上报规则中的每项数据。如果组合了公网网络指标，但实例没有公网 IP，对应数据可能不存在，整条组合规则便无法按预期触发。首次配置时，应先用单指标验证数据和通知，再逐步增加组合条件。

按全部资源、应用分组还是单台实例

• 全部资源：适合统一底线规则，新增加的 ECS 也能被覆盖，但需避免开发机制造噪声；
• 应用分组：适合按生产、测试、业务系统或负责人管理不同阈值；
• 指定实例：适合数据库、网关或单台关键节点的专属规则，维护成本较高。

长期运营时，建议使用标签或应用分组表达环境和责任归属。例如生产与测试不要共用同一通知强度，临时实例也不应长期留在关键业务联系人组里。

为什么监控有数据却没有收到告警

1. 确认规则状态、生效时间和资源范围；
2. 确认选择的指标确实有连续数据，而不是图表中的历史数据；
3. 核对统计方式、连续周期、告警级别和阈值方向；
4. 检查是否仍处于静默周期；
5. 确认联系人组非空，通知方式已经验证；
6. 查看告警历史，区分“未触发”和“已触发但未送达”；
7. 检查邮件拦截、回调响应和通知渠道状态。

不要为了测试而把生产实例长时间压到极限。可以在测试实例上设置临时、容易恢复的阈值，确认触发和恢复通知后再删除测试规则。

为什么内存或磁盘使用率没有数据

内存和文件系统使用率通常依赖 CloudMonitor Agent。没有数据时按以下顺序排查：

1. 在 Host Monitoring 页面确认 Agent 状态是否为 Running；
2. Linux 检查 argusagent 进程，Windows 检查对应服务；
3. 确认 Cloud Assistant 正常，自动安装命令能够下发；
4. 检查实例能否解析并访问 CloudMonitor 心跳和数据上报地址；
5. 检查出站安全组、系统防火墙、NAT 或代理设置；
6. 等待新的采样周期，再核对图表时间范围与实例地域。

基础 CPU 或网络指标仍存在，而内存、文件系统和进程指标同时缺失，通常应优先检查 Agent；所有指标同时中断，则还要核对实例状态、地域选择和平台侧事件。

收到告警后怎样形成处理闭环

1. 记录实例 ID、地域、指标、触发时间、持续周期和当前值；
2. 对照同一时间的 CPU、内存、磁盘、网络和系统事件；
3. 进入实例检查进程、系统日志和应用日志；
4. 先止损，再判断优化配置、扩容还是修复应用；
5. 恢复后确认指标回落和恢复通知；
6. 复盘阈值是否过敏、漏报或缺少责任人。

例如 CPU 持续升高时，要区分正常计算任务、流量上涨、死循环和异常进程；磁盘使用率升高时，要继续确认日志、临时文件、数据库或容器层实际占用。只重启实例会丢失现场，也无法消除根因。

常见问题

安装 CloudMonitor Agent 会重启 ECS 吗？

官方说明，安装 Agent 不需要重启 ECS，安装完成后会自动采集数据。生产环境仍建议在低峰期操作，并在安装后检查进程和业务状态。

为什么 CPU 有数据，内存没有数据？

CPU 等基础指标不依赖 Agent，而内存和文件系统等操作系统指标依赖 Agent。应先检查 Host Monitoring 中的 Agent 状态、进程和出站网络。

一个瞬时尖峰要不要立即告警？

取决于业务。通常应结合统计方式和连续周期过滤短暂波动，但交易、网关等敏感业务可能还需要更快的应用可用性告警，不能套用统一阈值。

CloudMonitor 告警能代替业务监控吗？

不能。它能覆盖资源与系统层异常，但不能自动判断登录、下单、支付回调或 API 返回内容是否正确，关键业务仍要补充日志、链路和外部探测。

官方资料

• Alibaba Cloud：ECS monitoring and logging
• Alibaba Cloud：Set up host monitoring
• Alibaba Cloud：Install and uninstall the CloudMonitor agent
• Alibaba Cloud：Create an alert rule
• Alibaba Cloud：Configure ECS alert rules

如果需要确认阿里云国际 ECS 的账号、ID 充值或基础运维方向，可以通过 Telegram 联系 @heishayun。排查监控问题时，请提供地域、实例 ID、缺失指标、时间范围和脱敏后的 Agent 状态，不要发送账户密码。