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}
|
