日志级别 INFO 和 DEBUG 有什么区别？该怎么用？
DEBUG 是给开发者的细粒度调试信息，生产环境通常关闭；INFO 是有意义的业务事件记录，生产环境常态开启。本文讲清各级别语义和使用规范。
一句话：DEBUG 记录"程序内部怎么走的"（给开发者排障用，生产关闭），INFO 记录"业务上发生了什么"（有意义的运行事件，生产常态开启）。
各级别语义
| 级别 | 语义 | 典型内容 | 生产环境 |
|---|---|---|---|
| DEBUG | 最细粒度调试信息 | 变量值、函数进出、分支判断 | 通常关闭 |
| INFO | 有意义的运行事件 | 服务启动、任务完成、用户关键操作 | 开启 |
| WARN | 潜在问题，不影响运行 | 配置缺失用默认值、重试、资源接近上限 | 开启 |
| ERROR | 错误，功能受影响但程序活着 | 请求失败、异常被捕获 | 开启+告警 |
| FATAL/CRITICAL | 严重故障；Python logging 不自动退出，其他库需检查 Fatal API 行为 | 数据库连不上、启动失败 | 开启+告警 |
实际例子
logger.debug("查询参数: %s, 耗时: %sms", params, elapsed) # 排障细节
logger.info("用户 %s 下单成功，订单号 %s", user_id, order_id) # 业务事件
logger.debug("缓存未命中，回源查询") # 正常缓存未命中通常不是警告
logger.error(f"支付接口调用失败: {e}") # 功能错误
使用规范
- 生产环境通常从 INFO 起按业务配置：DEBUG 日志量巨大且暴露内部细节；
- 临时排查可动态开 DEBUG：很多框架支持运行时调整某个 logger 的级别；
- ERROR 配合告警：按影响、频率与业务阈值决定是否告警，不应让每条 ERROR 都直接呼叫值班人员。
级别规范还要在采集后保持一致。日志进入观测云时，先检查 DataKit 解析结果中的 status 与应用原始级别是否对应，再在日志查看器按服务筛选错误；把 DEBUG 错映射为 error 会直接污染后续错误统计。
常见问题（FAQ）
Q：DEBUG 日志不写，出问题时怎么办？
A：靠 INFO+ERROR 的上下文、APM 链路追踪定位；确实需要时临时打开 DEBUG 级别复现问题，查完关闭。
Q：TRACE 是什么级别？
A：比 DEBUG 更细（如循环中每次迭代），log4j2、Python logging（自定义）等有，一般用不到。
Q：级别设高了会丢日志吗？
A：会。logger 级别是 INFO 时，DEBUG 消息直接不输出。logger、handler 的级别和 filters 共同决定结果。占位符可以延迟格式化，但参数表达式仍会先求值。
