日志采样详解：用更少的日志获得同样的洞察力

日志采样（Log Sampling）是指从产生的全部日志中按规则只记录一部分代表性条目，将其余安全丢弃的技术。 它的目标是：在保证分析结论不失真的前提下，把日志量降下来，让存储、处理与成本都回到可控范围。

一个直观例子：某接口依赖的第三方服务宕机几秒，一千个请求全部失败。不采样就产生一千条几乎相同的错误日志；配置"每 10 条相同日志留 1 条"后只剩 100 条——事件全貌照样清晰，成本却降了一个数量级。

核心要点速览

• 采样的本质：保留代表性子集，丢弃冗余重复；
• 三大收益：降存储成本、提查询性能、让分析聚焦关键日志；
• 三种策略：随机采样（等概率）、时间采样（限流速）、哈希采样（按请求 ID 全留或全不留）；
• 采样要在成本失控之前引入，而非之后补救；
• 观测云配合手段：黑名单过滤无效日志、多索引差异化存储、监控日志摄入量突变。

为什么值得采样

1. 存储需求骤降：只留存子集，TB 级日志系统的存储账单立竿见影地下降；
2. 分析性能提升：查询的数据量变小，检索与聚合更快；
3. 全链路成本下降：采集、传输、处理、存储每个环节都受益；
4. 分析更聚焦：可以设计"错误日志多留、INFO 少留"的策略，把注意力导向问题；
5. 可持续扩展：系统规模增长时，日志体系不会先被数据量压垮。

三种主流采样策略

1. 随机采样

每条日志以固定概率被记录（如每 5 条留 1 条），不看内容、不看级别。以 Go 的 Zerolog 为例：

log := zerolog.New(os.Stdout).With().Timestamp().Logger().
    Sample(&zerolog.BasicSampler{N: 5}) // 每 5 条留 1 条

优点是实现最简单；缺点是一视同仁——错误日志和健康检查日志被丢弃的概率相同，可能丢掉关键信息。

2. 基于时间的采样（限速）

按时间窗口限制输出条数，例如每秒最多记 3 条：

log := zerolog.New(os.Stdout).With().Timestamp().Logger().
    Sample(&zerolog.BurstSampler{Period: time.Second, Burst: 3})

它能硬性压制日志洪峰，但可能漏掉窗口内的关键日志。改进版（如 Zap 的 Sampler）按"级别 + 消息内容"分别限速——相同内容的 error 每秒留 3 条，不同内容的 error 不受影响，兼顾降噪与保真。

3. 基于哈希的采样

分布式系统中最讲究的策略：对请求的唯一标识（如 trace_id）做哈希，按哈希值决定这个请求的所有日志全留或全不留。这样采样后的数据集里，每个被保留的请求都有完整的调用链日志，不会出现"一半服务的日志被采、另一半被丢"的残缺现场。

这是微服务场景的首选——采样不能以牺牲请求级可观测性为代价。

采样在哪一层做

观测云落地：框架不支持采样时，可用采集端能力达到类似效果——用黑名单规则直接过滤已知无效日志（健康检查、心跳等），用 Pipeline 的 drop() 按条件丢弃匹配条目，在日志进入平台前完成减量 。

采样的配套保障

采样是有损的，需要两道保险：

• 关键日志豁免：ERROR/FATAL 不采样或高保留率，只对健康检查、访问日志等高频低价值日志采样；
• 摄入量监控：为日志摄入量建立监控器，量异常飙升（如某服务突发错误风暴）时触发告警——既防成本失控，本身也是一个故障信号 。

总结

日志采样的哲学是"更聪明地工作，而不是更用力地存储"。理想策略：低价值高频日志（INFO/访问日志）激进采样，高价值日志（ERROR 及以上、关键业务事件）完整保留，微服务场景用哈希采样保证请求完整性。趁成本还没失控就把它纳入日志体系——事后补装的阻力远大于事前内建。

常见问题（FAQ）

Q：采样会影响故障排查吗？
合理策略下不会。排障依赖的是"有代表性的完整现场"而非"全部数据"；错误日志通常豁免采样，哈希采样还能保证被采请求的日志链完整。

Q：采样率设多少合适？
从日志量与预算倒推：先测算当前摄入量和成本构成，再决定采样比例。常见起点是高频 INFO 日志 10%–20%，观察分析效果后再调整。

Q：观测云里黑名单和采样是什么关系？
黑名单是"确定性过滤"（明确不要的整条丢弃），采样是"概率性保留"（同类日志留一部分）。两者互补：黑名单干掉已知噪声，采样压制剩余高频日志。

---

系列阅读：降低日志成本七步法 ｜ 日志最佳实践十二条