#日志采样策略

当系统 QPS 达到数万甚至数十万时，每秒产生的日志量可能超过 GB 级别。全量存储所有日志的成本是不可接受的。日志采样（Log Sampling）是一种权衡策略：在保留关键信息的前提下，降低日志的存储和处理成本。

采样的核心挑战是选择偏差：如果采样不当，可能丢失「恰好」只出现一次但非常重要的信息。例如，一次罕见的内存泄漏可能只产生少量日志，采样后可能完全丢失。好的采样策略应该确保「异常信息不会被漏掉」。

#采样类型对比

#头部采样实现

头部采样是最简单的策略：在日志产生时，根据采样率随机决定是否记录。例如，设置 10% 采样率，只有 1/10 的日志被写入存储。实现方式可以是硬采样（随机丢弃）或软采样（只保留满足条件的日志，如 ERROR 级别全保留）。

OpenTelemetry SDK 支持配置日志采样器：

// 采样器配置：10% 采样率，但 ERROR 级别全保留
Sampler sampler = Sampler.parentBased(
    Sampler.traceIdRatioBased(0.1),
    Collections.singletonList(
        new RuleSampler(
            (span) -> span.getStatus().getCode() == StatusCode.ERROR,
            Sampler.samplerAlwaysOn()
        )
    )
);

#尾部采样实现

尾部采样在数据进入存储之前进行聚合统计，只保留统计上有意义的样本。例如，统计每秒各类型日志的数量，如果某类型的日志数量异常高（可能是攻击或故障），则对该类型进行 100% 采样。

OpenTelemetry Collector 的 Tail Sampling Processor 是典型的尾部采样实现。它首先将所有日志缓存在内存中，等待一定时间窗口（如 30 秒），然后根据配置的策略决定哪些日志应该被发送到后端。支持的策略包括：错误日志 100% 采样、按 TraceID 采样（保留完整请求链）、按服务采样（保证每个服务都有日志覆盖）。

#智能采样实践

生产环境推荐多阶段采样策略：第一阶段在 SDK 层做基础采样（如 10%），确保存储成本可预期；第二阶段在 Collector 层对异常日志（如 ERROR、WARNING）做补偿采样；第三阶段在存储层定期分析日志分布，对热点服务进行动态调参。

这种策略的优势是：正常情况下存储成本可控，异常情况下关键日志不会丢失。Google 的 Cloud Logging、Datadog 的 Log Management 都采用了类似的多阶段采样设计。