Python logging.QueueHandler 队列满了怎么办：非阻塞日志丢弃策略与压测核对

接口本身只做一次数据库查询，压测时延却随着日志量一起上升，现场通常不是业务代码突然变慢，而是日志处理把请求线程拖住了。Python 的 logging.handlers.QueueHandler 默认用 put_nowait() 把记录放入队列；有限队列装满后，真正需要先回答的是“这条日志要阻塞请求，还是允许降级丢弃”，而不是盲目把队列调大。

如果日志不能反过来拖垮业务，优先采用显式的非阻塞降级：记录丢弃数量、保留 WARNING/ERROR 等关键级别，再用压测观察请求延迟和丢弃率。

先把基线测出来：消费者变慢时谁在付代价

先不要改成阻塞式 put()。我们构造一个容量为 2 的 queue.Queue，让 QueueListener 的消费者每次处理都暂停一小段时间，再从生产线程连续写入日志。这样能把“队列满”稳定地复现出来。

import logging
import queue
import time
from logging.handlers import QueueHandler, QueueListener

log_queue = queue.Queue(maxsize=2)
handler = QueueHandler(log_queue)
listener = QueueListener(log_queue, logging.StreamHandler())
listener.start()

logger = logging.getLogger("checkout")
logger.setLevel(logging.INFO)
logger.addHandler(handler)

for index in range(20):
    logger.info("checkout step=%s", index)
    time.sleep(0.001)

listener.stop()

这段代码的关键关系只有四个：QueueHandler 生产记录，put_nowait 尝试入队，queue.Full 表示容量边界被撞到，QueueListener 在另一条线程消费。调用链看清后，压测结果才有解释空间。

默认行为为什么会丢日志：queue.Full 不是业务异常

Python 文档把 QueueHandler.enqueue 的默认实现定义为调用 put_nowait()。队列已满时，emit 会调用 handleError；当 logging.raiseExceptions 为 False 时，记录可能被静默丢掉。这个设计保护了生产线程的速度，却不会替你建立丢弃计数。

因此，线上不能用“没有抛出异常”证明日志完整。更可靠的基线是记录：生产总数、明确丢弃数、消费者处理数，以及请求端的 P95/P99 延迟。

非阻塞降级怎么写：只让低价值日志让路

可以覆写 enqueue，在捕获 queue.Full 后递增 dropped_count。示例只把降级策略放在 INFO/DEBUG；真实审计事件不要和普通访问日志共用这条会丢弃的队列。

class DropWhenFullHandler(QueueHandler):
    def __init__(self, log_queue):
        super().__init__(log_queue)
        self.dropped_count = 0

    def enqueue(self, record):
        try:
            self.queue.put_nowait(record)
        except queue.Full:
            self.dropped_count += 1

drop_handler = DropWhenFullHandler(log_queue)
logger.handlers.clear()
logger.addHandler(drop_handler)

这里的验收不是“程序还在跑”，而是 dropped_count 是否可观测、ERROR 是否走独立可靠输出、队列恢复后消费数是否继续增长。若丢弃数持续增加，先降低日志量或加快消费者，再考虑扩大容量。

压测时要看哪些数据：容量不是越大越好

用一个可重复的本地实验观察三个状态：消费者正常、消费者变慢、消费者停止。不要把下面的示例数字当作通用性能结论；机器、格式化器和输出目标不同，结果会完全不同。

before = drop_handler.dropped_count
for index in range(1000):
    logger.info("batch=%s", index)
after = drop_handler.dropped_count
print({
    "dropped_count": after - before,
    "queue_size": log_queue.qsize(),
})

至少记录四项：请求延迟分位数、生产总数、dropped_count 增量、QueueListener 停止前是否仍有积压。qsize() 只能作为近似观察，不适合拿来做并发条件判断；队列空或满的瞬间都可能在下一次操作前改变。

三类边界别混在一起

如果业务要求每条日志都落盘，阻塞式队列只是把压力从日志线程转移到请求线程；这不是免费的可靠性。更稳妥的做法是把关键事件和普通诊断日志拆开，分别设定容量、告警与失败处理。

常见问题

QueueHandler 队列满了会直接抛出 queue.Full 吗？

默认路径会在 emit 内处理错误并调用 handleError，是否打印到标准错误还受 logging.raiseExceptions 影响；不要把它当成业务层可捕获的稳定异常接口。

把 maxsize 调得很大能解决问题吗？

只能延后撞满时间，不能解决消费者持续跟不上生产者的问题。仍需观察 dropped_count、积压和请求延迟。

什么时候应该使用阻塞式 put？

只有在调用方明确接受等待、且等待上限不会伤害请求时才考虑，并应设置超时和回退；审计事件更适合独立可靠通道。

QueueListener 停止前为什么要关注积压？

stop 会等待监听线程处理队列中的记录；退出前若积压过多，关闭时间和丢失风险都会上升，应把它纳入停机演练。

把结果带回生产配置

先用小容量队列复现满队列，再逐步增加容量并保持消费者处理速度不变。最终配置应写清日志级别、满队列策略、丢弃计数、关键事件的替代通道和告警阈值。只要请求延迟和日志完整性之间的取舍没有被量化，调大 maxsize 仍然只是把问题藏得更深。