可实现轻量可靠的自动化硬件巡检：通过Shell脚本调用smartctl、ipmitool等工具采集CPU温度、内存可用率、硬盘SMART状态、电源风扇读数及RAID状态，结合cron定时执行、日志归档与异常邮件通知。
用 Shell 脚本结合系统工具（如 smartctl、ipmitool、dmidecode、lshw、cat /proc/meminfo 等）采集关键硬件指标，再通过 cron 定时执行 + 日志归档 + 异常邮件通知，就能实现轻量可靠的自动化硬件巡检。
核心硬件检查项与对应命令
脚本需覆盖以下关键部件，每项应有明确的健康判断逻辑：
-
CPU 温度与状态：用
sensors（需安装 lm-sensors）读取温度，阈值建议 ≤85℃；也可查/sys/class/hwmon/下原始值 -
内存健康：解析
cat /proc/meminfo | grep -E "MemTotal|MemAvailable"判断可用率；结合dmesg -T | grep -i "hardware|ecc|corrected"检查 ECC 错误日志 -
硬盘 SMART 状态：对每块磁盘运行
smartctl -H /dev/sdX（返回 PASSED 才正常），并检查Reallocated_Sector_Ct、Current_Pending_Sector、UDMA_CRC_Error_Count等关键属性值 -
电源与风扇（带 IPMI 的服务器）：用
ipmitool sdr type temperature、ipmitool sdr type fan、ipmitool sdr type power获取实时读数和状态，过滤出“ns”（non-specific）或“lc”（lower critical）等异常标识 -
RAID 卡状态（如 MegaRAID）：用
megacli -AdpAllInfo -aALL 2>/dev/null | grep "System Overview\|Controller Status"或storcli /c0 show检查控制器和虚拟盘状态（Optimal / Degraded / Failed）
脚本结构设计要点
一个健壮的巡检脚本应包含初始化、采集、判断、输出、通知五部分：
- 开头设置日志路径、邮箱、超时阈值、忽略设备列表（如测试盘
/dev/sdb）等可配置变量 - 用
set -e和trap 'echo "ERROR at line $LINENO"; exit 1' ERR增强容错，避免某条命令失败导致后续误判 - 每个硬件模块封装为函数（如
check_disk_smart()），便于单独调试和复用 - 健康判断不只看返回码，更要看输出内容——例如
smartctl -H返回 “PASSED” 才算 OK，不能只依赖命令是否报错 - 结果统一写入带时间戳的 JSON 或简单键值日志（如
disk_sda_health=OK temp_cpu=62C raid_status=Optimal），方便后续解析
定时执行与异常响应机制
仅定时执行不够，必须配套可观测性和响应能力：
- 用
crontab -e添加：0 3 * * * /opt/scripts/hw-check.sh >> /var/log/hw-check.log 2>&1（每天凌晨3点执行） - 脚本末尾加入差异比对逻辑：将本次结果与上一次日志对比，仅当出现新异常（如 SMART 属性值恶化、新增 “Failed” 状态）才触发告警
- 邮件通知用
mail -s "HW Alert on $(hostname)" admin@example.com ，内容需含主机名、时间、具体异常项、建议操作（如 “请立即检查 /dev/sdc 的 Reallocated Sector 数”） - 保留最近7天日志：
find /var/log -name "hw-check-*.log" -mtime +7 -delete，可在脚本结尾或独立清理任务中执行
部署前必做验证
上线前务必在测试环境逐项验证，避免误报或漏检：
- 手动运行脚本，确认所有命令在目标系统中存在且权限足够（如
ipmitool需 root 或 ipmi 组；smartctl对 NVMe 盘要用-d nvme参数） - 模拟异常：临时拔掉一根内存（重启后）、人为修改 SMART 属性（仅限测试盘）、断开 RAID 卡缓存电池，验证脚本能捕获并告警
- 检查 cron 环境变量：默认 cron 的 PATH 较窄，建议在脚本开头显式声明
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin - 首次运行后检查日志格式是否规整、邮件是否收到、历史比对逻辑是否生效
不复杂但容易忽略——关键是把“硬件是否在正常工作”翻译成机器可判定的确定性条件，而不是只跑命令看有没有报错。
