mlx5 Devlink Health Reporter 能把部分固件或发送路径异常暴露给 Linux 运维工具，并在支持的情况下执行恢复。问题在于，过于积极的自动恢复可能在监控平台采集前重置设备，现场只剩一次短暂断流；完全不恢复又可能让业务长时间停留在故障状态。接入运维的重点不是把命令包装成告警，而是定义取证、隔离和恢复的顺序。
平台应先在健康节点建立报告器清单和正常状态，关联网卡 PCI 地址、接口、端口、固件、驱动、服务器与业务。异常发生时保存 reporter 状态、dump、内核日志、设备计数和受影响作业，再按严重度决定自动恢复、节点排空或人工处置。所有恢复动作都必须有次数限制和冷却时间，防止反复重置制造更大故障。
资产身份要跨命名层对齐
devlink 使用的 PCI 设备、Linux 接口名、RDMA 设备、交换 representor 和业务端口可能不是同一命名。建立稳定映射并在接口重命名、固件更新和节点重装后校验。告警必须指向可定位的物理/逻辑对象，而不是只给出一串临时接口名。
先定义事件严重度与去重
区分瞬时可恢复、重复发生、影响数据路径和设备不可用等等级，按设备与时间窗口聚合事件。累计计数和新事件分开处理，避免节点重启后历史值触发告警风暴。重复恢复后再次出现的事件应升级为排空与人工诊断。
诊断转储必须先于恢复
在允许的时间预算内先采集 reporter dump、show 状态、内核日志、固件版本、最近配置和业务影响，再执行 recover。若自动化无法保证原子顺序，应至少在本机快速写入受保护目录并由集中系统异步收集。敏感信息按安全策略脱敏。
恢复成功不等于业务恢复
recover 命令返回成功后，继续验证接口、链路、RDMA、队列、路由和目标业务。对 GPU/RDMA 节点运行轻量数据路径检查，确认作业是否需要重启。只有业务探针与错误增量恢复正常，节点才可重新准入。
自动化要有熔断与升级路径
限制同设备、同节点在一定时间内的恢复次数，超过阈值自动隔离并创建工单。驱动或固件升级后在试点节点重新确认 reporter 名称、dump 格式和 recover 行为。运维记录保留原事件、动作、结果与版本，不能只留最终绿色状态。
上线门禁需要哪些证据
- 映射 PCI、netdev、RDMA、representor、端口和业务身份。
- 定义事件等级、增量计算、去重窗口与升级条件。
- 确保 reporter dump、日志和版本先于任何恢复动作保存。
- 恢复后检查链路、RDMA、路由、业务与错误增量。
- 设置次数限制、冷却、节点隔离和版本升级试点。
版本条件决定实施范围
Linux 内核文档描述了 devlink health reporter 的诊断、转储与恢复框架。
mlx5 报告器类型、命令、事件和恢复范围随内核、驱动、固件与设备能力变化，应依据目标版本确认。
文中机制与配置边界依据Linux Devlink 官方文档的当前版本核对；官方说明用于确定候选条件，实际部署仍需结合完整料号、服务器支持清单、软件组合与现场测试。
中科新远的协同范围
中科新远是 NVIDIA Networking Elite 合作伙伴。中科新远可结合 ConnectX、BlueField 与服务器运维体系协助建立身份映射、证据采集和恢复后数据路径检查，让自动化动作可审计。具体合作范围和项目交付内容以当前有效资质、官方目录及书面确认结果为准。
Devlink recover 返回成功，是否可以立即让节点继续承载作业？
不能只看命令结果。还需验证接口、链路、RDMA 与业务路径，并确认错误不再增长；重复异常应隔离节点。
WeChat
Profile