Quarkus 1.10.3.Final配置access-log后控制台及日志文件均无访问日志输出

前置说明 #

针对你使用的Quarkus 1.10.3.Final版本，quarkus-resteasy扩展的默认传递依赖已内置Undertow作为HTTP服务承载引擎，无需单独引入Undertow等额外应用服务器组件，配置无日志输出的问题可按以下维度逐一排查，不存在必须额外引入应用服务器依赖的场景。 #

1. 全局日志级别拦截导致的静默失效 #

你当前配置的全局根日志级别为quarkus.log.level=WARN，而Undertow输出访问日志对应的固定日志分类为io.undertow.request.access-log，其默认输出级别为INFO，会被全局WARN规则直接拦截，无论控制台还是文件通道都不会输出任何访问日志。
需要单独补充配置：

quarkus.log.category."io.undertow.request.access-log".level=INFO

2. 访问日志输出通道的配置遗漏 #

1.10.3版本的访问日志通道是独立控制的，和普通应用日志的控制台开关不联动：

• 仅设置quarkus.http.access-log.enabled=true 只会将访问日志写入指定的文件目录，不会自动输出到控制台
• 如果需要同时输出到控制台，需要额外开启独立控制台开关：quarkus.http.access-log.enable-console=true
• 检查指定日志目录的写入权限：你配置的日志目录为系统级路径/var/log/，若运行应用的系统账号无写入权限，访问日志会静默丢弃，不会在启动阶段抛出可感知的权限异常。

3. 自定义访问日志Pattern的兼容性问题 #

1.10.3版本的Undertow访问日志模块对自定义Pattern的解析校验非常严格，一旦出现格式错误、占位符不匹配的情况，日志模块会直接禁用访问日志输出，不会抛出可感知的报错。
排查建议：

• 暂时替换为官方提供的最简标准Pattern测试，先排除格式问题：%h %l %u %t "%r" %s %b %D
• 你当前Pattern中%m（请求方法）放置在%s（响应状态码）、%b（响应字节数）之后虽不影响解析，但如果后续引用的X-Request-Id、X-Organization-Id请求头缺失，部分场景下会触发解析异常，可先移除自定义请求头占位符做验证。

4. HTTP引擎启动状态校验 #

在应用启动日志中检索是否存在Undertow HTTP started on port [配置端口号]的输出，确认HTTP服务正常加载。若未检索到对应日志，说明当前应用未启动HTTP监听流程，访问日志自然不会生成。 #

内容的提问来源于stack exchange，提问作者naddame