FW1090 CPU使用率高告警

• 周期性任务特征：网络设备（如FW1090防火墙）或与之联动的网管平台（如H3C IMC、安全态势感知等），常常会在凌晨或业务低谷期（比如你日志中的固定时间点）自动执行一些后台任务，例如：

  • 日志压缩与归档

  • 流量报表生成

  • 配置文件自动备份

  • 特征库/协议库的定时检查或升级

  • SNMP批量数据采集

• CPU告警机制：设备会周期性（如1分钟）采样CPU使用率，一旦超过设定的阈值（如高级别告警门限99%，低级别80%），就会触发告警。当任务结束，CPU使用率回落至恢复阈值以下，告警解除。你观察到的10分钟正好符合一个短时任务的典型运行时长。

排查与处理方法

1. 查看系统日志，寻找任务线索

这是最直接的方法。登录设备，查看告警时间点前后的系统日志，寻找是否有任务启动、完成的记录。

• 命令行：display logbuffer | include <告警时间点前后几分钟> 或 display logbuffer | include 任务关键字。

• Web界面：导航至“监控”或“系统日志”部分，按时间筛选日志。重点关注“Info”级别的日志，看是否有与备份、归档、升级相关的记录。

2. 检查CPU历史记录，确认规律

使用命令查看CPU利用率的详细历史记录，可以更精确地定位冲高时间段，排除误报。

• 命令行：display cpu-usage history 可以图表方式显示CPU利用率的历史记录。

• Web界面：在“设备状态”或“系统利用率”页面，通常也有CPU使用率的趋势图。

3. 排查常见定时任务

登录设备，检查以下常见配置：

• 日志主机或信息中心：检查是否配置了日志输出到外网日志主机（如H3C IMC）。有时日志主机在整点会并发请求大量MIB信息，导致CPU升高。

  • 命令：display current-configuration | include info-center 或 display loghost。

• SNMP配置：如果网管系统（如IMC、Zabbix）配置了密集的SNMP轮询（尤其是基于IP或接口的批量查询），也可能导致CPU周期性升高。

  • 命令：display current-configuration | include snmp。

• NTP同步：检查NTP（网络时间协议）同步设置。虽然NTP本身消耗不大，但时间跳变有时会触发一些基于时间的策略重新计算。

  • 命令：display ntp-service status。

• 特征库自动升级：安全设备通常会定期（如每天凌晨）检查IPS、AV等特征库的更新。

  • 命令：display current-configuration | include update 或查看“对象”→“特征库升级”相关配置。

• 会话统计或Top N排名：检查是否开启了定时生成会话Top N统计的功能，尤其是在整点时刻。

  • 命令：display current-configuration | include top。

4. 调整告警阈值（临时规避）

如果确认是正常业务任务，且不影响设备转发，可以通过适当调高告警阈值来减少误报。但不推荐作为根本解决方案，否则会掩盖真实的性能问题。

• 命令：

  system-view

  monitor cpu-usage threshold severe-threshold 98 [ minor-threshold 90 ] # 将高级别告警从99%调到98%，低级别从80%调到90%（示例，请按需调整），缺省情况下，CPU利用率高级别告警门限为99%，低级别告警门限为80%。

5. 排查联动平台（如IMC、安全感知平台）

如果FW1090本身没有查到任何定时任务，那么任务很可能在上层的网管平台上。

• 登录你的H3C IMC（智能管理中心）或其他网管软件。

• 检查平台自身的定时任务：如“性能监控任务”、“配置备份任务”、“拓扑发现”、“报表任务”等。看这些任务是否会在告警时间点启动，并且任务涉及大量SNMP查询或数据写入，从而导致被管理设备（FW1090）CPU升高。

开了debug导致的

问题根源分析

1. 告警时间线：
   • 03:52:30：CPU使用率超过阈值，触发 CPU_EXCEED_THRESHOLD告警。
   • 03:52:41：系统执行了 undo debugging all​ 命令。这条命令的作用是关闭所有调试信息输出。
   • 04:02:30：CPU使用率恢复正常，触发 CPU_RECOVER_THRESHOLD告警。
2. 因果关系：
   • 开启调试日志（尤其是针对数据转发、安全策略、路由等核心业务的调试）会极大增加设备的处理开销，因为设备需要为每一个匹配的报文或事件生成详细的日志信息，这非常消耗CPU资源。
   • undo debugging all命令关闭了这些调试信息输出，CPU占用随即下降，并在大约10分钟后恢复到正常水平。

结论与建议

• 技术人员进行故障排查时临时开启，但排查后忘记关闭。
• 存在自动化的脚本或任务在特定时间（如您提到的“这个点”）开启了调试，并在运行一段时间后（如10分钟）自动或手动关闭。

解决步骤

1. 立即确认并彻底关闭调试：
   • 登录设备，在系统视图下，再次执行 undo debugging all​ 命令，确保当前没有任何调试功能被启用。
   • 使用 display debugging​ 命令进行验证，输出应该为空或显示“All possible debugging has been turned off”。
2. 检查定时任务/自动化脚本：
   • 检查设备的配置中是否存在定时执行任务（scheduler job/schedule），特别是那些在每天固定时间（如03:52）运行的脚本或命令。
   • 检查命令行历史（如使用 display history-command或查看更详细的日志），看 debugging命令是否由定时任务触发。
3. 审查运维流程：
   • 如果这是人为操作，请加强运维规范，要求操作后必须立即关闭调试功能。
   • 如果是自动化监控或收集工具所为，请调整该工具的配置，确保其收集完必要信息后能自动、立即执行 undo debugging all，或者改为使用对性能影响更小的信息收集方式（如使用 display命令抓取状态快照）。

• 03:52:30：触发 CPU_EXCEED_THRESHOLD（CPU 使用率超过阈值）
• 03:52:41：执行了 undo debugging all 命令（关闭调试）
• 04:02:30：触发 CPU_RECOVER_THRESHOLD（CPU 恢复正常）

1. CPU 高负载持续约 10 分钟，和你观察到的 “10 分钟后恢复” 完全吻合。
2. 中间有人执行了 undo debugging all，极大概率是调试 / 日志收集开关未关闭，导致 CPU 被持续占用。
3. 结合你之前发现的 slot6 板卡有大量 ICMP 流量，两者很可能是同一根源：调试 / 镜像 / 日志收集未关闭 + 异常流量 共同推高了 CPU。

🔍 可能的未关闭日志 / 调试开关

1. packet capture / 镜像抓包
   • 比如在 slot6 上执行了 capture-packet 或配置了本地镜像，持续抓取流量并写入内存 / 文件。
   • 表现：CPU 高，流量大时更明显，停止抓包后 CPU 立刻回落。
2. debugging 调试未关闭
   • 之前执行过 debugging 命令（如 debugging ip icmp、debugging arp），但只关了部分或没关全。
   • 你日志里的 undo debugging all 就是证据：之前肯定开了调试。
3. 日志 / 告警频繁输出
   • 开启了 info-center logbuffer 或 terminal monitor，大量日志刷屏，导致 CPU 处理日志任务过重。
   • 或 snmp-agent trap enable 配置了过多 Trap，频繁上报告警。
4. 性能 / 流量监控任务
   • 开启了 display cpu-usage history 实时采样，或第三方监控工具高频拉取 OID。
   • 或 IMC 等网管平台对该板卡配置了高频性能采集（如 10 秒一次）。

✅ 排查与修复步骤（按优先级）

1. 检查是否还有调试 / 抓包在运行

• 如果有：
  cli

  # 关闭所有调试 undo debugging all # 停止抓包 packet-capture stop # 删除镜像组 undo mirroring-group 1

2. 检查日志 / 告警输出配置

• 建议优化：
  cli

  # 关闭终端日志输出（避免刷屏） undo terminal monitor undo terminal debugging # 限制日志缓冲区大小 info-center logbuffer size 1024

3. 检查 SNMP / 网管采集频率

• 在 IMC / 网管平台查看：
  • 该设备 / 板卡的性能采集周期是否为 10 秒 / 30 秒（过短会加重 CPU）
  • 建议改为 1 分钟 / 5 分钟 一次
• 设备端检查：
  cli

  display snmp-agent status

4. 检查异常流量（结合你之前的发现）

• 如果发现某端口 / IP 有大量 ICMP：
  • 先定位源设备（display arp + display mac-address）
  • 临时限流：qos car 限制 ICMP 速率，或在接入交换机上封堵。

🧠 为什么刚好在这个点发作？

• 很可能是凌晨定时任务触发：
  • 网管平台凌晨执行批量采集 / 备份
  • 设备自身凌晨执行日志归档 / 统计计算
  • 或某台服务器凌晨启动批量探测 / 扫描（比如你之前发现的数据库 ping）
• 加上未关闭的调试 / 抓包，双重压力导致 CPU 瞬间打满，10 分钟后任务结束 / 被手动关闭，CPU 恢复。

🚀 最终建议

1. 先执行 undo debugging all，确认当前无调试任务。
2. 检查并清理 packet-capture / mirroring-group。
3. 优化日志 / 网管采集频率。
4. 定位并处理 slot6 上的异常 ICMP 流量。
5. 观察 24 小时，看凌晨 CPU 告警是否复现。