日志量过大时先调级别还是做采样，取舍依据是什么

日志量突然变大时，通常先调低日志级别，再考虑采样。原因很简单：slog 的级别过滤可以在 Handler 的 Enabled 阶段尽早丢弃低优先级记录，而采样会保留一部分低级别事件，必须额外定义采样键、时间窗口和异常例外。错误、权限变更、订单状态变化等不可重复事件不应为了省空间而随机丢弃。

官方文档：https://pkg.go.dev/log/slog

先按日志价值判断该调级别还是采样

先问两个问题：这些记录是否能被同一事件键聚合，以及少掉一部分后是否仍能定位故障。如果答案分别是“不能”和“不能”，就不应采样。比如支付失败、鉴权失败、配置变更、数据写入失败都应保留；它们数量不大，却直接影响追责和排查。

可以把策略分成三层：Debug 记录先由级别门槛控制；请求成功、缓存命中这类高频重复事件可做比例或时间窗口采样；Warn、Error、审计事件全量保留。这样做比统一把所有日志降到 Error 更稳，因为后者会把定位上下文一起删掉。

用 LevelVar 动态收紧 slog 的最低级别

slog 内置的 JSONHandler 和 TextHandler 都支持 HandlerOptions.Level。传入固定的 slog.LevelWarn 后门槛不会变化；传入 *slog.LevelVar 则可以在多 goroutine 场景安全地调整级别。生产环境可以默认 Info，磁盘或下游写入压力升高时临时切到 Warn，排障结束再恢复。

package main

import (
    "log/slog"
    "os"
)

var programLevel = new(slog.LevelVar) // 默认是 Info，作为全局动态门槛

func newLogger() *slog.Logger {
    handler := slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
        Level: programLevel, // 低于当前级别的记录会尽早被 Handler 丢弃
    })
    return slog.New(handler)
}

func tightenForPressure() {
    programLevel.Set(slog.LevelWarn) // 只临时收紧，错误和警告仍然保留
}

func restoreNormal() {
    programLevel.Set(slog.LevelInfo) // 排障结束后恢复普通观测粒度
}

这里的“尽早”只表示 Handler 可以在处理记录的入口判断级别，并不代表业务参数一定不会被计算。如果某个日志参数本身需要昂贵的序列化或查询，调用前还可以用 logger.Enabled(ctx, level) 做保护。调级别适合处理一整类低价值日志，不适合解决单一业务事件异常重复的问题。

在 Handler 边界为重复事件做可解释采样

标准库 log/slog 提供 Handler 接口，但没有替你决定采样比例。采样层可以包住已有 Handler：先判断记录级别，再从事件名、路由或业务类型拼出稳定的采样键，最后按窗口或概率放行。关键是不要只按全局随机数采样，否则同一请求链上的记录可能互相失去关联。

实际工程中可以把采样配置放在自定义 Handler 或日志后端，并同时写出 logs_dropped_total、logs_kept_total 和按原因分类的计数。采样对象最好是成功请求、健康检查、缓存命中等可重放事件；遇到 record.Level >= slog.LevelWarn、带错误字段或审计事件标记时直接放行。

采样也要防止“异常把采样器打爆”：当错误率升高、某个路由出现突发失败或排障开关打开时，应暂停普通事件采样，恢复关键上下文。采样窗口、比例和例外规则写入配置，而不是散落在每个业务函数中。

用指标和回退开关验证日志策略

上线前不要只看文件大小。至少记录四项：级别过滤丢弃量、采样丢弃量、各级别保留量，以及错误事件的完整率。日志量下降但错误完整率也下降，说明策略过度；日志量不变而采样丢弃计数为零，说明采样键或 Handler 没有接入真正的输出路径。

建议把策略做成可回退的两档：正常档为 Info 加低风险事件采样，排障档为 Debug 或全量关键上下文。回退时先恢复错误和审计旁路，再决定是否打开 Debug，避免压力还没解除就把所有高频成功事件全部放出来。

• 确认 JSONHandler/TextHandler 使用了预期的 Leveler，而不是另一个默认 Logger。
• 确认采样键包含路由、事件名等稳定字段，不把用户隐私或完整请求体写进键。
• 确认采样器自身不会阻塞日志主路径，计数写入失败也不能反过来阻塞业务。
• 用一次可控故障检查 Error、trace_id 和关键状态变更是否仍能完整检索。

常见问题

把最低级别从 Info 调到 Error 能代替采样吗？

不能完全代替。它能快速降低一整类日志量，但会同时丢掉有助于解释成功请求和慢路径的上下文。是否调整要看这些上下文能否由指标、Trace 或按需 Debug 补回。

采样比例应该固定成 10% 吗？

不应直接套固定比例。先按事件重复度、故障价值和存储成本设定，再用保留量、丢弃量和错误覆盖率校准；不同路由可以使用不同采样规则。

LevelVar 适合频繁切换吗？

它适合运行期间安全地调整日志门槛，但不应把它当成高频业务开关。门槛变更要有权限、审计和自动恢复时间，避免排障结束后长期保持 Debug。

因此，日志量过大时优先用级别过滤清掉明确低价值的 Debug/Info；对仍然重复且可聚合的成功事件，再在 Handler 或后端做带键、带指标、可回退的采样。错误、审计和关键状态变化永远应当有全量保留路径。