运维工程师看日志的态度有个转变过程：早期恨不得全量记——出问题有据可查；流量上来后被日志反噬——磁盘撑爆、写入拖慢、查询如泥。今年我们在高并发服务上落了日志采样方案。这篇讲清采样的设计逻辑和实操。结论先说：高并发下的日志策略不是记全，是记对——错误全量记，正常按比例采，热点按需补，三条规则下去，日志量砍九成，排查能力不减反增，因为真正有信息量的日志不再被淹没。
一、全量日志的三宗罪
1.1 被日志吃掉的机器
先摆事实：核心交易服务峰值每秒两万请求，全量访问日志每秒四十兆，一天三个多T。三宗罪依次到来：磁盘罪——日志盘三天一轮转，轮转间隙磁盘告警常客；性能罪——日志写入占用一成的请求耗时，高并发下这个开销实打实挤占了业务吞吐；检索罪——出问题想查一条日志，在几亿行里捞，查询工具先崩了。日志本为排障而生，量大到病态后，它自己成了要排的障。
1.2 日志的信息密度定律
统计了我们日志的信息密度：百分之九十九点九的行是正常请求记录——参数、耗时、状态码全绿——它们在排障时的使用率不到千分之一；千分之一的错误行、慢请求行，使用率接近百分之百。信息密度定律：日志的价值分布极度不均，绝大多数行是沉默的大多数，从不被读。采样方案的哲学从这里来：与其记全了再淹没有价值的，不如只记有价值的加少量样本。
二、采样方案的三层设计
2.1 错误全量：一条不漏
头一层铁律：错误日志全量记，永不采样。错误行是排障的黄金——异常堆栈、错误码、失败上下文，一条都不能少。不仅全量，还加权保障：错误日志走独立缓冲区，高并发下日志系统过载时，错误通道优先保送；错误日志的保留周期加倍——正常日志七天，错误日志九十天。这层的逻辑：日志预算要花在刀刃上，错误就是刀刃，宁可正常日志少记，错误行一条不弃。
2.2 正常采样：千分之几的样本
第二层：正常请求按比例采样。采样率的定法：目标日志量倒推——磁盘预算除以单行大小，得出每天可承受行数，除以请求总量，得采样率。我们定在千分之三：正常请求一千条记三条。采样实现：
log_sampling:
error: 1.0 # 错误全量
slow_request: 1.0 # 慢请求全量(耗时>500ms)
normal:
ratio: 0.003
rules:
- user_level: vip # VIP用户请求加倍采样
ratio: 0.02
- api: /payment/* # 支付类接口加倍
ratio: 0.05
- new_version: true # 新版本放量期全采
ratio: 1.0
纯随机之外，加权采样保关键：VIP 用户、支付链路、新版本灰度期——这些场景的采样率单独调高甚至全采。正常日志的角色从全量档案变成抽样调查——统计趋势、还原典型路径，抽样够用；真出问题，靠的是错误全量和下一层的按需补采。
2.3 热点补采：出问题时的临时全量
第三层是采样的动态阀门：常规时期千分之三，异常时期按需拉满。触发方式两种：自动触发——错误率超过阈值，系统自动把相关服务日志采样率拉到全量，持续十分钟或错误率回落；人工触发——排障时一键拉全量，限定时段和接口。这层设计解决了采样的先天缺陷——采样期间漏掉的现场，出问题时要能临时看全。阀门机制的要点：自动恢复——临时全量到点自动回落，防止拉上去忘了收，日志再次爆炸；留痕——每次采样率变更记录在案，事后复盘能还原当时的记录密度。
三、配套的工程细节
3.1 链路采样的一致性
分布式调用链下的采样有讲究：同一请求跨服务透传采样标记——头一个服务采样命中，整条链路的各服务都记，没命中全链路都不记。不然采样割裂，链路追踪图七零八落，排障时拼图都拼不齐。采样标记走调用上下文传递，实现一次，全局生效——这个细节没做，链路追踪的采样数据基本没法用。
3.2 采样日志的统计还原
抽样数据做统计要还原总量：报告里的请求量、耗时分布，用采样率反推——样本量除以采样率。这里有个纪律：还原统计要标注置信区间，样本量小的时段（低峰期千分之三采出来没几条），数字波动大，报告注明仅供参考。用样本讲故事可以，把样本当全量讲就是误导——采样体系里的人要时刻记得手里是抽样，不是普查。
3.3 结构化先行：采样的前提
采样方案成立的前提是日志结构化：每条日志带齐请求标识、用户标识、接口、耗时、状态码这些维度字段，采下来的样本才可分组可对比。纯文本日志采了样也难用——样本之间没有可比的维度。我们先做了半年的结构化改造，日志字段规范化，然后采样水到渠成——顺序别颠倒：先结构化让每条日志都有信息量，再采样挑选留多少。
四、效果与边界
4.1 数字对比
采样方案运行半年：日志总量降九成——从日均三个T到三百G；磁盘轮转周期从三天到一个月，告警清零；日志写入开销从一成降到忽略不计；错误排查的日志检索速度提升十倍——因为错误日志不再淹没在海量正常行里。团队评价较妙的一条：以前翻日志像垃圾堆里找钥匙，现在是钥匙盒里挑钥匙——信息没少，噪音没了。
4.2 采样的边界认知
采样的适用边界：高并发、低单条价值的日志——访问日志、常规业务流水，适合采；低频、高价值的日志——审计日志、安全事件、交易凭证，永不采，全量留档。安全审计日志碰采样是合规红线，这条边界划死。我们的分类清单贴在运维手册头一页：什么可采、什么不可采、什么出事临时采——边界清楚，采样才走得稳。
五、总结
日志采样的完整方案：错误和慢请求全量铁律，独立通道优先保障；正常请求千分之几随机采样，关键场景加权提采；异常时自动加人工的动态阀门临时拉全量；链路采样标记透传保全图，统计还原标注置信，结构化改造做在前。核心理念回到那句话：高并发下不必记下每一条——日志系统的目标是排障效率，不是数据囤积，记对的那一条，胜过记全的一万条。
常见问题
问:采样后恰好漏了关键请求的日志,怎么办?
答:三重兜底:动态阀门——错误率一旦抬头,相关服务自动拉全量,真正的故障期基本都在全量记录中;按需补采——用户反馈某笔请求有问题,业务数据库里该请求的结果数据还在,结合错误日志和上下文拼图;样本回归——统计层面,单个样本缺失不影响群体分析。要坦率承认:采样确实可能漏掉个别静默异常,这是拿九成日志成本换来的代价——权衡的依据是漏的概率和存的成本,每个团队按自己的业务定。
问:采样率定多少合适,有经验值吗?
答:从预算反推,不从感觉出发:先算日志系统每天能舒服吃多少——磁盘、写入、检索三头都舒服的量;再除以请求总量,得基础采样率。我们的经验区间:日均亿级请求的服务,千分之一到千分之五;千万级,百分之一到三;百万级以下,通常不值得采,全量也没多少。另外留个动态调整:连续三个月日志量都用不满预算,采样率上调;反之下调——采样率是运营参数,不是一次定终身的常量。
问:开发调试时需要详细日志,采样会不会碍事?
答:开发和生产是两套策略:开发环境全量加调试级别,一个字不采;生产环境采样加生产级别。要防的是把调试习惯带进生产——代码里的调试日志,生产统一级别过滤,不落盘。另外生产排障需要临时详细日志时,走动态阀门的人工触发,指定接口指定时段拉全——渠道留着,别让开发为了自己方便在生产常年开全量。
问:链路追踪系统和日志采样,怎么配合?
答:一个原则:采样决策链路优先。链路追踪系统自己有采样策略——头部采样、尾部采样,它决定哪些请求成链;日志采样跟随链路的决策——链路采了的请求,它的日志同步采,保证有链就有日志可查;链路没采的,日志按常规比率走。两边各自采样互不知晓的话,常见惨状是链路图在,日志没有;日志在,链路断——排查时两头对不上,先对齐采样策略,这是分布式日志体系的隐形地基。
