核心是选对日志驱动+搭好后端接收服务，无需改应用代码：后端服务输出stdout/stderr即可被Docker接管；Nginx等需改输出至控制台或挂载采集；开发测试用json-file挂载，中小生产用fluentd转发，中大型用fluentd+ELK/Loki；Fluentd示例三步落地，注意关闭轮转、同网络、标签区分及资源配额。
直接用 Docker Compose 整合日志收集系统，核心是选对日志驱动 + 搭好后端接收服务。不需要改应用代码，只需配置就能把分散在各容器里的日志统一收进来、存起来、查得快。
明确日志来源和输出方式
先确认你的服务日志是往哪出的：
- .NET、Java、Node.js 等后端服务：默认打到 stdout/stderr，Docker 自动捕获，这是最省事的路径
- Nginx、MySQL、Redis 等基础组件：有些默认写文件（如
/var/log/nginx/access.log），这类必须改成输出到控制台，或挂载目录+额外采集器 - 前端构建产物（如 Vue 打包后静态资源）本身不产日志，但 Nginx 代理层的日志要收全
重点：只要服务把日志输出到标准输出，Docker 就能通过日志驱动统一接管——这是集中管理的前提。
选择适合规模的日志驱动方案
根据团队当前阶段选一种，别一上来就堆 ELK：
-
开发/测试环境：用
json-file驱动 + 宿主机目录挂载
配置简单，日志落本地，docker compose logs -f直接看，支持时间戳、过滤、颜色区分 -
中小生产环境（10 个以内服务）：用
fluentd或syslog驱动
日志发到 Fluentd 容器，再转存 Elasticsearch 或 Loki；Fluentd 配置灵活，支持多行日志、字段解析、标签路由 -
中大型生产环境：用
gelf或fluentd+ ELK/Loki 栈
Logstash 或 Fluentd 做前置处理，Elasticsearch 存储 + Kibana 查看，Loki + Grafana 更轻量、更适合 Kubernetes 场景
快速落地一个 Fluentd 集中收集示例
三步跑通最小可行链路：
-
启动 Fluentd 容器：
在docker-compose.yml中加一段：fluentd: image: fluent/fluentd:v1.16-1 volumes: - ./fluentd/conf:/fluentd/etc ports: - "24224:24224" - "24224:24224/udp" -
给业务服务配驱动：比如后端 API 服务加上：
api: build: ./api logging: driver: "fluentd" options: fluentd-address: "fluentd:24224" tag: "backend.api" -
配置 Fluentd 输出到 Elasticsearch：
在./fluentd/conf/fluent.conf里写：<match **> @type elasticsearch host elasticsearch port 9200 logstash_format true logstash_prefix docker-logs </match>
启动后，所有打上 backend.api 标签的日志就会自动进 ES，Kibana 里建索引模式就能查。
避免踩坑的关键细节
这些地方不注意，日志会丢、乱序、查不到：
- 容器内应用必须关闭日志文件轮转（比如 Nginx 的
access_log /dev/stdout），否则 Fluentd 只能收到 stdout，收不到文件日志 - Fluentd 容器和业务容器要在同一个 Docker 网络里，确保
fluentd:24224能通 - 多实例部署时，用
tag: "{{.Name}}.{{.ID}}"区分不同容器，避免日志混在一起 - ELK 中 Elasticsearch 内存至少 4GB，否则写入容易失败；Loki 对资源更友好，适合小团队起步
