日本AMD服务器的监控不能只看 CPU 使用率。实际告警应至少覆盖三类信号：CPU 封装温度及是否出现降频、ECC 内存的可纠正与不可纠正错误、磁盘 I/O 延迟与设备错误。对于没有厂商专属阈值资料的环境，可以先使用工程起始值，再结合 BMC、操作系统日志和业务基线调整，而不能把某个温度或 I/O 数字直接当成所有 AMD 平台的硬件极限。

可采用的初始判断是：CPU 封装温度持续超过 80℃进入预警，超过 90℃或达到 BMC 的 critical 线进入严重告警；ECC 不可纠正错误或 MCE 硬件错误应立即告警，可纠正错误则按同一内存条的发生频率判断；SSD/NVMe 的 await 可先以 20ms、50ms作为预警和严重告警参考，机械磁盘可放宽到 50ms、100ms。上述数值是通用运维起始线，不是 AMD 处理器、内存或磁盘的统一规格限制。

一组可落地的初始告警阈值

以下阈值适合用于日本AMD服务器的第一版监控规则。正式启用前，应确认服务器型号、散热方式、磁盘介质、业务负载以及监控指标的采集口径。

如果 BMC 或硬件厂商文档提供了更低的温度告警线，应优先采用厂商定义。若 CPU 在正常业务负载下长期接近 80℃，不能简单地把阈值调高，而应先核实散热、机箱风道、风扇转速和环境温度。

CPU 温度：看封装温度，也看是否发生热限制

监控哪个温度字段

AMD 平台可能同时暴露 Tctl、Tdie、CPU Package、核心温度和主板 CPU 温度等字段。不同主板、BMC 固件和 Linux 驱动的命名不完全一致，字段含义也可能不同。

优先选择以下顺序：

1. BMC 提供的 CPU 封装或处理器温度；
2. 操作系统中与封装温度对应的传感器；
3. 在没有封装温度时，使用核心最高温度作为辅助指标；
4. 主板插槽温度只用于交叉验证，不作为唯一 CPU 温度依据。

在同一台日本AMD服务器上，温度监控应长期使用同一字段。若监控系统从 Tdie 切换到 Tctl，即使硬件状态没有变化，也可能出现整段曲线偏移，导致大量误报。

Linux 中可以先查看已经加载的传感器：

sensors

如果服务器使用了 BMC，也可以使用只读方式查看 IPMI 传感器：

ipmitool sensor

命令是否可用取决于系统是否安装对应工具、BMC 是否启用以及当前用户是否有访问设备的权限。不要因为 sensors 没有输出就直接判定 CPU 没有温度传感器，也不要把不存在的字段写入监控配置。应先确认实际输出中的传感器名称。

为什么不能只设一个“超过多少度就报警”

CPU 温度需要结合持续时间和运行状态判断：

• 高温只出现一个采样点，可能是瞬时 Boost 或采集抖动；
• 高温持续存在，但 CPU 负载很高，可能是正常业务压力，也可能是散热余量不足；
• CPU 负载不高却温度持续升高，更应检查风扇、散热器接触、机箱风道和温度传感器；
• 温度升高同时出现频率下降、BMC 热事件或业务延迟增加，故障优先级应提高。

因此，推荐采用“温度阈值 + 持续时间 + 性能迹象”的组合规则。恢复条件也不要设置成温度一度跌破告警线就恢复，可以要求温度低于预警线 3℃至 5℃并持续多个采样周期，以减少反复通知。

需要注意的是，80℃和90℃只是通用运维起始值。处理器具体型号、散热方案、BIOS 策略和机房环境都会影响合理范围。接近厂商定义的热保护线时，应以 BMC 或型号文档为准，而不是继续套用通用值。

ECC 内存：重点看错误速率和故障位置

ECC 监控必须区分两类错误：

• 可纠正错误（CE）：硬件已经纠正，系统通常可以继续运行，但同一内存条反复出现 CE 可能意味着内存颗粒、插槽、通道或主板存在退化；
• 不可纠正错误（UE）：无法通过 ECC 修复，可能导致进程异常、系统崩溃、数据损坏或机器重启，应作为高优先级硬件事件处理。

CE 不建议按累计总数告警

EDAC 中的 ce_count 和 ue_count 往往是从启动后累计的计数器。如果服务器运行了较长时间，累计 CE 很大并不代表当前故障正在恶化。监控系统应保存上一次读数，计算本周期增量：

本周期错误数 = 当前计数 - 上一次计数

如果服务器重启后计数器归零，应将其视为计数器重置并重新建立基线，不能把归零误报为错误恢复，也不能把计数跳变直接当成新增错误。

在 Linux 中可以查看 EDAC 计数：

for f in /sys/devices/system/edac/mc/mc*/{ce_count,ue_count}; do
  [ -r "$f" ] && printf '%s: ' "$f" && cat "$f"
done

同时检查内核日志中的硬件错误信息：

journalctl -k --since "1 hour ago" | \
grep -Ei 'edac|mce|machine check|hardware error|ecc'

不同发行版、内核版本和平台的日志格式可能不同。部分 AMD 平台的 Machine Check Architecture 事件不会完整映射到简单的 EDAC 计数器，因此应同时采集内核日志或系统已有的 RAS 事件工具。

ECC 告警怎么分级

一个实用的分级方式如下：

• UE、MCE 或明确的不可纠正内存事件：任意新增事件立即告警；
• CE 只出现一次：记录事件并通知低优先级观察，不必立即重启服务器；
• 同一 DIMM 在 10 分钟内出现约 10 次 CE：进入预警，并检查该内存条、通道和对应日志；
• CE 在多个监控周期重复出现，或错误速率持续增加：升级为硬件风险告警；
• 多条内存同时出现错误：不能只更换单条 DIMM，应检查电源、主板、固件、温度和内存配置。

CE 阈值不是所有平台都适用的固定标准。某些平台会进行后台内存巡检，巡检本身可能产生可纠正错误记录；某些平台则会对一批错误进行聚合上报。因此，首次上线时应先确认事件是按单次错误、批次错误还是巡检周期计数。

内存错误还需要尽可能定位到 DIMM、通道和插槽。如果监控系统只能看到主机总 CE 数，而看不到具体位置，可以先按主机总量告警，但处理时必须结合 BMC 日志和物理插槽映射，否则无法判断是单条内存反复故障，还是多个通道同时异常。

磁盘 I/O：延迟优先，忙碌率用于辅助

磁盘 I/O 告警最常见的误区是只看 %util。这个指标表示设备处于忙碌状态的时间比例，但无法单独说明请求是否已经影响业务。对于多队列 SSD 或 NVMe，设备可能保持较高忙碌率，同时延迟仍然可接受；反过来，设备 %util 不高，也可能因为控制器、链路或介质问题出现明显延迟。

Linux 中可以使用 iostat 查看扩展 I/O 指标：

iostat -xmd 1 5

重点关注：

• await：请求从提交到完成的平均等待时间，单位通常为毫秒；
• r_await、w_await：读、写请求的分别延迟；
• aqu-sz：平均队列长度；
• r/s、w/s：每秒读写请求数；
• %util：设备忙碌比例；
• 吞吐量：用于判断带宽是否达到业务或设备上限。

对于 SSD/NVMe，await 超过 20ms并持续一段时间可以作为预警起点，超过 50ms则需要重点排查。对于机械磁盘，可以先使用 50ms和100ms作为预警、严重告警参考。数据库、日志写入和低延迟应用可能需要更低的业务专属阈值；批量备份、离线归档等业务则可能允许更高延迟。

这些值必须建立在“确实存在业务 I/O”的前提下。设备几乎没有请求时，单个慢请求就可能把短窗口平均值推高。更稳妥的规则是：

• await 超限；
• 同时存在持续的读写请求；
• 告警持续超过多个采样周期；
• 业务延迟或队列长度出现相同方向变化。

如果监控系统能够提供分位数，应优先观察 I/O 延迟的 p95 或 p99，而不是只看平均值。平均值可能掩盖少量但严重的长尾请求。

磁盘错误和 I/O 堵塞要分开处理

查看磁盘物理关系时，可以先确认设备类型和挂载关系：

lsblk -o NAME,TYPE,MODEL,SERIAL,MOUNTPOINTS

直连 SATA 设备可以尝试：

smartctl -a /dev/sda

NVMe 设备通常使用：

smartctl -a /dev/nvme0

这些命令通常是只读操作，但设备路径必须根据 lsblk 的实际输出确认，不能把逻辑卷、RAID 虚拟盘和物理盘混为一谈。若磁盘位于硬件 RAID 或某些 HBA 后面，操作系统可能无法直接读取完整 SMART 信息，应通过控制器管理工具获取物理盘状态。

判断结果可以按以下方式区分：

• await 高、%util 高、队列变长，但没有介质错误：更接近 I/O 饱和或业务突发；
• await 高、%util 不高、请求量不大：检查控制器、链路、文件系统等待和设备响应异常；
• SMART 或 NVMe 错误计数新增：优先处理设备风险，不要等到 I/O 延迟持续超限；
• 单个设备延迟明显高于同机其他设备：重点比较设备型号、挂载关系和错误日志；
• 多块设备同时延迟升高：应排查共享控制器、主机资源和上层业务，而不是直接更换所有磁盘。

告警降噪：把单点异常变成可判断事件

使用持续时间和多窗口

温度、await 和 %util都可能有短时尖峰。建议使用短窗口发现异常、长窗口确认影响：

• CPU 温度可使用 1 分钟采样，连续 10 分钟确认预警；
• 磁盘 I/O 可使用 10 秒至 1 分钟采样，连续 5 至 10 分钟确认；
• ECC 使用事件增量和 10 分钟、1 小时等窗口计算速率；
• UE、MCE、设备掉线等离散硬件事件不应等待长窗口。

如果监控平台支持多条件表达式，可以将“指标超限”和“采集值有效”同时作为条件。采集断开应单独产生监控缺失告警，不能被当成温度或 ECC 已恢复。

设定恢复滞回

CPU 温度刚降到 79℃时，不建议立即恢复一个 80℃告警。可以要求温度低于预警线 3℃至 5℃并持续两个以上周期，磁盘延迟则要求连续多个周期回到正常区间。ECC 和设备错误属于事件型告警，恢复应依据事件是否停止、设备是否重新可用以及维护结果确认，不能仅依赖计数器暂时不增长。

关联告警而不是重复通知

同一故障可能同时触发多个指标：

• 风扇或散热故障可能同时造成 CPU 温度上升、频率下降和业务延迟增加；
• 内存硬件问题可能同时产生 CE、MCE 和应用异常；
• 磁盘介质退化可能先出现 SMART 错误，随后出现 await 升高和队列堆积。

监控系统应将同一主机、同一设备和相近时间内的告警进行关联，保留原始事件，但把通知合并为一个主告警。这样既不会丢失证据，也能避免值班人员收到大量重复消息。

部署前后的验证方法

正式启用前，先完成以下准备：

1. 确认服务器是物理机还是虚拟机。虚拟机通常无法直接读取宿主机 BMC、ECC 和物理盘状态，相关监控必须部署在宿主机或硬件管理层。
2. 确认 CPU 温度实际字段，记录 BMC 与操作系统读数是否一致。
3. 确认 EDAC 计数器是否能定位到内存条，以及计数器是否会在重启后归零。
4. 确认 I/O 指标对应的是物理盘、RAID 逻辑盘还是逻辑卷。
5. 至少采集一个完整业务周期的正常数据，记录 CPU 温度范围、I/O 延迟、队列长度和 ECC 基线。

验证告警链路时，应使用监控平台提供的测试事件或临时测试规则，不建议通过拔盘、关闭风扇、强行制造 ECC 错误等方式测试硬件。一次合格的告警验证至少应包含主机名、设备名、当前值、阈值、持续时间、事件时间和恢复通知。

如果上线后误报较多，应先确认采集字段和计数口径，再调整持续时间、分级和滞回，不要直接大幅提高阈值。修改前保留旧规则，调整后观察一个完整业务周期；若出现漏报或无法区分故障类型，可恢复原规则，再针对具体指标拆分条件。

这些阈值的适用边界

日本AMD服务器的地域不会改变 CPU、ECC 或磁盘指标的基本判断方法，但实际阈值会受到以下因素影响：

• AMD 处理器具体型号及其温度传感器定义；
• 散热器、风扇策略、机箱风道和环境温度；
• BIOS、BMC 固件和 Linux 内核对 RAS 事件的上报方式；
• ECC 内存巡检和错误聚合策略；
• SATA、SSD、NVMe、RAID 控制器及其队列模型；
• 应用对 I/O 延迟的容忍度。

因此，最终可执行的判断标准应是：CPU 温度以厂商限制线和持续趋势为准，ECC 以不可纠正事件和同一 DIMM 的错误速率为准，磁盘 I/O 以延迟、队列、忙碌率和设备错误的组合为准。当单一指标超限时先确认采集有效性；当两个以上相关指标同时异常，或出现 UE、MCE、设备掉线等硬件事件时，应立即进入故障处理流程。