4.4 日志查看与资源监控
4.4 日志查看与资源监控
本节摘要：值班员的眼睛——logs 看作业记录、stats 看实时体征、top 看进程明细。本节不止教"怎么看"，更教"怎么判"：几种典型日志模式与资源曲线分别指向什么问题。
一只"活着但没干活"的箱子
值班夜里最常见的一类告警：容器状态 Up，业务接口却超时。状态 Healthy、进程在岗，问题出在哪？答案几乎总在日志与体征里——这就是本节要建立的三个观察位。先起一只演示箱子，把观察工具全部过一遍。
图 4-2：值班员的三个观察位
logs：作业记录的正确读法
日志命令本身一行就能学会，功夫全在选项与判读：
# 起一只演示箱子并制造访问 docker run -d --name lab-mon -p 8080:80 nginx:1.25-alpine curl -s -o /dev/null http://localhost:8080 # 基础读法：全部历史日志 docker logs lab-mon # 跟踪模式：持续输出新日志（等同 tail -f，Ctrl-C 退出） docker logs -f lab-mon # 常用过滤组合：最近三十秒、只看时间戳、最后二十行 docker logs --since 30s lab-mon docker logs -t --tail 20 lab-mon # 2026-08-30T10:12:01.284100000Z 172.17.0.1 - - "GET / HTTP/1.1" 200
两个原理性的点必须讲透。其一，logs 读的是主进程的标准输出与标准错误——应用要"把日志打到前台"容器才能收走；写进容器内文件系统的日志，logs 是看不到的（这既解释了"应用日志规范"为什么重要，也是第 5 章把日志目录外挂卷的理由）。其二，日志有堆积风险：跟踪模式跑在高流量容器上会刷爆终端，容器内日志文件无限膨胀会吃光磁盘——4.1 节 run 时的 --log-opt max-size 就是为这一刻准备的。
判读上，记三种典型模式：报错堆栈重复出现通常是配置错或依赖不可达；连接被拒（connection refused）通常是目标服务没起或端口配错；同样请求反复重试（retry storm）通常是对端变慢引发的雪崩前兆，先限流再排查。
stats：实时体征
# 全体运行容器的实时体征（每秒刷新，Ctrl-C 退出） docker stats # NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O # lab-mon 0.09% 6.2MiB / 3.7GiB 0.17% 1.2kB / 8.4kB 3.1MB / 0B # 只看指定容器，输出一次即退（脚本友好） docker stats --no-stream lab-mon
读表的关注点按优先级排：MEM USAGE 逼近 LIMIT 是第一警报——4.5 节配了额的容器一旦超限会被内核直接终结（退出码 137），所以内存曲线是预测性排障的核心指标；CPU 长期低位但应用无响应提示问题多半不在算力而在依赖（外部服务、数据库、锁）；NET I/O 为零但业务应活跃提示网络配置或泊位映射断了。
top：进程名册
# 箱内进程明细（宿主机视角的 ps） docker top lab-mon # UID PID PPID CMD # root 1201 1175 nginx: master process nginx -g daemon off; # 101 1244 1201 nginx: worker process # 101 1245 1201 nginx: worker process
名册的判读口诀：主进程在第一位（PID 较小），它的生死就是容器的生死；worker 数量异常（过多或为零）是应用层问题的直接证据；出现不明来源的进程，安全问题，立即隔离排查。把"活着但没干活"的开场案子收个尾：stats 显示 CPU 近零、top 显示 worker 进程只剩一个且卡死、logs 尾部停在几小时前——三合一指向应用死锁而非资源不足，处置是保留现场（导出日志）后重启容器，再到应用侧修死锁。
第四观察位：events 的事件流
体征与名册之外还有一个容易被忽略的全局视角——事件流。它按时间顺序记录引擎世界里发生的每一件事：起吊、停船、OOM 终结、健康检查失败……排查"什么时候开始不对劲"时，事件流就是码头的监控录像：
# 查看最近十分钟引擎事件（另开终端持续跟踪可去掉 --since） docker events --since 10m --until 0s # 输出（节选）： # container die (exitCode=137, oomKilled=1, name=order-db) # container restart (name=order-db) # container health_status: unhealthy (name=order-api) # 一行事件胜过十行猜测：137 与 oomKilled 直接锁定内存方向
三个观察位加一条事件流，构成完整的值班视野：events 定时刻、stats 定资源、top 定进程、logs 定原因——下一节的资源配额，正是从"看得见"走向"管得住"的那一步。
小演练：三分钟巡检一只可疑箱子
把观察位串成一次标准巡检。假设 order-api 被反馈偶发超时，按固定顺序取证，动作可复述、结论可复核：
# 第一步：体征快照——内存与 CPU 一眼定基调 docker stats --no-stream order-api # NAME CPU % MEM USAGE / LIMIT MEM % # order-api 98.7% 412MiB / 512MiB 80.5% <- 内存逼近配额，CPU 打满 # 第二步：名册核对——看是谁在吃算力 docker top order-api # 第三步：时间线回放——数一数最近的错误密度 docker logs --since 10m -t order-api | grep -c ERROR # 47 <- 十分钟 47 条错误，问题正处活跃期
三步走完方向已经清晰：内存八成满加错误密集，优先查内存曲线与是否曾被内核击杀（inspect 档案里的 OOMKilled 字段），再决定限流、扩配额还是保留现场重启。巡检的价值不在某条命令，而在顺序固定——夜班交接时，接手的人能照着同样三步重放你的现场。
本节要点回顾
- logs 读的是主进程的标准输出与错误流；写进容器内文件的日志 logs 看不见。
- 跟踪用 -f，过滤用 --since 与 --tail；日志限额（--log-opt）防磁盘吃满。
- 三种典型日志模式：重复堆栈配配置错、连接被拒查目标服务、重试风暴先限流。
- stats 看体征：内存逼近上限是第一警报；CPU 低位但无响应，问题多半在依赖。
- top 看名册：主进程第一位，worker 异常与不明进程都是直接证据。
看得住，还要管得住。下一节给每只箱子核定载重——资源配额，从玩具到生产的门槛。