logging:
  config: classpath:logback-spring.xml
  level: #自定义第三方包名日志等级
    io.seata: ERROR
    org.apache.dubbo: ERROR
    # 🔴 启动成功日志的「防吞」开关（2026-08-11）。
    # 背景：下面 log.level.root 是 ERROR，没有单独条目的服务（gateway / lims）root 就是 ERROR，
    # 启动类那句 log.info("xx启动成功") 会被静默吞掉——排障时看不到服务到底起没起来。
    # 这里按**类**精确放行，而不是把整个服务开成 INFO：logback 中子 logger 级别覆盖 root，
    # 于是只有启动类这几行 INFO 能过，控制台仍保持干净（gateway 实测 11 行，含 Spring 自带的
    # Starting/Started 两行——它们用的正是主类 logger，附带启动耗时，是净收益）。
    # 新增服务时如果它在 log.level 里没有 INFO 条目，就往这里补一行。
    jnpf.JnpfGatewayApplication: INFO
    jnpf.JnpfLimsApplication: INFO
    # 解除注释后Druid连接池打印SQL语句
    druid.sql.Statement: debug
#    druid.sql.DataSource: debug
#    druid.sql.Connection: debug
#    druid.sql.ResultSet: debug
    org.redisson.cluster: ERROR
log:
  level:
    root: ERROR
    # 🔴 平台聚合服务（2026-08-11）。logback 的 root level 取 log.level.${spring.application.name}，
    # 缺条目就回落到上面的 root: ERROR——那样连「启动成功」都不打印，排障等于瞎跑。
    # 下面被注释的 9 个平台服务名（jnpf-system / jnpf-visualdev / jnpf-workflow …）
    # 在聚合后**全部失效**：它们的 spring.application.name 已统一为 jnpf-platform。
    jnpf-platform: INFO
    #自定义服务的日志等级, 名称是服务中的spring.application.name: 等级 TRACE,DEBUG,INFO,WARN,ERROR
    # jnpf-oauth: ERROR
    # jnpf-system: ERROR
    # jnpf-lims: ERROR
    # jnpf-datareport: ERROR
    # jnpf-visualdev: ERROR
    jnpf-workflow: INFO
    # jnpf-file: ERROR
    # jnpf-tenant: ERROR
    # jnpf-message: ERROR
    # jnpf-scheduletask: ERROR
    # jnpf-permission: ERROR
    # jnpf-visualdata: ERROR
    # jnpf-app: ERROR
    # jnpf-gateway: ERROR
    # jnpf-eln: ERROR
  # 日志根参数化（2026-08-11）：日志文件此前写在容器**可写层**且无挂载——容器一 recreate
  # 就全部清零（当天为改配置重建过 3 次，前两次日志全丢），且悄悄撑大 docker 数据盘
  # （cx-platform 空闲 9 分钟就写了 227KB ≈ 36MB/天/服务）。
  # 🔴 默认值必须保持相对路径 `log`：宿主栈（start-all.sh）就靠它把日志落在仓库工作目录下，
  # 改成绝对路径会让宿主栈往 / 底下写。容器栈通过 compose 的 JNPF_LOG_DIR=/data/jnpf-logs 覆盖。
  # 路径里的 ${spring.application.name} 让所有服务共用一个挂载点也不会互相覆盖——
  # 宿主侧自动长成 logs/jnpf-gateway/、logs/jnpf-platform/ …，compose 里只需一行 volumes。
  path: ${JNPF_LOG_DIR:log}/${spring.application.name}