日志 on Liangweidong's blog

Loki + Promtail 日志架构：像查指标一样查日志

Wed, 15 May 2024 00:00:00 +0800

Prometheus 解决的是"指标"问题，但线上排障 80% 的时间还是靠"日志"。传统方案是 ELK（Elasticsearch + Logstash + Kibana），重、占资源、运维复杂。Grafana Labs 推出的 Loki + Promtail 组合走的是另一条路——“像查指标一样查日志”：不建索引、只做标签、查询时按需拉取，配合 Grafana 一站式展示。这篇文章把零散在多个笔记里的部署、配置、踩坑细节，整理成"从零拉起→接入业务容器→清理过期日志"的一条完整路径。

阅读对象：已经在用 Prometheus + Grafana 体系，希望把日志也接进来的开发者、运维同学
覆盖范围：Loki 主服务（v2.9.x 时代）、Promtail / docker log driver 两种采集方式、多行日志识别、retention 清理、Nginx 反向代理

一、为什么是 Loki

在引入 Loki 之前，日志方案无外乎这几类：

ELK（Elasticsearch + Logstash + Kibana）：经典但重，JVM + 倒排索引吃资源，小机器跑不动
EFK（Fluentd 替代 Logstash）：稍轻量但仍依赖 ES
自建文件存储 + 简单 grep：能用但没可视化、没聚合
云厂商日志服务：阿里云 SLS、AWS CloudWatch Logs 等，绑定厂商

Loki 的设计哲学是"和 Prometheus 同构"：

维度	Prometheus	Loki
数据类型	指标（时序数值）	日志（文本行）
索引方式	标签（label）	标签（label）
存储	TSDB 本地/远端	对象存储/文件系统
查询语言	PromQL	LogQL
展示	Grafana	Grafana
资源占用	中	低（不做倒排索引）

When to use：如果你已经用 Prometheus + Grafana 做监控，强烈推荐 Loki——同一个 Grafana 实例、同一套标签习惯、几乎零额外学习成本。如果你的日志需要"全文模糊匹配"（Loki 不擅长）或日均日志量 GB 级以上（建议直接上 ES + SLS），那 Loki 就不合适了。

二、架构总览

Loki 体系的角色分工极简：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


业务容器（被采集）
 │
 ├─→ 方式 A：Promtail 进程 → 读容器日志文件 → 推送
 └─→ 方式 B：docker log driver（loki plugin） → 直推
 │
 ▼
 Loki 主服务（存储 + 查询）
 │
 ▼
 Grafana（展示）

Loki：主服务，负责存储日志和处理查询
Promtail：代理，负责从各种来源（文件、syslog、journald）采集日志并推给 Loki
Grafana：UI 展示 + 数据源对接（和 Prometheus 同一个实例即可）

三、Loki 部署

3.1 直接 docker run（最小可用）

1

docker run -d --name=loki --restart=always -p 3100:3100 grafana/loki:2.9.5

默认数据存到容器内 /loki 目录，容器销毁即数据丢失，生产环境必须挂载出来。

3.2 docker-compose（推荐）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


version: "3"
services:
 loki:
 image: grafana/loki:2.9.5
 container_name: loki
 restart: always
 network_mode: host
 volumes:
 - /home/docker/loki/config:/etc/loki
 command: -config.file=/etc/loki/local-config.yaml

默认配置 /etc/loki/local-config.yaml（Loki 2.9.5 自带）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


auth_enabled: false

server:
 http_listen_port: 3100

common:
 path_prefix: /loki
 storage:
 filesystem:
 chunks_directory: /loki/chunks
 rules_directory: /loki/rules
 replication_factor: 1
 ring:
 kvstore:
 store: inmemory

schema_config:
 configs:
 - from: 2020-10-24
 store: boltdb-shipper
 object_store: filesystem
 schema: v11
 index:
 prefix: index_
 period: 24h

ruler:
 alertmanager_url: http://localhost:9093

schema 版本：v11 是 Loki 2.9 时代的默认 schema。如果以后升级 Loki 主版本，要查 CHANGELOG 看 schema 是否需要迁移。生产环境建议把 chunks 和 rules 目录挂到大磁盘上，不要放系统盘。

四、日志采集：两种方式

4.1 方式 A：Promtail（推荐，灵活）

Promtail 是 Loki 官方的采集器，配置和 Promtail/Loki 同源：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


# promtail 配置片段
server:
 http_listen_port: 9080

positions:
 filename: /tmp/positions.yaml

clients:
 - url: http://{{LOKI_HOST}}:3100/loki/api/v1/push

scrape_configs:
 - job_name: docker
 docker_sd_configs:
 - host: unix:///var/run/docker.sock
 refresh_interval: 5s
 relabel_configs:
 - source_labels: ['__meta_docker_container_name']
 target_label: 'container'
 - source_labels: ['__meta_docker_container_log_stream']
 target_label: 'stream'
 pipeline_stages:
 - docker: {}

多行日志识别：Java 应用的异常堆栈、Nginx 多行 access log 等，默认会被拆成多行记录。配置 loki-pipeline-stages 的 multiline 段：

1
2
3
4
5
6
7


options:
 loki-url: "http://{{LOKI_HOST}}:3100/loki/api/v1/push"
 max-size: "50m"
 max-file: "10"
 loki-pipeline-stages: |
 - multiline:
 firstline: '^\[\d{2}:\d{2}:\d{2} \w{4}\]'

上面这条规则表示：以 [HH:MM:SS DAY] 开头的行是新日志的起点，其余行归属同一日志。

4.2 方式 B：docker log driver（最简）

Loki 官方提供了 docker plugin，装上后业务容器启动时加 --log-driver=loki 即可：

1
2


# 安装插件
docker plugin install grafana/loki-docker-driver:latest --alias loki --grant-all-permissions

国内直接拉可能 403（gcr.io 同款问题），离线场景需要：

1
2
3
4
5
6


# 离线节点
docker plugin disable loki -f
docker plugin rm loki -f
tar -xzf plugins.tar.gz -C /var/lib/docker
service docker restart
docker plugin enable loki

业务容器接入（示例）：

1
2
3
4
5
6
7
8


docker run -it -d \
 --name my-app \
 --restart=always \
 --log-driver=loki \
 --log-opt loki-url="http://{{LOKI_HOST}}:3100/loki/api/v1/push" \
 --log-opt max-size=50m \
 --log-opt max-file=10 \
 my-app:v1

小坑：loki-pipeline-stages 这种含特殊字符的 option 在 daemon.json 里配置时，JSON 字符串需要转义 \n，写错直接被 docker daemon 拒绝。

4.3 全局模式（所有容器默认走 Loki）

修改 /etc/docker/daemon.json：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


{
 "log-driver": "loki",
 "log-opts": {
 "loki-url": "http://{{LOKI_HOST}}:3100/loki/api/v1/push",
 "max-size": "50m",
 "max-file": "10"
 },
 "registry-mirrors": [
 "https://docker.m.daocloud.io",
 "https://hub-mirror.c.163.com",
 "https://mirror.baidubce.com",
 "https://docker.nju.edu.cn"
 ]
}

重启 docker 后所有容器都会切换日志驱动，已经在跑的应用会因为日志驱动不匹配启动失败。生产环境切换前先停业务，或者用"按容器 logging 字段覆盖"的折中方案。

4.4 docker-compose 模板

最常用的"logging anchor"写法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


version: "3"
x-logging: &loki-logging
 driver: loki
 options:
 loki-url: "http://{{LOKI_HOST}}:3100/loki/api/v1/push"
 max-size: "50m"
 max-file: "10"
 loki-pipeline-stages: |
 - multiline:
 firstline: '^\[\d{2}:\d{2}:\d{2} \w{4}\]'

services:
 my-service:
 image: my-image:tag
 restart: always
 logging: *loki-logging
 # ...

五、Grafana 对接

Loki + Grafana 是天生一对：

Grafana → Configuration → Data Sources → Add data source → Loki
URL 填 http://{{LOKI_HOST}}:3100
保存

查询语法（LogQL）示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 查名为 my-app 容器的所有日志
{container="my-app"}

# 包含 "ERROR" 的日志
{container="my-app"} |= "ERROR"

# 不包含 "health-check"
{container="my-app"} != "health-check"

# 正则匹配
{container="my-app"} |~ "Exception.*at .*\\(.+\\.java"

# 过去 5 分钟
{container="my-app"}[5m]

六、Retention 清理（关键！）

Loki 默认永不过期，磁盘会被慢慢吃光。

旧方式（已废弃，2.4 之前）

1
2
3


table_manager:
 retention_deletes_enabled: true
 retention_period: 24h

新方式（2.4+）

1
2
3
4
5
6
7
8


compactor:
 retention_enabled: true
 compaction_interval: 10m  # Compactor 检查过期表的间隔
 retention_delete_delay: 5m  # 过期后多久真正删除
 retention_delete_worker_count: 150

limits_config:
 retention_period: 7d  # 保留 7 天

修改后重启 Loki 生效。

七、Nginx 反向代理

Loki 服务端（带 WebSocket 实时推送和 HTTP 查询）需要 Nginx 转发：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


server {
 listen 8080;
 server_name loki.example.com;

 add_header Access-Control-Allow-Origin *;
 add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS';
 add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';

 location / {
 proxy_pass http://{{LOKI_HOST}}:3100;
 proxy_http_version 1.1;
 proxy_set_header Host loki.example.com;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection "upgrade";
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_connect_timeout 60;
 proxy_read_timeout 600;
 proxy_send_timeout 600;
 }
}

必须带 Upgrade/Connection 头：Grafana 查询 Loki 的实时流接口要 WebSocket，没有 Upgrade 头会被 nginx 拒绝。

八、踩坑清单

磁盘吃光——Loki 默认永久保留日志，必须配置 compactor.retention_enabled
查询慢——Loki 不索引日志内容，模糊匹配走"全量扫描"。查询时尽量用 |=、!= 做精确过滤，避免 |~ 正则匹配超大日志流
多行日志被拆碎——Java 异常、Nginx 多行 log 必须配 multiline，否则一条错误变成几十条记录
gcr.io 拉镜像失败——grafana/loki-docker-driver 插件托管在 gcr.io，国内走离线打包或者换用 Promtail 方案
schema 升级——Loki 主版本升级时，schema 不兼容会启动失败。务必先查 CHANGELOG 看是否需要 loki-canary 验证、是否需要执行 loki 内置的 schema 迁移工具
时区问题——Loki 时间戳按 UTC 存储，Grafana 里看日志时间默认也是 UTC。要么在 Grafana 里设 Dashboard timezone 为 Asia/Shanghai，要么在查询时显式带时区

九、2024+ 视角补充

本文写于 2024-05，2024-2026 期间 Loki 关键演进：

Loki 3.x（2024-Q3 起）：全面 BoltDB-shipper 弃用，统一走 TSDB 存储（与 Prometheus 一样的 TSDB），启动速度 / 写入吞吐 / 内存占用全面优化
Loki 3.3+：单二进制模式（Loki / Querier / Ingester / Distributor 合并）——小规模部署 1 容器跑 1 个 Loki 即可，无需拆微服务
Alloy 替代 Promtail：Grafana 2024 推出 Grafana Alloy（基于 Grafana Agent 演进），统一 Telemetry 采集（Logs / Metrics / Traces / Profiles），Promtail 进入 maintenance 模式
Loki 3.4+：结构化元数据（Structured Metadata）——日志标签化效率比 2.9 时代提升 10x
Loki + Promtail 已成过去：2025+ 推荐 Loki + Alloy 组合
对象存储成熟：S3 兼容存储（GCS、MinIO、Azure Blob、华为 OBS）全支持——本地盘生产已不再推荐

实战建议（2025-2026 视角）：

Loki 3.3+ 单二进制 + MinIO / S3 存储后端 + Alloy 采集 是 2025+ 主流
大集群（> 50 节点）：Loki 微服务模式（querier / ingester / distributor 拆分）+ Kafka 缓冲——高吞吐稳定
向量检索：2025+ Loki 实验支持 向量相似度查询（与 Grafana 11 配合），但生产慎用——性能不如专用向量库
告警：Loki 3.x 内置 ruler（不再依赖 alertmanager）——一站式告警

十、参考资料

Loki 官方文档：https://grafana.com/docs/loki/latest/
Promtail 配置：https://grafana.com/docs/loki/latest/clients/promtail/
LogQL 查询语法：https://grafana.com/docs/loki/latest/logql/
离线插件打包：参考 docker plugin install 文档
Grafana Alloy 替代 Promtail：https://grafana.com/docs/alloy/

下一步

监控那层用 Prometheus？→ 看 Prometheus 监控告警体系一文
不想装一堆组件？→ HertzBeat 轻量监控告警把监控 + 告警 + 通知合三为一
Grafana 还想要"链路追踪"？→ 接入 Tempo，复用同一套 Grafana

Docker daemon.json 配置详解：镜像加速、存储驱动与日志轮转

Tue, 15 Mar 2016 00:00:00 +0800

/etc/docker/daemon.json 是 Docker daemon 的核心配置文件，所有"非启动命令行"参数都在这里——registry-mirrors、insecure-registries、cgroup driver、log driver、storage driver、live-restore、default-runtime 等等。

这一篇把 daemon.json 的常用字段、最佳配置、reload / restart 区别、多机同步一次性收齐。

阅读对象：需要标准化 Docker 部署的运维同学、想搞懂 daemon.json 各字段的开发者 覆盖范围：镜像加速 + cgroup driver + 日志轮转 + K8s 集成 + 多机同步

一、daemon.json 在哪

系统	路径
Linux	`/etc/docker/daemon.json`
Windows (Docker Desktop)	`%ProgramData%\docker\config\daemon.json`
macOS (Docker Desktop)	`~/Library/Group Containers/group.com.docker/settings.json`
通过 `--config-file` flag	任意路径

重要：daemon.json 是 Linux 专属的标准路径。Docker Desktop（Mac/Windows）走 GUI 设置面板，本质也是写上面那个文件。

二、完整配置示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


{
 "live-restore": true,
 "exec-opts": ["native.cgroupdriver=systemd"],
 "log-driver": "json-file",
 "log-opts": {
 "max-size": "50m",
 "max-file": "3"
 },
 "registry-mirrors": [
 "https://docker.m.daocloud.io",
 "https://hub-mirror.c.163.com",
 "https://mirror.baidubce.com",
 "https://docker.nju.edu.cn",
 "https://docker.mirrors.sjtug.sjtu.edu.cn",
 "https://dockerproxy.com"
 ],
 "insecure-registries": [
 "registry.internal.example.com:5000"
 ],
 "storage-driver": "overlay2",
 "data-root": "/var/lib/docker",
 "default-runtime": "runc",
 "features": {
 "buildkit": true
 }
}

三、字段逐个解读

3.1 `registry-mirrors`：镜像加速

国内服务器拉 Docker Hub 镜像慢到秒级超时，配镜像源是必做项。

1
2
3
4
5
6
7
8


"registry-mirrors": [
 "https://docker.m.daocloud.io",
 "https://hub-mirror.c.163.com",
 "https://mirror.baidubce.com",
 "https://docker.nju.edu.cn",
 "https://docker.mirrors.sjtug.sjtu.edu.cn",
 "https://dockerproxy.com"
]

机制：Docker daemon 拉镜像时先尝试 mirrors，失败才回源。多 mirror 是 fallback 链——不是并发。

验证：

1
2
3
4
5


$ docker info | grep -A 5 'Registry Mirrors'
Registry Mirrors:
 https://docker.m.daocloud.io/
 https://hub-mirror.c.163.com/
 ...

测速：

1
2
3
4
5


# 删本地缓存后用 time 计时
docker rmi node:latest
time docker pull node:latest
# 国内典型：~5-15s（用 mirror）
# 直连 Docker Hub：~1m+（甚至超时）

3.2 `insecure-registries`：私有仓库（HTTP）

公司内部 / 测试环境的私有 Registry 通常没有 HTTPS 证书。配置后 Docker 才允许 docker pull/push：

1
2
3
4


"insecure-registries": [
 "registry.internal.example.com:5000",
 "10.0.0.10:5000"
]

注意：HTTP 仓库在 daemon 层就被标记为"不加密"，生产环境强烈建议升级到 HTTPS——攻击者能篡改镜像内容，等于供应链投毒。

3.3 `exec-opts`：cgroup driver

1

"exec-opts": ["native.cgroupdriver=systemd"]

Why 必须 systemd：K8s 1.22+ 强制要求 kubelet 的 cgroup driver 和容器 runtime 一致。如果 dockerd 用 cgroupfs 而 kubelet 用 systemd，Pod 启动可能失败、CPU / 内存 limit 不生效。

验证：

1
2


docker info | grep -i cgroup
# 期望：Cgroup Driver: systemd

3.4 `log-driver` / `log-opts`：日志配置

1
2
3
4
5


"log-driver": "json-file",
"log-opts": {
 "max-size": "50m",
 "max-file": "3"
}

字段	默认	推荐	说明
`max-size`	无	`"50m"`	单个日志文件最大 50MB
`max-file`	1	`"3"`	最多保留 3 个文件（50MB × 3 = 150MB）
`labels`	-	`"production,app"`	只收集带这些 label 的容器日志
`env`	-	`"ENV=prod"`	只收集带这些环境变量的容器日志

生产环境：

max-size 必须配——不配的话容器日志会无限增长撑爆磁盘
max-file 建议 3-5 个——多了浪费 IO，少了不便排查
高吞吐服务（nginx、Kafka）考虑改 log-driver: syslog 或 fluentd 推 ELK

3.5 `storage-driver`：存储驱动

驱动	内核要求	适用
`overlay2`	Linux 4.0+	默认推荐（CentOS 7+、Ubuntu 16.04+、Debian 9+）
`devicemapper`	Linux 3.18+	老 CentOS 7 / RHEL 7
`btrfs`	Linux 3.16+	btrfs 文件系统
`zfs`	Linux 3.16+	ZFS 文件系统
`vfs`	任意	调试用，性能差

不要轻易改 storage-driver——已有镜像 / 容器迁移成本极高，且 Docker 不支持在 daemon.json 改 storage driver 时自动迁移已有数据。

3.6 `data-root`：数据根目录

1

"data-root": "/var/lib/docker"

为什么需要改：

/var 容量不够（最常见）
用 XFS / ext4 大盘替代
把数据放到独立 SSD

详见 Docker 数据目录搬家一文。

3.7 `live-restore`：daemon 升级不停容器

1

"live-restore": true

What：daemon 重启时（升级、crash 恢复）正在运行的容器不会停。默认是 false——daemon 一重启，所有容器被 SIGTERM。

验证：

1
2


$ docker info | grep -i live
Live Restore Enabled: true

注意事项：

仅在 dockerd 是 pid 1 时有效（systemd 管理的标准场景）

不支持 Windows 容器

不支持 --userland-proxy=false 的某些边界场景

Docker Swarm 模式下行为可能不一致

3.8 `features.buildkit`：启用 BuildKit

1
2
3


"features": {
 "buildkit": true
}

BuildKit 是新一代构建引擎，2020 年起逐步成为默认。优势：

并行构建层（用 RUN 多步骤时显著加速）
增量构建缓存（按文件变更检测）
改进的 Dockerfile 语法
--mount=type=cache / --mount=type=secret 高级特性

Docker 23.0+（2023-02） 起 BuildKit 默认开启，无需显式配置。

四、reload vs restart：什么时候用哪个

daemon.json 修改后，systemctl reload docker 还是 systemctl restart docker？

操作	行为	适用
`reload`	发 `SIGHUP` 给 dockerd，热加载配置	`log-opts` / `registry-mirrors` / `insecure-registries` / `live-restore`
`restart`	优雅停所有容器 → 重启 daemon	`data-root` / `storage-driver` / `exec-opts`（cgroup driver）

重要：

live-restore: true 时，reload 不会中断容器
live-restore: false 时，restart 会停所有运行中的容器
改 data-root 必须 restart——reload 不重读路径
改 exec-opts 涉及 cgroup driver，必须 restart——reload 不重读

1
2
3
4
5


# 标准生效流程
systemctl daemon-reload # 重新加载 systemd unit 文件
systemctl reload docker # 热加载 daemon.json
# 或
systemctl restart docker # 重启 daemon

五、多机同步：批量应用 daemon.json

在 K8s 集群里，所有节点的 daemon.json 应保持一致：

1
2
3
4
5
6
7
8
9


# 单文件分发
scp /etc/docker/daemon.json worker1:/etc/docker/

# 批量
for NODE in master2 master3 worker1 worker2; do
 echo $NODE
 scp /etc/docker/daemon.json $NODE:/etc/docker/
 ssh root@$NODE "systemctl daemon-reload && systemctl reload docker && systemctl restart docker"
done

生产警示：在 K8s 集群里改 daemon.json 之前，先 kubectl drain <node> --ignore-daemonsets，避免 Pod 被 dockerd 重启打断。

六、常见问题

6.1 `unable to configure the Docker daemon` 启动失败

daemon.json 语法错（多余逗号、引号不配对）。journalctl -u docker 找具体报错行。

1
2
3
4


# 验证 JSON 语法
python3 -m json.tool /etc/docker/daemon.json
# 或
jq . /etc/docker/daemon.json

6.2 镜像源不生效

1
2
3
4
5
6
7


# 1. 看 mirror 是否在 daemon 配置里
docker info | grep 'Registry Mirrors'

# 2. 没生效 = 没 reload
systemctl reload docker # 或 restart

# 3. 还是不行 = 源本身失效了，换一个

6.3 cgroup driver 冲突（K8s）

1

Failed to run kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver "cgroupfs" is different from docker cgroup driver "systemd"

解决：dockerd 和 kubelet 都用 systemd。dockerd 改 exec-opts: ["native.cgroupdriver=systemd"]，kubelet 改 --cgroup-driver=systemd，两边都改完再重启。

七、要点回顾

registry-mirrors 必配——国内服务器不配镜像源拉镜像会卡
log-opts: max-size + max-file 必配——不配日志能撑爆磁盘
K8s 集群里 cgroup driver 必须 systemd——exec-opts 加 native.cgroupdriver=systemd
live-restore: true 是 daemon 升级不停机的关键
reload vs restart 取决于改的字段——改 data-root / cgroup 必须 restart
改完 JSON 一定要 python3 -m json.tool 校验——JSON 错 daemon 起不来
多机同步用 scp + 批量 systemctl reload

八、小结

daemon.json 是 Docker 标准化的"地基"。一个规范的 daemon.json 应该满足：

镜像加速——registry-mirrors 国内必配
日志轮转——log-opts 限制大小和文件数
K8s 友好——cgroupdriver=systemd
生产稳定——live-restore: true
多机一致——所有节点同一份配置

下一步：daemon.json 是"daemon 自身"的配置。容器内部的"声明式配置"由 Dockerfile + Compose + K8s Manifest 接力——后者是"应用层"的标准化。

参考资料

Docker 日常运维速查：日志、磁盘、端口、容器自省

Mon, 15 Jun 2015 00:00:00 +0800

跑 Docker 容器不难，跑久了之后的"找日志、看磁盘、查端口、还原启动命令"才是真正花时间的地方。这一篇把日常 80% 的运维命令收成一份"速查表"，按主题组织。

阅读对象：日常需要管理 Docker 容器、想要一份"忘了就能查"的命令清单 覆盖范围：日志查询（时间窗口 + grep）、磁盘分析、容器 IP / 启动命令 / 进程 PID 反查、网络断开、批量清理

一、容器日志查询

1.1 基础查询

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 持续查看（类似 tail -f）
docker logs -f <container>

# 看最后 50 条
docker logs -f --tail=50 <container>

# 过滤关键词
docker logs -f --tail=50 <container> | grep "Oss"

# 上下文过滤：-C 前后多少行，-B 前多少行，-A 后多少行
docker logs -f --tail=50 <container> | grep "Oss" -C 10

1.2 时间窗口查询

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 查从 2016-07-01 起的最后 10 条
docker logs --since="2016-07-01" --tail=10 mynginx

# 查最近 30 分钟
docker logs --since 30m <container>

# 查指定时间区间（ISO 8601）
docker logs --since='2024-04-23T08:00:00Z' --until='2024-04-23T08:34:00Z' base

# 1 小时前 ~ 8.5 小时前
docker logs --since "$(date -d '1 hour ago' +'%Y-%m-%dT%H:%M:%SZ')" \
 --until "$(date -d '8 hour 30 minute ago' +'%Y-%m-%dT%H:%M:%SZ')" base

Why 用 ISO 8601：--since / --until 接受 Go duration（如 30m、2h）和 RFC 3339 时间戳。跨时区排查时必须用 RFC 3339 + Z 后缀，否则会以 daemon 本地时区解析。

1.3 日志文件位置

Docker 默认把日志写到本地 JSON 文件：

1

/var/lib/docker/containers/<容器id>/<容器id>-json.log

问题：JSON 日志没有自动轮转，长期运行的容器日志能把磁盘撑爆。两种解法：

配置全局日志轮转（推荐，daemon.json 级别）：

1
2
3
4
5
6
7


{
 "log-driver": "json-file",
 "log-opts": {
 "max-size": "50m",
 "max-file": "3"
 }
}

手动清空（应急用）：

1
2
3
4
5


# 容器运行时
truncate -s 0 /var/lib/docker/containers/<container-id>/<container-id>-json.log

# 或更直接
cat /dev/null > /var/lib/docker/containers/<container-id>/<container-id>-json.log

二、磁盘占用分析

1
2
3
4
5


# 一句话看整体
docker system df

# 详细看每个镜像 / 容器 / 卷
docker system df -v

典型输出：

1
2
3
4
5
6


REPOSITORY TAG IMAGE ID CREATED SIZE SHARED SIZE UNIQUE SIZE
go-scratch 1.0.0 45579d645abb 31 minutes ago 0B 0B 0B
easysoft/zentao 16.4 a07d6a23404c 2 weeks ago 699.7MB 0B 699.7MB
postgres 14.1-alpine 2302d5724f71 3 months ago 209MB 0B 209MB
sonarqube 9.2.1-community cb35e2de836c 3 months ago 549.1MB 0B 549.1MB
gitlab/gitlab-ee 13.12.9-ee.0 4ccbcfe81d60 7 months ago 2.435GB 0B 2.435GB

关键字段：

SHARED SIZE：被多个容器共享的只读层（多个镜像公用）
UNIQUE SIZE：当前镜像独占的可写层（这是清理时的真实可释放空间）
容器层"容器一停就消失"，但镜像层不会自动清——长期累积的 <none>:<none> 是元凶

三、容器网络：查所有 IP

1
2
3
4
5
6
7


# 所有运行中容器
docker inspect --format='{{.Name}} - {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' \
 $(docker ps -aq)

# docker-compose 启动的（多网络时 .IPAddress 拿到的是第一个）
docker inspect -f '{{.Name}} - {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' \
 $(docker ps -aq)

四、通过 PID 反查容器

1
2
3
4
5
6
7
8


# 知道宿主机上某个 PID 是哪个容器的
docker ps -q | xargs docker inspect --format '{{.State.Pid}}, {{.Name}}' | grep "<PID>"

# 反向：根据启动命令里的特征字符串找容器
pgrep -f "/app/start-scms.sh" | xargs -I {} sudo cat /proc/{}/cgroup

# 输出长这样（取 docker-xxx.scope 那行）：
# 0::/system.slice/docker-a89a19896cf24e4a60745870ac9fc7a1691c3fa6ff539d6acfc5094154bb44db.scope

典型场景：服务 A 调用服务 B 出问题，但服务 B 在 K8s 集群里名字很难找——从宿主机 cgroup 文件反查最快。

五、还原容器的启动命令

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 标准工具：cucker/get_command_4_run_container
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
 cucker/get_command_4_run_container:1.3 <container-name>

# 输出示例：
# docker run -d \
# --name mysql01 \
# --env MYSQL_ROOT_PASSWORD=py123456 \
# -p 13306:3306/tcp \
# --restart=always \
# mysql

Why 这个工具：容器跑久了之后，谁、用什么参数起的经常说不清。docker inspect 能看到参数但格式反人类；这个工具一键还原成 docker run 命令。

类似的工具还有 assaflavie/runlike 和 joinsunsoft/runcommand，用法类似。

六、批量操作 Exited 容器

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 启动所有 Exited 的容器
docker ps -a | grep Exited | awk '{print $1}' | xargs docker start

# 删所有 Exited 的
docker ps -a | grep Exited | awk '{print $1}' | xargs docker rm

# 按 status 过滤
docker ps -f "status=exited"
docker rm -f $(docker ps -f "status=exited" -q)

# 强制删除 + 清理网络占用
docker rm -f <container-id>
docker network disconnect --force bridge <container-id>

七、查端口占用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 看所有 docker-proxy 监听的端口
netstat -nlp | grep docker-proxy | awk '{print $4}' | sort

# host 模式下，docker-proxy 不会监听，得用 pid 找
docker top <container>
netstat -anp | grep <pid>
lsof -i | grep <pid>

# 一行命令找容器进程的端口
for i in $(docker top <container> | awk '{print $2}'); do
 netstat -tunlp | grep $i
done

八、清理无用的卷 / 镜像

1
2
3
4
5
6
7
8
9


# 删 dangling 镜像（仓库名 / tag 为 <none>）
docker rmi $(docker images -f "dangling=true" -q)

# 删所有未挂载的卷（**危险**，生产前必须确认）
docker volume prune
docker volume ls -f "dangling=true" -q | xargs --no-run-if-empty docker volume rm

# 一键清空（**非常危险**，会把所有停止的容器、镜像、网络、未用卷全删）
docker system prune -af --volumes

生产警示：docker system prune -af --volumes 是"一键核弹"——会删所有 dangling 镜像、所有停止的容器、所有未挂载卷、所有未用网络。CI 节点上偶尔用一下尚可，生产数据库节点永远不要跑。

九、查看磁盘与目录映射

1
2
3
4
5
6
7


# 容器对应的 overlay2 目录
docker inspect <container> -f {{.GraphDriver.Data.MergedDir}}
# 输出：/var/lib/docker/overlay2/<id>/merged

# 容器元数据目录
ls /var/lib/docker/containers/<container-id>
# 里面有 config.v2.json / hostconfig.json / *-json.log

十、根据状态查询

1
2
3
4
5


# 只看退出的
docker ps -f "status=exited"

# 只看健康的（需要 healthcheck）
docker ps -f "health=healthy"

十一、一键全清（应急用）

1
2
3
4
5
6
7


# 删所有容器（不管状态）
docker rm -f $(docker ps -a -q)

# 清镜像 / 网络 / 卷
docker system prune -af --volumes

# 注意：上面会**删 dangling 镜像 + 所有停止的容器 + 所有未用卷**

十二、要点回顾

日志查询用 --since / --until + ISO 8601 时间戳最稳
磁盘分析用 docker system df -v 看 UNIQUE SIZE，那是真实可释放空间
容器 IP用 inspect + range .NetworkSettings.Networks，比单字段 IPAddress 兼容多网络
还原启动命令用 cucker/get_command_4_run_container 或 runlike
批量清理 Exited用 docker ps -a | grep Exited | awk | xargs
docker system prune -af --volumes 是核弹——生产环境谨慎

十三、小结

日常运维最花时间的不是"启动容器"，而是"出问题后查根因"。这份命令清单的核心理念是：

查日志 → ISO 8601 + grep 上下文
查磁盘 → system df -v 看 UNIQUE SIZE
查 IP / 命令 / 进程 → inspect + Go template + cgroup
批量操作 → awk + xargs 串起来
清理 → dangling=true 比 prune -af 安全

把这些命令攒成 shell 函数或 alias，比每次翻笔记快：

1
2
3
4
5
6


# ~/.bashrc
alias dl='docker logs -f --tail=100'
alias dlf='docker logs -f --tail=100 | grep'
alias ddf='docker system df -v'
alias drmexit='docker rm -f $(docker ps -f "status=exited" -q)'
alias drmi='docker rmi $(docker images -f "dangling=true" -q)'

下一步：日志和磁盘都是"被动响应"问题。下一步是"主动预防"——daemon.json 里配好 log-opts 限制日志大小、给所有容器加 healthcheck、用 restart: always 守好关键服务，把运维压力从"救火"变成"看仪表盘"。

日志 on Liangweidong's blog

Loki + Promtail 日志架构：像查指标一样查日志

一、为什么是 Loki

二、架构总览

三、Loki 部署

3.1 直接 docker run（最小可用）

3.2 docker-compose（推荐）

四、日志采集：两种方式

4.1 方式 A：Promtail（推荐，灵活）

4.2 方式 B：docker log driver（最简）

4.3 全局模式（所有容器默认走 Loki）

4.4 docker-compose 模板

五、Grafana 对接

六、Retention 清理（关键！）

旧方式（已废弃，2.4 之前）

新方式（2.4+）

七、Nginx 反向代理

八、踩坑清单

九、2024+ 视角补充

十、参考资料

下一步

Docker daemon.json 配置详解：镜像加速、存储驱动与日志轮转

一、daemon.json 在哪

二、完整配置示例

三、字段逐个解读

3.1 registry-mirrors：镜像加速

3.2 insecure-registries：私有仓库（HTTP）

3.3 exec-opts：cgroup driver

3.4 log-driver / log-opts：日志配置

3.5 storage-driver：存储驱动

3.6 data-root：数据根目录

3.7 live-restore：daemon 升级不停容器

3.8 features.buildkit：启用 BuildKit

四、reload vs restart：什么时候用哪个

五、多机同步：批量应用 daemon.json

六、常见问题

6.1 unable to configure the Docker daemon 启动失败

6.2 镜像源不生效

6.3 cgroup driver 冲突（K8s）

七、要点回顾

八、小结

参考资料

Docker 日常运维速查：日志、磁盘、端口、容器自省

一、容器日志查询

1.1 基础查询

1.2 时间窗口查询

1.3 日志文件位置

二、磁盘占用分析

三、容器网络：查所有 IP

四、通过 PID 反查容器

五、还原容器的启动命令

六、批量操作 Exited 容器

七、查端口占用

八、清理无用的卷 / 镜像

九、查看磁盘与目录映射

十、根据状态查询

十一、一键全清（应急用）

十二、要点回顾

十三、小结

参考资料

3.1 `registry-mirrors`：镜像加速

3.2 `insecure-registries`：私有仓库（HTTP）

3.3 `exec-opts`：cgroup driver

3.4 `log-driver` / `log-opts`：日志配置

3.5 `storage-driver`：存储驱动

3.6 `data-root`：数据根目录

3.7 `live-restore`：daemon 升级不停容器

3.8 `features.buildkit`：启用 BuildKit

6.1 `unable to configure the Docker daemon` 启动失败