编排日志聚合是什么
把一套编排里多个服务的容器输出合并展示，默认给每行加上服务名前缀并按颜色区分。排障时不必逐个容器去取日志，一次就能看到跨服务的时间线，定位「哪个环节开始报错」比单看某一个服务有效率得多。
基本信息
| 语法 | docker compose logs [选项] [服务名...] |
|---|---|
| 常用选项 | 跟随输出、限定末尾行数、显示时间戳、去掉服务名前缀 |
| 默认行为 | 输出全部服务的已有日志后退出 |
| 适用范围 | 仅限当前编排项目下的服务 |
| 前提 | 日志驱动可被读取，集中采集类驱动可能取不到内容 |
典型使用场景
- 联调排障：一次看到网关、应用、数据库三方的输出，判断错误从哪一层开始
- 启动问题定位：服务启动失败时看哪个服务先报错，而不是逐个猜
- 实时观察：跟随输出盯着一次请求的完整链路
- 回归验证：重启后取最近一段日志，确认没有隐藏报错
- 脚本消费：去掉前缀后按行解析，用于自动化检查
常用示例
常用示例
docker compose logs # 输出全部已有日志
docker compose logs --tail=100 # 最近一百行
docker compose logs -f web worker # 只看两个服务并持续跟踪
docker compose logs -t api | grep -i error | tail -50 # 带时间戳筛错误
docker compose logs --no-log-prefix api # 去掉服务名前缀便于脚本解析参数组合效果
| 参数 | 作用 | 使用提醒 |
|---|---|---|
| 限定服务名 | 只输出指定服务 | 多个服务名用空格分隔 |
| 跟随输出 | 持续打印新日志 | 终端会一直占用，必要时先看末尾再决定 |
| 末尾行数 | 限制首次输出量 | 高流量服务不加限制会刷屏 |
| 显示时间戳 | 每行前加时间 | 便于与监控图表对齐 |
| 去掉前缀 | 不带服务名前缀 | 脚本解析更方便，人工看时不易分辨来源 |
多服务排障的顺序
- 先看网关与代理的日志，确认请求是否到达以及返回状态
- 再看应用日志中的错误栈与依赖调用失败信息
- 接着看依赖服务是否同时出现报错，判断是局部还是全局问题
- 最后结合时间戳把几个服务的时间线拼起来，定位首个异常出现的位置
- 记录关键时间点，便于与监控、告警和变更记录对照
日志前缀用于区分来源，脚本消费时要显式去掉。人工排查时保留前缀更容易判断是哪一层先出问题。
看不到日志先确认日志驱动，集中采集类驱动下本地读不到内容；编排里的服务名写错时命令也会给出提示，别一直怀疑服务没输出。