Go Zerolog diode.Writer 队列满时为什么会丢日志

如果你把 \`zerolog\` 接到 \`diode.Writer\` 后发现日志数量少了，先不要把问题归咎于 JSON 编码。这个组件的核心取舍就是：让日志生产者尽量不被慢速输出端阻塞；当有界队列已经装满、底层 writer 又来不及消费时，新事件可以被丢弃。

官方地址：https://github.com/rs/zerolog

API 文档：https://pkg.go.dev/github.com/rs/zerolog/diode

队列满时丢日志是 diode.Writer 的非阻塞设计结果，不是“写入成功但后来凭空消失”。要接受这个取舍，就必须配置 Alerter 观察 missed 数量；如果日志绝不能丢，就不要把它当成可靠落盘队列。

先把生产者和消费者分开看

\`diode.NewWriter(w, size, pollInterval, f)\` 在 Zerolog 和真正的输出端之间增加了一个有容量的 many-to-one 队列。业务 goroutine 是生产者，调用日志方法后把数据交给队列；后台 poller 或 waiter 再把队列内容写入 \`w\`。两边速度相同的时候，日志会顺利穿过这层包装。

问题出在突发流量或输出端变慢时：生产者继续写入，消费者却只能按自己的速度取出数据。当队列达到 \`size\` 后，继续到来的事件没有等待位置。官方文档把这个行为直接描述为“writer 跟不上数据流时丢弃事件”，所以 \`size\` 不是“保证保存多少条日志”，而是“允许吸收多大的短时速度差”。

size 和 pollInterval 决定了什么

\`size\` 越小，越容易在突发期间触发丢弃；它越大，能吸收的短时积压越多，但也意味着更多内存和更长的排空时间。它不能修复长期的吞吐不足：如果输出端持续比日志生产端慢，队列最终仍会再次填满。

\`pollInterval\` 大于零时使用 poller，否则使用 waiter。这个参数影响后台消费方式，不会把一个有界、非阻塞的 writer 变成可靠消息队列。可以先把容量和输出端吞吐当成一组约束来讨论，再决定是否值得牺牲部分日志完整性换取业务线程不被拖慢。

用 Alerter 把丢失变成可观察信号

package main

import (
    "os"

    "github.com/rs/zerolog"
    "github.com/rs/zerolog/diode"
)

func newLogger() (zerolog.Logger, func() error) {
    // missed 是本次回调统计到的丢失数量，应接入监控或降级日志。
    alert := func(missed int) {
        // 这里不要再写回同一个 diode，避免告警和业务日志互相挤压。
        println("zerolog dropped messages:", missed)
    }

    // size 只负责吸收短时突发，不能承诺永不丢失。
    writer := diode.NewWriter(os.Stdout, 1000, 0, alert)
    logger := zerolog.New(writer)

    // Close 等待后台消费结束，并在底层 writer 可关闭时释放它。
    return logger, writer.Close
}

这里的告警回调不是补发机制，\`missed\` 也不是丢失日志的完整内容。它的价值是让系统知道“发生过丢弃”，从而可以结合流量、输出延迟和队列容量调整方案。告警本身最好走独立、低频、不会再次占满同一队列的通道。

我的落地检查表

相关问题

把 size 调得很大是不是就不会丢？

不能保证。大容量只延后队列满的时刻；只要平均生产速度长期高于消费速度，积压仍会增长。容量应按突发量和可接受的内存预算设置，并配合 missed 监控。

哪些日志不适合使用 diode.Writer？

需要逐条追溯的审计记录、账务事实或必须完整保存的安全事件，不适合把丢弃作为正常退路。此时应选择具备持久化、背压或重试语义的输出方案；diode.Writer 更适合对延迟敏感、允许降级的运行日志。

所以，队列满时丢日志并不是 Zerolog 的隐藏 bug，而是 \`diode.Writer\` 用非阻塞换吞吐的明确边界。真正需要修复的通常不是“把丢失藏起来”，而是确认日志等级、输出吞吐、告警和关闭流程是否与这项取舍一致。