性能优化指南
如果出现服务器磁盘占用较高，或者项目的 CPU、内存占用较高，可以按照这份文档进行优化处理。
先分清：引擎侧 vs 日志侧
流盾把「拦请求」和「记日志」拆开了：
访客请求
→ 引擎侧（OpenResty + Lua + Redis）：匹配规则、限速、拦截/挑战、回源
→ 需要记日志时：异步写入 Redis Stream
→ 日志侧 Worker 消费 → 写入 ClickHouse（防护日志、统计、明细）| 一侧 | 负责什么 | 资源特点 |
|---|---|---|
| 引擎侧 | 真实 IP、白/黑名单、例外、限速、自定义规则、人机验证；把命中结果交出去 | Redis + Lua 热路径，单次请求通常亚毫秒；CPU / 内存占用通常很小 |
| 日志侧 | 从 Redis Stream 批量入库；供总览、防护日志、预警统计、AI 取证等查询 | 数据落在 ClickHouse；流量大或长期全量留存时，更容易占磁盘和 CPU |
性能影响结论
真正影响磁盘占用、CPU 和内存性能的，是日志记录侧，防护引擎所占用的性能非常小！
建议怎么调
1. 新站：先全量记日志
站点刚接入、规则还在磨时：
- 控制模式用 手动，并打开 全局日志记录
- 观察采样率 保持较高（默认约 100% 即可）
- 日志保留天数 可先用默认 30 天
这样总览、防护日志、预警统计更接近真实情况，方便对照 渐进上线防护 做「先观察、再拦截」。
2. 规则稳定后：缩短保留天数（省磁盘）
网站跑稳、策略基本定型后（常见是 约 10 天以上，以你自己摸清误伤为准）：
- 到 日志保留天数，可从默认 30 天 降到 10 天 左右
- 范围允许 1～365 天；越短越省磁盘，事后可追溯的窗口也越短
3. 流量大时：降低观察采样率（减写入）
观察模式命中量往往远大于真正拦截。流量上来后：
- 下调 无人查看时观察采样率（例如先试 10%～50%）
- 需要盯日志排查时，可临时提高 有人查看时观察采样率
- 也可打开 不记录观察模式（只保留拦截/挑战等处置日志，观察命中更少）
采样只影响「写不写日志」，不改变规则是否命中、是否拦截。
高流量场景也可改用「按流量自动启停」：平时少记，突增时再自动开记——细节见 系统设置 · 日志采样。
重要提醒：少记日志 ≠ 少防护
请务必读完
减少日志记录、降低采样率、缩短保留天数，都不会削弱规则与拦截引擎。
引擎仍按策略匹配并处置请求。变少的只有依赖日志入库后的展示与统计，例如：
- 预警通知里的次数 / 比率类统计
- 总览与防护日志里的统计排行
- 日志明细条数
采样率降低后，面板上的数字往往小于真实命中量，只能当趋势参考，不能当成精确计数。若正在应急排查或磨新规则，请先恢复较高采样或全量记录，再下结论。