Redfish 日志模型
Redfish 用统一的 REST 资源模型暴露管理能力，日志部分由 LogServices 承担：先读集合拿到可用的日志列表，再按条目资源的地址逐条取详情。作用与 SEL 相同，但字段是标准化的，一套采集脚本可以同时覆盖多个品牌，厂商差异集中在 Oem 段。
基本信息
| 标准来源 | DMTF Redfish 规范，入口在 /redfish/v1/ |
|---|---|
| 日志入口 | Systems/<id>/LogServices 与 Managers/<id>/LogServices |
| 条目读取 | LogServices/<名称>/Entries，集合内是条目引用 |
| 认证方式 | 基本认证或会话令牌，批量采集推荐令牌 |
| 实时能力 | EventService 支持事件订阅，可推送到接收端 |
| 版本差异 | 可用日志与字段随固件版本变化，脚本需容忍缺字段 |
典型使用场景
- 跨品牌统一采集：脚本复用，差异只处理 Oem 字段
- 集中审计：条目汇总到日志平台做趋势分析
- 监控联动：用事件订阅替代轮询，告警更及时
- 工单附件：按时间范围导出条目作为故障证据
- 定期巡检：比对条目增量，发现新出现的告警
- 配置审计：读管理侧操作记录，核对谁在什么时间改过配置
读取日志条目
读取日志条目
# 该主机提供哪些日志服务
curl -k -s -u admin:'<口令>' https://<bmc-ip>/redfish/v1/Systems/1/LogServices | head -40
# 读某类日志的条目集合（集合里是引用，不是正文）
curl -k -s -u admin:'<口令>' https://<bmc-ip>/redfish/v1/Systems/1/LogServices/SEL/Entries | head -60
# 提取条目地址，再逐条取详情；具体名称与字段依机型而定
curl -k -s -u admin:'<口令>' https://<bmc-ip>/redfish/v1/Systems/1/LogServices/SEL/Entries \
| jq -r '.Members[]?."@odata.id"' | head -5
# 读单条详情
curl -k -s -u admin:'<口令>' https://<bmc-ip>/redfish/v1/Systems/1/LogServices/SEL/Entries/1资源与字段读法
| 字段 | 含义 | 关注点 |
|---|---|---|
| LogServices | 可用的日志集合 | 名称因厂商而异，先列出再选 |
| Entries | 条目集合 | 集合返回引用，正文需再取一层 |
| Created | 条目产生时间 | BMC 时间未同步时不可信 |
| Severity | 严重级别 | 可用于过滤，并非每条都有 |
| Message | 事件描述 | 定位故障部件的主要关键字 |
条目多时不要一次全量拉取：用分页参数或时间过滤，否则响应体过大，脚本容易超时并拖慢管理控制器。
各厂商对同一类日志的命名不同：先把资源清单列出来再写解析逻辑，脚本里对缺失字段做兜底，换机型时才不用重写。
高频基本认证轮询会不断创建会话，触到上限后其它运维工具无法登录：批量采集改用会话令牌，并在结束后删除会话。