选择计算实例性能监控指标，不宜把所有能采集的数据都放进告警面板。先明确要发现什么问题：资源是否耗尽、性能是否变差，还是实例本身不可用。再围绕这些问题选择少量可解释、可行动的指标。
先覆盖四类基础资源
| 类别 | 建议观察 | 判断时注意 |
|---|---|---|
| CPU利用率 | 使用率、负载、运行队列 | 高使用率不一定等于故障；若持续偏高并伴随请求变慢，才更值得排查。 |
| 内存使用率 | 可用内存、交换空间活动、内存回收情况 | Linux 会将空闲内存用于缓存，不能只看“已用”数字；持续换页通常比缓存占用更能说明压力。 |
| 磁盘I/O | 读写量、队列长度、操作延迟 | 吞吐高低受设备类型和读写模式影响，需与实例自身正常时段比较。 |
| 网络吞吐量 | 收发速率、丢包、错误包、连接状态 | 流量未到带宽上限也可能出现丢包或连接问题，应同时查看错误与应用响应。 |
这四类构成计算实例性能监控指标的基础清单。若实例承载服务，再补充服务可用性和请求延迟；若只是批处理任务，则可关注任务运行时长、失败次数和队列积压，不必套用同一套告警。
按场景补充，而不是堆满面板
交互式服务
除资源项外，记录成功率、响应延迟及并发量。比如系统指标稳定但延迟突然升高，应继续检查进程线程、依赖服务或请求分布。可将平均值与高分位延迟并看，避免少量慢请求被平均值掩盖。
计算或批处理任务
关注单次任务耗时、CPU时间、内存峰值和失败重试。若任务常因内存不足退出，增加磁盘吞吐监控未必能解决问题；先核对退出日志与资源峰值，定位瓶颈后再调整实例规格或任务并发。
Linux 可用 vmstat观察运行队列和交换活动，用 iostat查看设备读写与延迟；Windows 环境可通过“性能监视器”查看处理器、内存和磁盘计数器。Prometheus、Grafana 等工具可用于采集和展示，但采集频率、保留周期应按排障需要和存储成本确定。
把指标变成可执行告警
- 建立基线：按实例和工作时段观察一段正常运行数据，区分日常波动与异常；部署、批量任务等时段应单独标记。
- 设持续条件：可把 CPU 使用率持续超过约 80%、内存可用比例低于约 10%–15%作为初始观察线，持续时间可先设为数分钟。它们只是常见起点，需结合负载、操作系统和容量调整。
- 增加关联条件：CPU 告警同时检查运行队列或延迟；内存告警同时检查换页；磁盘告警同时检查延迟和队列，减少单一指标引起的误报。
- 指定处理动作：告警应说明影响对象、时间范围和排查入口。先确认实例状态与近期变更，再查看对应资源和应用日志，避免只收到一个孤立数字。
最终的计算实例性能监控指标清单应能回答三个问题：哪里变差、何时开始、下一步查什么。先从基础资源和服务表现各选少数关键项，再根据真实故障复盘增删，比一次配置大量阈值更容易维护。
常见问题
所有实例都应使用相同阈值吗？
不应。实例规格、操作系统、负载模式和业务时段不同，应先建立各自基线，再设阈值。
CPU 使用率高就需要扩容吗？
不一定。若任务按预期利用 CPU 且响应正常，可能无需处理；若高使用率持续并伴随排队或延迟恶化，再排查并发、程序效率和容量。
只监控主机资源够不够？
不够。资源指标说明实例状态，服务可用性、请求延迟或任务结果才能体现用户或作业是否受到影响。
采集频率应该设多高？
没有通用固定值。较短间隔有利于捕捉突发问题，但会增加数据量；可按告警响应要求和排障精度选择，并保持各实例口径一致。