docker日志应直出stdout/stderr，再通过日志驱动（如fluentd、syslog、local）对接宿主机可观测体系；禁用文件写入，避免fifo等不可靠重定向，推荐挂载目录双写或sidecar代理实现合规落盘。
直接在 Dockerfile 中用 CMD 或 ENTRYPOINT 把日志重定向到宿主机“管道”（如命名管道 /dev/stdout 以外的 FIFO）是不可行且不推荐的。Docker 容器生命周期与宿主机管道的创建、权限、生命周期不匹配，容易导致启动失败或日志丢失。真正的高级技巧不是“重定向到管道”，而是**让日志自然流向 stdout/stderr，并通过容器运行时机制无缝对接宿主机可观测体系**。
确保应用日志直出 stdout/stderr（根本前提）
这是所有后续方案生效的基础。若应用自行写文件（如 Python 用 FileHandler、Java 写 app.log），Docker 就捕获不到原生日志。
- Python：禁用
logging.FileHandler，改用StreamHandler(sys.stdout)；避免print(..., file=open(...)) - Java（Spring Boot）：确认
logback-spring.xml中<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"></appender>是主输出，且无FileAppender覆盖 - Node.js：统一用
console.log()/console.error()，不fs.appendFile()写日志文件
利用 Docker 日志驱动对接宿主机“逻辑管道”
Docker 的 --log-driver 实质上就是把容器 stdout/stderr 当作数据流，注入到宿主机的各类后端——这比手动建 FIFO 更可靠、更标准化。
-
对接系统日志服务：用
syslog驱动，日志自动进入journald或rsyslog，宿主机上可执行journalctl -u docker -n 100实时查看 -
对接 Fluentd/Vector 等代理：启动容器时指定
--log-driver=fluentd --log-opt fluentd-address=host.docker.internal:24224，日志即被推送到宿主机运行的 Fluentd 实例，再由其分发至文件、ES 或 S3 -
本地结构化落盘（生产可用）：使用
local驱动（比json-file更高效），并配置轮转：docker run --log-driver=local --log-opt max-size=20m --log-opt max-file=5 myapp
需文件落盘时的合规双写方案
当审计要求日志必须同时存在容器 stdout 和宿主机文件时，避免在 CMD 中用 sh -c "app | tee ..."（易阻塞、无轮转）。推荐：
-
挂载宿主机目录 + 应用自身支持多输出：在 Dockerfile 中声明
VOLUME ["/var/log/myapp"]，运行时用-v /host/logs:/var/log/myapp；再通过应用配置（如 Logback 的RollingFileAppender + ConsoleAppender并存）实现双写 -
轻量级 sidecar 日志代理：容器内启动两个进程（用
s6-overlay或supervisord管理）：主应用输出到 stdout，另起一个tail -F /var/log/myapp/app.log进程，将其输出再转发到 stdout —— 这样docker logs仍可见，且文件也落盘
绕过 Docker 日志系统（慎用）
仅适用于特殊场景（如调试、静默任务），不建议用于生产日志管理：
-
--log-driver=none：完全禁用 Docker 日志收集，适合无需日志的批处理任务 -
docker run ... > /host/output.log 2>&1：在宿主机 shell 层重定向容器整个输出流，但会丢失每条日志的时间戳和流标识（stdout/stderr 混合） - 挂载
/dev/shm或tmpfs作为临时缓冲区，再由宿主机脚本定期消费 —— 复杂度高，无标准工具链支持
