上月我见过一个做金融教育投放的团队，他们服务器没扩容，CPU 和带宽其实都正常，但磁盘使用率每天下午就准点逼近阈值，很规律。后来排查发现，问题出在分流命中日志全量写入，日志采样率没有做差异化设计。高峰时段大量重复参数把磁盘和 I/O 一起拖高了。说白了，这不是流量问题，而是记录策略的取舍问题。你想，记录太密，存储与写入开销会反过来侵蚀页面响应；记录太稀，误判排查退化得跟猜谜一样。所以，要配置合理的日志采样率，先别急着拍一个比例，得先有一套判断标准。
判断标准：排障闭环比日志行数更重要
判断日志策略是否合理，不只看每小时写多少行。我习惯看三个条件：高峰时段能否在五分钟内检索到目标会话或设备指纹；日志目录增长是否触发容量告警；主请求的 P95 延迟是否因日志写盘而抬升。这三个条件都没恶化，说明当前记录密度可接受；若只能满足两个，就要区分哪些分流日志为故障排查服务，哪些只是重复流水。这里容易搞混的是，日志采样率调整的目的不是单纯减少写入，而是提高每条记录的有效命中比例。
全量记录与固定采样：分水岭在哪里
全量记录适合流量量级不大、规则库刚上线、排障频率高的阶段。比如日均点击只有两三千，按一天 24 小时、每次点击产生 8 到 12 条分流与回源日志估算，全量写入也只有几万到十几万条，磁盘和写入压力都可控。此时保留完整请求细节，比事后补采样更划算。事后补采样经常补不出当时的完整参数链。
固定采样适合流量过万且规则相对稳定的状态。常见做法是每 5 到 10 条命中事件只记 1 条，或者在应用层用随机数决定是否落盘。固定采样能保留总体分布，却会丢失单次异常证据。我见过一个做教育投放的小团队，把采样率从 10% 调到 1% 后，磁盘水位下降很明显，但后来某类设备指纹被连续误判时，只能看到“有若干请求命中异常规则”，无法还原单次请求的完整参数链，最后只好临时恢复全量记录才能定位。这个案例很典型，固定采样适合看趋势，不能当排障证据。
条件采样：把记录留给决策分叉点
比单纯降低比例更有效的是条件采样。它不是按概率记录，而是只记录“规则链在决策分叉点”附近的事件。常见触发条件包括：关键词参数命中但设备指纹缺失；UA 特征与 TLS 指纹不一致；同一会话在短时间内被不同规则命中；跳转链路出现重试或状态码异常。这些请求通常只占几个百分点，却承载了大多数误判线索。说白了，就是把记录留给那些真正需要决策的点。
条件采样的另一个好处是与规则链的短路顺序配合：当过滤型条件先行短路了后续决策时，只有记录被短路前的参数，才能判断是顺序问题还是判断条件本身失效。相关取舍可参考规则链的短路顺序调优。
选择边界：按阶段和异常场景切换
落地时可以按三条边界切换。日均点击低于三五千且磁盘余量充足，全量记录是最省心的选择；日均点击过万、规则库进入稳定期，固定采样 5% 已经能覆盖大多数趋势分析；而在规则库迭代、审核驳回升高或误判率突然异常时，应临时把采样率调高，并对冲突型事件开启条件采样，而不是长期全量。这里容易搞混：调高采样率不是让你又回到全量，只是临时动作。
同时要避免把所有日志都走同步写盘。动态分流对延迟敏感，落地页响应通常希望在几百毫秒内完成，日志写入应使用缓冲或异步落盘；但异步带来的问题是进程异常退出时可能丢失最后一段日志。因此只有错误级和冲突级事件才值得同步记录，普通命中流水可降级为异步或延迟批量写入。采样与时序验证也要配合，不能只记结果不记触发时间，否则后续无法还原阈值调整依据，可参考访客分层采样验证时序。
小结
日志采样率没有全局最优值，只有与当前投放阶段、流量量级、规则库成熟度和排障时效要求的匹配。全量记录解决单次排障证据留存，固定采样解决长期趋势观察，条件采样解决有限成本内保留决策分叉。三者可以共存，关键是让普通流水安静，让异常请求留下完整链路。
常见问题
日志采样率调低会影响误判排查吗？
会。固定采样比例越低，单次异常请求的完整参数链越可能缺失，尤其在高流量场景下。建议在规则库迭代、误判升高时临时提高采样率或开启条件采样，普通稳定期再降低比例。
分流日志全量记录需要预留多大磁盘？
没有固定数值，与点击量、每次请求产生的日志条数、单条日志长度有关。日均点击三五千时，全量记录通常一天几万到十几万条，按单条 200 到 500 字节估算，日增量在十到几十 MB 级；点击过万后建议做采样或轮转。
条件采样应优先记录哪些字段？
至少记录时间戳、会话 ID、设备指纹状态、命中规则、页面版本、跳转状态码和关键输入参数。不要记录完整账户或用户身份信息，字段越少越容易在高峰期快速检索。
高峰期可以临时关闭分流日志吗？
不建议整体关闭。可以临时降低普通命中流水的采样率，同时保留冲突级和错误级日志。整体关闭虽然能释放磁盘与 I/O，但会让异常无法回溯，事故时长通常比资源压力代价更高。
延伸阅读
本文讨论的是分流日志采样率的选择边界，若你同时关心多平台分流与落地页配置差异，可以通过下面这篇补充阅读扩展场景判断。
