flush函数在python logging模块中是用于将缓存的日志立即发送到目标端的。如官方文档
我在log_handler.py文件中看到，QueuedLogHandler重写了flush，调用stop杀死了推送线程：
def flush(self):
self.stop()这个导致的一个问题是，如果先实例化了sls的logger，其他地方如果再次调用logging.config.***Config的话，会导致sls的logger无法发送日志：
# 配置
logging.config.fileConfig('logging.conf')
logger = logging.getLogger('sls')
# 这条日志可以记录
logger.info(f"test1 in sls: {time.time()}")
logging.config.dictConfig({'version':1})
# 这条日志不会被记录
logger.info(f"test2 in sls: {time.time()}")我遇到的场景是：我使用fastapi+uvicorn提供http服务，启动后sls日志无法记录。
分析后发现uvicorn在初始化时内部有调用logging.config.dictConfig，里面会调用_clearExistingHandlers方法，此方法内部调用了handler的flush，sls的flush是调用stop，导致worker死掉了。
解决方法也很简单，删掉flush的重写部分就可以。
flush函数在python logging模块中是用于将缓存的日志立即发送到目标端的。如官方文档
我在log_handler.py文件中看到，QueuedLogHandler重写了flush，调用stop杀死了推送线程：
这个导致的一个问题是，如果先实例化了sls的logger，其他地方如果再次调用logging.config.***Config的话，会导致sls的logger无法发送日志：
我遇到的场景是：我使用fastapi+uvicorn提供http服务，启动后sls日志无法记录。
分析后发现uvicorn在初始化时内部有调用logging.config.dictConfig，里面会调用_clearExistingHandlers方法，此方法内部调用了handler的flush，sls的flush是调用stop，导致worker死掉了。
解决方法也很简单，删掉flush的重写部分就可以。