日志管理需规范级别、轮转、多进程写入及JSON格式：INFO仅用于可忽略操作，WARNING标记异常前兆；RotatingFileHandler须设maxBytes和backupCount；多进程用QueueHandler避免冲突；JSON日志用python-json-logger统一格式。
日志级别选错，INFO 和 WARNING 混用导致告警失灵
运维最怕的不是出错，而是出错了没被发现。很多团队把所有非错误信息都打成 INFO，结果监控系统只盯 WARNING 以上，漏掉关键异常前兆——比如连接池持续超 80%、重试次数突增、HTTP 5xx 响应但未抛异常。
实操建议：
立即学习“Python免费学习笔记（深入）”；
-
INFO只用于「预期内、可忽略、无需人工介入」的操作，如服务启动、定时任务开始/结束 - 接口返回非 2xx 但程序没崩？打
WARNING；重试第 3 次失败？打WARNING；DB 连接耗时 >500ms？打WARNING - 别依赖
logging.basicConfig(level=...)全局设级，用logger.setLevel()精确控制每个 logger 实例，避免第三方库日志淹没主线程
RotatingFileHandler 配置不当引发磁盘爆满
默认不设 maxBytes 或 backupCount，日志文件越滚越大，某天凌晨磁盘 100%，服务全挂。更隐蔽的是用 TimedRotatingFileHandler 却没配 utc=True，跨夏令时导致日志轮转错乱，旧文件不删、新文件不建。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 强制设置
maxBytes=10485760（10MB）+backupCount=7，确保最多占 80MB 磁盘 - 用
RotatingFileHandler而非TimedRotatingFileHandler，除非真需要按天切分；若必须按天，请加utc=True和atTime=datetime.time(0, 0, 0) - 在启动脚本里加检查：
du -sh /var/log/myapp/*.log*，超过阈值发钉钉预警，别等 OOM
多进程下 FileHandler 写日志丢行或错乱
用 multiprocessing 启多个 worker，每个进程都开自己的 FileHandler，结果日志时间戳乱序、同一行被截断、甚至出现半条 JSON。根本原因是多个文件描述符同时写一个文件，OS 不保证原子性。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 禁用各进程直连文件，改用
QueueHandler+QueueListener：worker 把日志塞队列，主进程单点消费写磁盘 - 若必须用文件，用
ConcurrentLogHandler（需 pip install），它内部用文件锁规避竞争 - 绝对不要在子进程中调用
logging.basicConfig()—— 它会覆盖 root logger 的 handler，造成重复输出
JSON 日志字段缺失或类型错乱，ELK 查不到数据
想把日志送进 Elasticsearch，手写 json.dumps() 拼字符串，结果 timestamp 是 str 不是 ISO8601，duration_ms 是 float 带小数点，Kibana 解析失败；或者漏传 service_name，导致跨服务链路串不起来。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
python-json-logger库，配JsonFormatter(fmt='%(asctime)s %(name)s %(levelname)s %(message)s %(funcName)s')，自动处理时间格式和空值 - 在
LoggerAdapter里预置公共字段：extra={'service_name': 'api-gateway', 'env': 'prod'}，避免每个logger.info()都手动传 - 上线前跑个校验脚本：抽 100 条日志
json.loads(line)，检查 key 是否全、timestamp是否能被dateutil.parser.parse()解析
