防火墙安全策略日志记录问题

防火墙安全策略日志“命中几十次才记录一次”，大概率不是故障，而是设备的缓存发送（聚合发送）机制在起作用。当然，也需要排查一下存储空间等问题。

🔍 核心原因：日志的“缓存发送”机制

很多厂商（尤其是H3C V7平台）的防火墙，为了避免海量日志冲击系统性能，默认启用了日志缓存发送功能。

• 工作机制：当同一数据流（即相同的五元组：源IP、目的IP、源端口、目的端口、协议）的第一个数据包匹配策略并生成日志后，设备不会立即发送，而是会缓存这条日志并启动一个5分钟（不可修改）的定时器。

• “合并”记录：在这5分钟内，如果有新的流量匹配了这条缓存的日志，设备会增加命中次数，但不会生成新的日志条目。只有当5分钟定时器到达，或者缓存已满时，设备才会发送一条合并后的日志。

• 结果：这就造成了“命中几十次才记录到一次”的现象。

⚙️ 其他可能原因

• 存储空间/缓冲区满：设备内存或硬盘（如有）的日志缓冲区被写满后，新日志会覆盖旧日志或被丢弃。

• 日志级别过滤：如果全局日志级别设置过高（如warning），informational级别的安全策略日志可能不会被记录。

• 策略未开启日志：需确认该安全策略规则已明确勾选“记录日志”或配置了logging enable命令。

• 快速日志输出配置：如果配置了customlog将日志发往外部服务器，可能导致本地的logbuffer里看不到日志。

🛠️ 解决方案

根据你的需求，有两种解决方案：

方案一：关闭缓存，启用实时发送（实时性要求高）

如果你需要实时看到每一条匹配日志，可以关闭缓存机制：

1. 登录防火墙命令行界面。

2. 进入系统视图。

3. 执行命令：aspf log sending-realtime enable。

注意：这会显著增加系统负载和日志量，请评估设备性能后再操作。

方案二：保持缓存，理解机制（追求性能稳定）

如果你更关注设备性能，可以保持默认的缓存机制。理解它“合并记录”的工作原理后，这就不是问题了。

🔧 排查步骤

如果以上方案都不适用，可以按以下步骤排查：

1. 确认策略配置：检查安全策略是否已开启日志记录功能。

2. 检查存储空间：查看设备内存或硬盘（如有）的剩余空间是否充足。

3. 检查日志级别：确保info-center的日志级别不高于informational。

4. 检查日志输出方向：确认日志是否被定向发送到了外部服务器。

看看其他的策略有没有勾选日志记录，有的会话长连接保持会使用之前的，需要断开后重新触发，防火墙才会增加计数

H3C SecPath 防火墙 安全策略日志 “命中几十次才记录一条” 完整根因分析
现象描述：策略已经开启logging enable，流量持续匹配策略，但是日志断续输出，不是每条命中都生成日志。
先区分平台：F1000-A-G5/F5080 这类 Comware V7 防火墙，安全策略日志默认是【缓存聚合模式】，不是每条报文都打日志，这是最核心诱因。
一、头号根源（90% 同类故障）安全策略日志【缓存发送机制】
官方机制说明
plaintext
security-policy log real-time-sending enable
默认关闭（缓存模式）：同一五元组数据流，首报文输出日志；之后启动5 分钟聚合定时器。5 分钟内反复命中同一条流，不会重复产生日志，等到周期到达才再次输出。
这就表现为：流量一直在跑、策略计数器持续上涨，但是很久才出现一条日志，看上去 “命中几十次才记录一次”。
开启实时发送：新建会话立即输出日志，同一条持续流依然不会每条报文打印，只会在会话新建 / 销毁产生日志；无法实现每个报文都记录（防火墙硬件性能不允许）。
⚠️重要概念区分
安全策略日志 ≠ 报文日志；防火墙不支持逐报文记录日志，只基于会话粒度生成日志。持续长连接（数据库、监控、TCP 长流）只会间歇性输出日志，属于设计机制，不是故障。
二、第二类诱因：全局重复日志抑制
如果配置了这条：
plaintext
info-center logging suppress duplicates
设备识别到连续相同内容日志，自动抑制重复输出；只在周期结束汇总打印一条，同样造成日志稀疏。
三、第三类诱因：信息中心限速 / 缓冲区溢出丢失日志
全局日志处理存在每秒条数上限
plaintext
info-center rate-limit global-threshold 400
所有模块日志总量超出阈值，新产生日志直接丢弃；高峰期策略日志丢失。
2. info-center logbuffer size 缓冲区容量不足，日志来不及转发到 syslog 服务器，被覆盖丢弃。
3. syslog 服务器接收缓慢、网络丢包，防火墙发送队列积压溢出，日志丢失。
四、第四类容易混淆的人为误解
策略计数器持续上涨 ≠ 会持续输出日志
display security-policy rule all match count 不断增加，只是报文匹配策略；安全策略日志基于会话，不是报文。
长连接只建立一次会话，后续大量报文不会反复触发日志。
NAT 场景误判：策略匹配是转换前 / 转换后五元组，日志识别流产生聚合。
区分【安全策略日志】和【流量 flow 日志】
安全策略日志：策略匹配事件（新建会话触发）
flow 日志：会话结束输出流量统计；想要持续流量统计建议开启 flow 日志，不要依赖策略日志。
分层整改方案（按优先级操作）
1、开启安全策略日志实时发送（优先执行）
plaintext
system-view
security-policy ip
security-policy log real-time-sending enable
作用：取消 5 分钟长周期缓存，新建会话立刻上报日志；改善日志间隔过长问题。
限制：依旧不能做到每条报文打印，长连接仅会话建立时产生日志。
2、关闭全局重复日志抑制（审计场景需要完整日志时）
plaintext
undo info-center logging suppress duplicates
3、优化信息中心，减少日志丢弃
plaintext
# 扩大本地日志缓存
info-center logbuffer size 10000
# 调高全局日志处理上限（根据设备性能适度调整）
info-center rate-limit global-threshold 800
# 放行防火墙本地访问syslog服务器的安全策略（避免日志报文被拦截）
4、长期方案：分清需求，选择正确日志类型
场景 A：故障排查、想看流量何时新建连接
维持【安全策略日志】，开启 real-time-sending 即可。
场景 B：想要统计持续流量、每段连接流量大小
改用 Flow 快速日志（customlog）
安全策略日志天生不适合持续流量监控，flow 日志在会话老化时上报流量字节数，更适合带宽审计。
plaintext
nat log enable
customlog format flow
customlog host X.X.X.X export flow
五、关键澄清（很多人踩坑）
✅正常现象：TCP 长连接（监控、数据库、堡垒机）一条会话持续几小时，只会产生 1~2 条安全策略日志；大量报文复用同一个会话，不会每条都打日志。
❌异常现象：频繁新建销毁大量短会话（http 短时访问），日志长时间一条都不出现 → 属于日志丢弃，需要排查限速、syslog 连通性。
最简验证命令
plaintext
# 查看策略匹配计数
display security-policy rule all | include logging enable\|Match count
# 查看信息中心是否存在日志丢弃
display info-center statistics
# 查看安全策略日志全局配置
display security-policy configuration | include log
落地实施顺序
开启 security-policy log real-time-sending enable，观察日志输出密度；
关闭重复日志抑制 undo info-center logging suppress duplicates；
核查 info-center 限速、日志服务器连通性；
如果需要持续流量审计，部署 flow 快速日志替代安全策略日志。