漏扫任务完成后,部分报表可以导出,部分报表导出一直没有进度,观察扫描结果的告警数也不是很多,请问怎么处理
(0)
最佳答案
(0)
这种“部分任务能导出,部分卡住”的现象,根源通常是某个特定任务在生成报告时“卡住”了,阻塞了整个导出队列。
你可以按照“由简入繁”的顺序,逐步排查并解决这个问题。
如果问题急需解决,可以优先尝试以下步骤。它能快速清理卡住的任务,让导出功能恢复正常。
清理导出任务队列:通过 SSH 登录漏扫系统后台,执行 display report export-task 命令查看导出任务列表。
如果发现状态为 pending 或 processing 且长时间未结束的任务,请记录其 Task ID。
执行 reset report export-task 命令,或使用 delete 功能,清理这些卡住的历史任务。
重启报表服务:清理任务后,执行 restart service report-engine 命令,重启报表引擎服务。
完成以上操作后,可以再次尝试导出之前失败的报表。如果问题依然存在,再参考下面的详细排查步骤。
如果快速恢复无效,可以按以下顺序逐步排查。
这部分排查最快,可以先做:
更换浏览器与模式:尝试使用 Chrome 或 Firefox 的无痕/隐私模式导出,避开缓存和插件干扰。
检查弹窗拦截:确认浏览器未拦截弹窗,PC 的磁盘空间也充足。
检查网络稳定性:确保 PC 与漏扫设备之间的网络连接稳定,避免因高延迟或丢包导致下载中断。
这是最常见的原因,排查时可以重点关注:
检查系统资源:执行 display cpu-usage、display memory 和 display disk-usage,确保 CPU、内存和磁盘使用率未持续超过 90%。报告导出主要消耗 磁盘 I/O,但生成过程会短暂占用内存,若内存已触发告警,需先处理。
检查服务状态:执行 display service status,确认 export-server 和 report-engine 服务的状态为 Running。若不是,可尝试用 restart service <服务名> 重启。
检查系统日志:执行 display logbuffer 或后台查看 /var/log/messages,搜索 report、export 或 error 等关键词,看是否有相关错误记录。
如果上述检查都正常,就需要排查更深层的后端服务了:
检查数据库服务:执行 systemctl status postgresql 或 mysql 等命令,确保后端数据库服务正常运行。数据库异常会导致无法读取扫描结果来生成报告。
检查报告生成日志:登录漏扫后台,执行 cat /var/log/report.log,这里可能包含报告生成失败的具体原因。
检查磁盘挂载:如果报告存储在外部 NAS 上,用 df -h 检查 NFS 或 CIFS 挂载是否正常,挂载失败会导致写入异常。
部分导出问题属于已知的软件缺陷,需要升级解决。
记录当前版本:执行 display version 获取完整的系统版本号。
检查官网补丁:访问 H3C 官网,根据设备型号和版本号,查找是否有专门修复导出问题的补丁。
联系技术支持:这是最稳妥的方式。提供设备型号、当前软件版本、故障现象以及已执行的排查步骤,让工程师协助判断是否为已知问题并提供解决方案。
(0)
暂无评论
df -h
top
free -h
# 若为Java架构,查看堆内存
ps aux | grep java | grep Xmx
/var/log/xxx/scanner/):grep -i export /var/log/xxx/*.log
(0)
暂无评论
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
抄袭了我的内容
×
原文链接或出处
诽谤我
×
对根叔社区有害的内容
×
不规范转载
×
举报说明
暂无评论