批量采集要解决什么
机队规模上来后，带外巡检不能靠逐台登录：脚本按主机清单循环调用 ipmitool 或 Redfish，把每台结果落到独立文件，再统一汇总。两个关键约束是并发与失败处理——管理控制器对会话数敏感，高并发会大面积超时；而漏记的失败主机，会让汇总结果看起来一切正常。
基本信息
| 输入 | 主机清单文件，每行一个 BMC 地址 |
|---|---|
| 输出 | 按主机名与日期归档的结果文件 |
| 并发控制 | 串行或受限并行，间隔去突发，避免触发限流 |
| 失败处理 | 非零退出单独记账并安排重试 |
| 凭据管理 | 口令文件独立存放并限制读权限 |
| 调度 | 交给 cron 或巡检平台定时执行 |
典型使用场景
- 日常巡检：批量采集电源状态、传感器读数与事件增量
- 交付验收：新机上架后一次性采集基础信息留档
- 固件盘点：批量读版本，核对同批次基线是否一致
- 故障排查：单机可疑时拉取同批次其它机器的数据做对照
- 资产同步：汇总序列号与机型，回填到 CMDB 或台账
批量采集骨架
批量采集骨架
for h in $(cat /etc/bmc-hosts.txt); do
out=/var/log/bmc/$h-$(date +%F).txt
{
ipmitool -I lanplus -H $h -U admin -f /root/.ipmi_pass mc info
ipmitool -I lanplus -H $h -U admin -f /root/.ipmi_pass sdr elist | head -40
} > $out 2>&1
# 失败主机单独记账，不要只保留成功的输出
[ $? -ne 0 ] && echo "$h" >> /var/log/bmc/failed-$(date +%F).txt
sleep 1 # 串行加间隔，先把突发压下去
done结果自检
| 检查项 | 正常表现 | 异常含义 |
|---|---|---|
| 文件数量 | 与清单行数一致 | 偏少说明有主机未采集 |
| 失败清单 | 为空 | 非空需重试，而不是直接归档 |
| 文件内容 | 含机型与传感器读数 | 空文件多为连接或凭据问题 |
| 总耗时 | 随主机数近似线性 | 暴涨通常是限流后反复重试 |
先在少量主机上验证脚本，再全量执行；输出目录纳入日志保留策略，避免长期运行把系统盘写满。
凭据不要硬编码在脚本里，也不要放在命令行参数上：进程列表与脚本文件都可能被同机其它用户看到。