如何区分日志等级中debug与info的使用场景？

Question

在实际开发中，如何准确区分日志等级中 debug 与 info 的使用场景是一个常见难题。例如：系统正常运行时的请求处理流水记录，应归为 info 还是 debug？若将所有请求参数、内部状态输出都打成 info，会导致日志量激增，影响关键信息提取；若全部降级为 debug，又可能遗漏对业务流转的可观测性支持。许多团队因此陷入“info 泛滥”或“debug 不足”的困境。问题在于：缺乏明确标准判断哪些信息属于“常规运行提示”（info），哪些属于“诊断辅助细节”（debug）。如何结合业务特征和运维需求，制定可落地的分级策略？

Answer 1

如何准确区分日志等级中 debug 与 info 的使用场景

1. 日志等级的基本定义与常见误区

在大多数日志框架（如 Log4j、Logback、SLF4J）中，日志级别通常按严重性从低到高分为：TRACE、DEBUG、INFO、WARN、ERROR。其中，DEBUG 和 INFO 是最常被混淆的两个层级。

• INFO：用于记录系统正常运行中的关键节点事件，如服务启动、请求接入、任务完成等。
• DEBUG：用于输出诊断信息，帮助开发者理解程序执行路径和内部状态，通常仅在排查问题时开启。

常见误区包括：

1. 将所有接口调用参数打印为 INFO，导致日志爆炸。
2. 认为“只要不报错就是 INFO”，忽视了信息的价值密度。
3. 线上环境长期开启 DEBUG 级别，造成磁盘和性能压力。

2. 实际开发中的典型场景对比

场景	建议日志等级	说明
HTTP 请求进入网关	INFO	记录 method + URI + client IP
请求参数完整 dump	DEBUG	包含敏感或高频数据
数据库连接成功	INFO	系统初始化阶段重要提示
SQL 执行语句及参数	DEBUG	用于性能分析但非必要常态输出
缓存命中/未命中	DEBUG	辅助定位性能瓶颈
定时任务开始执行	INFO	业务关键流程起点
任务内部循环每条处理记录	DEBUG	避免海量日志刷屏
用户登录成功	INFO	安全审计关键点
权限校验拒绝详情	DEBUG 或 WARN	视安全策略而定
消息队列消费确认	DEBUG	常规操作无需暴露

3. 制定可落地的日志分级策略

要解决“info 泛滥”或“debug 不足”的困境，需结合以下三个维度建立标准：

// 示例：基于业务重要性的日志输出
if (isBusinessCritical(request)) {
    log.info("Payment request received: orderId={}, amount={}", orderId, amount);
} else {
    log.debug("Query request processed: userId={}, filters={}", userId, filters);
}

• 业务特征：核心交易类操作（支付、下单）应强化 INFO 输出；查询类、内部调度可降级为 DEBUG。
• 运维需求：监控系统依赖 INFO 日志做指标采集，因此必须保证其稳定性和结构化。
• 可观测性成本：DEBUG 日志可用于链路追踪（如配合 OpenTelemetry），但需控制采样率或按条件动态开启。

4. 基于上下文的日志分级模型

graph TD
    A[事件发生] --> B{是否影响业务主流程?}
    B -->|是| C[输出为 INFO]
    B -->|否| D{是否有助于问题定位?}
    D -->|是| E[输出为 DEBUG]
    D -->|否| F[无需记录]
    C --> G[确保结构化、可检索]
    E --> H[建议添加 traceId / spanId]

该模型强调以“对业务的影响程度”作为首要判断依据。例如，一个订单创建请求的到达属于主流程，应记为 INFO；而其内部调用库存服务的重试次数，则属于诊断细节，归为 DEBUG。

5. 落地实践建议与工具支持

为保障策略可持续执行，推荐采取以下措施：

• 制定团队《日志规范文档》，明确各模块的 INFO/DEBUG 边界。
• 使用 AOP 或拦截器统一处理入口请求的日志输出，避免散落在业务代码中。
• 集成 ELK 或 Loki 等日志系统，通过字段提取实现 INFO 自动告警、DEBUG 按需查询。
• 在灰度环境中临时提升日志级别，收集足够诊断信息后再回归常态。
• 利用 MDC（Mapped Diagnostic Context）注入 requestId、userId 等上下文，增强 DEBUG 日志的可追溯性。

<!-- Logback 配置示例：按环境控制级别 -->
<springProfile name="prod">
    <root level="INFO">
        <appender-ref ref="FILE"/>
    </root>
</springProfile>
<springProfile name="dev,gray">
    <root level="DEBUG">
        <appender-ref ref="FILE"/>
    </root>
</springProfile>