微服务日志必须含 trace_id 且为单行 JSON 格式，使用 contextvars 注入 trace_id、python-json-logger 库序列化、ISO8601 UTC 时间戳（timestamp 字段），线上仅保留 levelno。
日志格式必须包含 trace_id 才算可用
微服务或分布式系统里，没有 trace_id 的日志等于丢了一半线索。Python 标准 logging 默认不带上下文透传能力，直接用 %(message)s 或 %(asctime)s 格式输出，查问题时根本串不起一次请求。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
threading.local或contextvars.ContextVar（Python 3.7+）存trace_id，在每次请求入口生成并绑定 - 自定义
logging.Filter，把trace_id注入到LogRecord属性中，再通过%(trace_id)s在格式字符串里引用 - 避免用
extra参数临时传trace_id—— 中间件、异步调用、线程切换后容易丢失
JSON 格式日志不是“更高级”，而是运维刚需
纯文本日志在 ELK、Loki 或云厂商日志服务里解析困难，字段提取靠正则，一改格式就崩。JSON 日志能被直接 ingest、filter、聚合，前提是每条日志是合法单行 JSON。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 别手写
json.dumps()拼接字符串 —— 容易漏转义、字段冲突、非 UTF-8 字符崩溃；用python-json-logger库的JsonFormatter - 确保
exc_info=True时异常栈也被序列化进exc_info字段，而不是混在message里 - 禁用
%(pathname)s和%(funcName)s等含斜杠/括号的字段名 —— JSON 解析器可能报错；改用file_path、func_name这类安全 key
levelno 和 levelname 都要保留，但别同时用
levelno（如 40）适合监控告警做数值比较，levelname（如 "ERROR"）适合人眼快速识别。但日志字段冗余会增大体积、拖慢序列化，尤其高频 INFO 日志。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 线上环境只留
levelno，告警规则统一用数字阈值（例如 >30 表示 WARNING 及以上） - 开发或本地调试可启
levelname，配合颜色高亮（用coloredlogs库） - 绝对不要在格式字符串里写
%(levelname)s:%(levelno)s—— 字段重复且无实际用途
time 字段必须用 ISO8601 UTC，别信 local time
服务器跨时区、容器漂移、日志聚合时，本地时间（%(asctime)s）会导致时间乱序、窗口计算错误。Kibana 或 Grafana 按时间轴展示时，本地时间戳可能倒流。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 禁用
logging.Formatter默认的asctime，改用%(created)f（Unix 时间戳秒级浮点数），再在 formatter 的formatTime方法里转成 ISO8601 UTC 字符串 - 用
time.gmtime而非time.localtime做转换，避免受TZ环境变量干扰 - 字段名统一叫
timestamp，别用time或ts—— 太模糊，下游解析器常有预设映射
trace_id 断了、时间戳偏了、JSON 格式坏了，排查成本就翻倍。 
