Web 一键收集日志概率性下载失败

Hardware SIG
1

问题现象：

  1. 一键日志收集能够正常完成，但日志压缩包有时无法下载，连续多次操作可能成功一次、失败多次。

  2. 不同浏览器电脑直连 BMC，现象仍然存在。

  3. GeneralDownload 接口返回 HTTP 200，但 Nginx 实际仅发送部分文件数据，并出现以下错误：

SSL_write() failed (32: Broken pipe)
client prematurely closed connection

  1. operation.log 显示 Collect diagnose file finished，随后出现 Download xxx.tar.gz failed。

  2. 已检查系统 CPU、内存及存储空间，未发现明显异常。KCS 驱动存在高频超时日志，尝试降低控制台日志级别后问题仍然存在；暂停 rsyslog 的实验也未观察到改善，但尚未完全确认停止状态覆盖整个测试过程。

这种日志收集成功、但 GeneralDownload 下载连接提前关闭的情况，是否有类似问题？建议从哪些组件或配置入手定位？

2

答案内容由AI生成，仅供参考：

结论

从你描述的现象看，日志收集任务本身可能已经完成，失败点更偏向“下载/文件传输链路”：operation.log 已出现 Collect diagnose file finished，随后才是 Download xxx.tar.gz failed；同时 GeneralDownload 返回 200，但 Nginx 侧出现 SSL_write() failed (32: Broken pipe) / client prematurely closed connection。上下文中存在相近问题链，可以作为排查参考，但当前资料不能直接确认根因。

点击此处查看详细分析解答

结论

从你描述的现象看，日志收集任务本身可能已经完成，失败点更偏向“下载/文件传输链路”：operation.log 已出现 Collect diagnose file finished，随后才是 Download xxx.tar.gz failed；同时 GeneralDownload 返回 200，但 Nginx 侧出现 SSL_write() failed (32: Broken pipe) / client prematurely closed connection。上下文中存在相近问题链，可以作为排查参考，但当前资料不能直接确认根因。

可参考的类似问题

  1. 带外下载 NPU 日志失败

    • Web 页面下载失败，F12 抓包显示 task 返回 502。
    • 定位为前端获取 task 信息时可能发生连接超时，原因可能是网络问题或后端资源紧张未能及时处理。
    • 解决方案是前端增加重试：重试三次，第四次仍失败才提示日志收集失败。
    • 对应 PR：webui#341。
    • 这与“接口返回 200 但实际传输中断/前端表现为下载失败”的方向相近，重点应看 前端 task 查询、后端资源状态和连接超时。

  2. Web 一键收集日志失败定位

    • 有案例中 Web 点击一键收集返回 500，app.log 在执行一键收集过程中无打印，重启 BMC 后现象仍存在。
    • 建议查看 framework.log。
    • 排查时需确认问题是否必现，并检查是否开启了某厂商定制化；历史上有 JD 定制化中收集日志相关功能未实现的情况。
    • 无论 Web 还是 CLI 收集日志，第一步都是通过运维组件拉起任务；如果 app.log 看不到信息，可以考虑开启北向组件 debug 日志。

  3. HttpServer 写响应时出现 SocketException

    • 上下文中记录：HttpServer 会遇到 SocketException，主要由于数据写操作中的 broken pipe。
    • 这与当前 SSL_write() failed (32: Broken pipe)、客户端提前关闭连接属于同一类“HTTP 响应写入中断”表现，应重点排查响应写入链路和客户端提前断开。

  4. 完整日志因网络中断无法收集

    • 有用户反馈完整日志无法收集，原因是收集过程中网络连接中断。
    • 这与概率性下载失败中“连接提前关闭”的现象方向一致，说明网络/连接稳定性需要纳入排查。

  5. 硬盘日志收集导致性能延迟和超时

    • 上下文提到：BMC Reset 期间进行磁盘日志收集会造成性能延迟和超时。
    • 有案例指出 Broadcom 带外通信性能较差，收集硬盘日志期间会频繁报超时；2603 版本优化后，硬盘日志收集会放在每天凌晨进行，不再每次 BMC 复位都收集，LTS2512 可能未包含这些优化。
    • 如果你的测试发生在 BMC 复位后或自动收集窗口，需要排除后台硬盘日志收集造成的资源竞争或超时影响。

建议重点排查的组件与配置

1. 前端 WebUI / 下载接口

  • 检查 GeneralDownload 虽返回 HTTP 200，但响应内容是否完整、文件大小是否与预期一致。
  • 关注前端 task 轮询和下载重试逻辑；上下文中的前端重试方案是：重试三次，第四次仍失败才提示日志收集失败。
  • 前端会把日志收集失败表现为“下载失败”，因此不能只看接口状态码，还要看实际文件传输是否完成。

2. Redfish task / LogServices / CollectLog

  • CollectLog 是 LogServices 上的 action，会生成 TaskId 用于跟踪后台日志收集任务。
  • 响应中的 status 例如 "200"、message 例如 "Collect task is running background." 只能说明任务被受理或后台运行，不等于文件已成功下载。
  • 应确认 task 查询是否超时、是否出现 502，以及任务最终状态是否真正完成。上下文中的 NPU 日志案例就是 task 查询超时导致前端下载失败。

3. HttpServer / HTTP 响应写入链路

  • 上下文已明确 HttpServer 可能因 broken pipe 出现 SocketException。
  • 当前现象中的 SSL_write() failed、client prematurely closed connection 应归入响应写入/连接中断方向排查。
  • 需要核对是否存在客户端提前断开、响应写入失败、传输过程中连接被关闭等情况。当前上下文未提供 Nginx 的具体配置项，因此不能直接给出 Nginx 配置层面的确定结论。

4. 运维组件 / 北向组件

  • Web 和 CLI 收集日志的第一步都是通过运维组件拉起任务。
  • 如果 app.log 没有有效打印，建议查看 framework.log，并考虑开启北向组件 debug 日志。
  • 这有助于判断问题发生在“任务拉起阶段”“任务执行阶段”还是“下载传输阶段”。

5. 厂商定制化

  • 排查是否开启了厂商定制化，尤其是与日志收集、下载相关的定制项。
  • 上下文中有定制化导致收集日志功能未实现的历史线索，因此定制化是应当排除的因素之一。

6. 存储 / 硬盘日志自动收集

  • 可检查 LogAutoCollectEnable、LogAutoCollectInterval 等配置，以及 StartCollectLog、DumpLog 相关流程。
  • 如果自动硬盘日志收集正在运行，可能带来后台资源占用和超时；尤其是在 BMC 复位后或自动收集窗口内，建议避开这些时段复测。
  • 2603 版本对硬盘日志收集时机做过优化，LTS2512 可能未包含；若版本较低，需要把该后台任务作为干扰因素排查。

7. 日志对照与 CLI 验证

  • 建议同时用 CLI 方式收集：SSH 登录 BMC 后执行 ipmcget -d d，收集完成后在 /tmp 目录取日志压缩包。
  • 如果 CLI 能正常生成并取得压缩包，而 Web 下载仍概率性失败，则问题更偏向 Web 下载/传输链路；如果 CLI 也异常，则继续查收集任务和后台组件。
  • 可结合 operation.log、app.log、framework.log 对照。注意上下文中有一条修改描述提到：Web 界面进行一键收集时，不会记录下载成功/失败的操作日志；因此若你版本中 operation.log 记录不完整，不能只依赖该日志判断。

关于 KCS 与 rsyslog

当前上下文没有提供 KCS 驱动高频超时、降低控制台日志级别、暂停 rsyslog 与“一键收集后下载失败”之间关系的分析资料，因此无法据此判断这些因素是否相关。它们可以作为环境因素单独记录和验证，但不建议在没有进一步证据前直接归因。

3

一般是因为电脑磁盘空间不足导致下载失败，可以换台电脑试试，这种问题之前遇到均不是bmc问题