判断虚拟化实例是不是“额度不够”，不能只看 CPU 使用率。虚拟化实例突发性能额度的识别与监控，关键是同时核对实例类型、基准性能、额度余额和业务响应情况。AWS 的 T 系列实例、Azure 的 B 系列虚拟机都采用突发性能机制，但指标名称、计费规则和额度消耗方式并不完全相同。
先弄清额度代表什么
突发型实例通常以较低的持续基准性能运行；在负载较轻时积累额度，负载超过基准时消耗额度，以支持短时间的更高 CPU 性能。基准值和额度积累速度取决于平台、实例规格及具体代际，不能把一种规格的数值直接套到另一种规格。
额度不是 CPU 核数，也不等同于磁盘或网络性能。额度余额下降，说明实例可能正在使用突发能力；若余额长期见底且 CPU 需求仍高，应用就可能受到基准性能限制。不同产品的余额用单位和展示方式可能不同，查看指标时应先确认控制台说明。
去哪里识别对应指标
AWS：核对 T 系列与 CloudWatch
在 EC2 实例详情中确认实例类型是否属于 T 系列，再到 Amazon CloudWatch 查看该实例的 CPU 利用率及可用的 CPU 积分指标。常见指标包括 CPUCreditBalance、CPUCreditUsage；部分设置下还会涉及 CPUCreditSurplus。具体指标是否出现，取决于实例类型和运行模式。Unlimited 模式可能允许在余额不足时继续突发，但相关额外额度可能产生费用，应同时检查账单和实例配置。
Azure：查看 B 系列额度指标
在 Azure 门户确认虚拟机属于 B 系列，并在 Azure Monitor 的指标页面查找 CPU credits remaining、CPU credits consumed 等指标。若门户中的名称略有差异，以当前资源的指标列表和说明为准。余额下降并不必然代表故障；要结合 CPU 使用率、响应时间和负载持续时长判断。
按步骤建立监控
- 确认实例属性：记录云平台、实例规格、vCPU 数量、基准性能和突发模式。规格变更后重新核对，避免沿用旧阈值。
- 添加指标：在监控面板同时展示 CPU 使用率、额度余额、额度消耗，以及适合该业务的响应时间或任务延迟。
- 拉长观察窗口：先按业务周期查看趋势。可从 5 分钟粒度开始观察短时波动，并对照数小时到数天的高峰和低谷；采集间隔与保留时间应按平台能力和告警用途调整。
- 设置分级告警：先告警提醒余额持续下降，再在余额接近耗尽且 CPU 持续高于基准、业务指标也变差时升级处理。不要仅因某个瞬时低点触发扩容。
- 复核成本和负载：检查额外突发费用、任务是否集中运行，以及是否有可错峰的批处理。若高负载成为常态，再比较更高基准性能的规格。
怎样判断该不该换规格
例如，某个只在工作日短时处理报表的虚拟机，额度在负载后能够逐步恢复，且处理时长符合要求，突发型实例可能仍合适。若同一实例连续多个业务周期都在高负载，额度反复耗尽，页面响应或作业时长同时恶化，则应测试更高基准性能的规格，或把可延后的任务移出高峰。
比较时看持续性能、费用和负载形态，而不只看峰值 CPU。突发实例适合间歇性负载；常年高 CPU 的服务通常更需要稳定的基准性能。调整前可在非高峰时段进行小规模验证，并对照调整前后的延迟、吞吐和费用。
常见问题
额度归零就会停机吗？
不一定。实例可能回落到基准性能，也可能按平台规则继续突发并产生费用；应以该实例类型和运行模式的产品说明为准。
CPU 使用率不高，为什么余额仍下降？
使用率的统计区间可能掩盖短时峰值，也可能与观察的额度指标时间粒度不同。缩短图表时间范围，并对齐指标采样时间再判断。
余额恢复慢说明实例有故障吗？
不一定。额度通常在负载低于基准时积累；若实例持续高于基准，余额恢复有限。先核对负载和实例规则。
什么时候应优先扩容？
当额度长期不足、CPU 需求持续高于基准，并且业务延迟或处理时长变差时，优先评估更高基准性能的规格。虚拟化实例突发性能额度的识别与监控，应最终落到业务表现与成本是否可接受。