在 CentOS 上直接修改硬件传感器阈值几乎不可行——传感器芯片的原始报警阈值通常由 BIOS 或硬件固件固化，Linux 内核仅负责读取状态，无法写入。你所看到的“温度过高”警告，实质是用户态监控工具根据自身逻辑判断后触发的，与硬件本身无关。因此，要实现类似“阈值”的效果，必须绕道而行，通过软件链路来完成。
直接修改无门，需绕过硬件层走软件监控链路
CentOS 本身不提供直接修改主板/芯片组传感器（如 it87、coretemp、acpitz）原始报警阈值的接口。这些阈值通常由 BIOS 固件或传感器芯片硬编码控制，Linux 内核仅读取状态，不能写入修改。你看到的“温度过高”警告，其实是用户态监控工具（如 lm_sensors + fancontrol 或第三方服务）自己判断后触发的，并非硬件真实报警。
借助 sensors-detect + fancontrol 实现软阈值干预
这是最贴近“调整阈值”需求的可行方案：让系统在温度达到你指定值时主动降频或调速，效果等同于报警并触发响应。
- 首先运行
sensors-detect扫描并加载对应内核模块（如it87、k10temp），确认能读到temp1_input、fan1_input等字段 - 编辑
/etc/fancontrol，关键字段必须完整填写：DEVPATH（设备路径）、SENSOR（如/sys/class/hwmon/hwmon0/device/temp1_input）、PWM（对应风扇 PWM 控制节点）、MINSTART/MINSTOP/MAXPWM - 在
FANINPUTS行中配置温度与风扇的映射关系，例如：FANINPUTS="/sys/class/hwmon/hwmon0/device/pwm1 /sys/class/hwmon/hwmon0/device/temp1_input"，然后使用fancontrol启动闭环调节 - 真正起关键作用的是
/etc/fancontrol中的MINTEMP和MAXTEMP—— 它们分别定义了风扇开始转动和全速运转的温度点，这就是你能够自定义的“阈值”
采用 Prometheus + Node Exporter 实现可告警的阈值
如果你需要邮件、钉钉、Webhook 等真实告警，而非仅风扇动作，则需走指标采集加规则引擎路线。Node Exporter 暴露的 node_hwmon_temp_celsius 是唯一可靠的数据来源。
- 确保
node_exporter启动时添加了--collector.hwmon参数（默认已开启） - 查询指标名称：
curl -s https://localhost:9100/metrics | grep node_hwmon_temp_celsius，可看到类似node_hwmon_temp_celsius{chip="k10temp_0000",sensor="Tdie"} 42.5的输出 - 在 Prometheus 的
alert.rules文件中编写规则：ALERT CPU_Temp_High
IF node_hwmon_temp_celsius{chip=~"k10temp.*",sensor="Tdie"} > 85
FOR 2m
LABELS {severity="warning"}
ANNOTATIONS {summary="CPU die temp > 85°C for 2m"} - 配置好
Alertmanager接收器后，该规则将在温度持续超过 85°C 达两分钟时发送通知
BIOS 层阈值几乎无法改动，不必白费力气
部分服务器厂商（如 Dell iDRAC、HP iLO）允许通过带外管理接口调整传感器告警门限，但普通 CentOS 主板的 BIOS 通常不开放此类选项。尝试使用 ipmitool sensor thresh 查看或设置，大概率会返回 Command not supported 或权限拒绝。即便支持，也需重启后才能生效，且与 Linux 用户态监控完全解耦——你修改了 BIOS 阈值，lm_sensors 依然照常读数，Prometheus 规则也不会自动同步。
真正要改变硬件级响应，只有两个现实出路：更换主板（选择支持 IPMI 阈值配置的型号），或者接受 BIOS 默认值，将所有“报警”逻辑统一收归到 Prometheus/Alertmanager 这一层进行集中管控。
