mirror of
https://github.com/yeasy/docker_practice.git
synced 2026-08-10 16:37:34 +00:00
yeasy
08e981018e
1. FROM「必须是第一条指令」（4.5、7.16、summary 三处）与本书 7.7.4「FROM 之前的 ARG」整节直接冲突。官方 Dockerfile 参考写的是 "A Dockerfile must begin with a FROM instruction. This may be after parser directives, comments, and globally scoped ARGs"，且 "ARG is the only instruction that may precede FROM"。三处 一并改成「第一条构建指令」并点明例外。 2. 12 章小结把 USER Namespace 列进「默认启用」的一档，并写「容器 root ≠ 宿主机 root」；而同章 12.2.2 明写 USER Namespace 默认**不**启用、需 userns-remap 显式 开启，18.1 更直说「在默认情况下，容器内的 root 用户（UID=0）就是宿主机上的 root 用户」。小结按正文口径改回——这条读反了会直接误判容器逃逸的风险面。 3. 11.5「目前支持三种日志驱动类型」是 Compose 早期文本的残留。官方支持 json-file、 local、syslog、journald、gelf、fluentd、awslogs、splunk、etwlogs、gcplogs、 none 共十余种，本书 19 章小结自己就列了六种。改为给出常见取值并链到官方清单。 4. 7.8 与 7.5 的示例注释建议 postgres:latest / redis:latest，而 4.1、7.10、 7.16、7 章小结、4.5 全都要求避免 latest（7.8 同一文件第 177 行也写「避免 latest」）。按全书口径改掉这两处。 另：ENV 的空格分隔旧写法（7.6 的「格式一」、附录四的 PG_MAJOR/PATH 示例）改为等号 形式并加注。BuildKit 的 LegacyKeyValueFormat 检查会报 "ENV key=value" should be used instead of legacy "ENV key value" format， 而本书 10.2 与 07 章 README 正是在推荐 docker buildx build --check。
54 lines
2.9 KiB
Go
54 lines
2.9 KiB
Go
## 本章小结
|
||
|
||
本章从三个维度介绍了容器可观测性：
|
||
|
||
* **指标监控**：以 Prometheus + Grafana 为主，完成指标采集、存储与可视化。
|
||
* **日志管理**：以 EFK/ELK 为例，完成容器日志的集中采集、检索与分析。
|
||
* **性能优化与故障诊断**：把观测到的数据落到资源限制、瓶颈定位与线上排错上。
|
||
|
||
生产环境中，建议将“可观测性”当成一个完整闭环：**采集 -> 存储 -> 展示 -> 告警 -> 排错 -> 容量治理**。
|
||
|
||
## 扩展阅读：Docker 日志驱动
|
||
|
||
Docker 提供了多种日志驱动 (Log Driver)，用于将容器标准输出的日志转发到不同后端。
|
||
|
||
常见的日志驱动包括：
|
||
|
||
* `json-file`：默认驱动，将日志以 JSON 格式写入本地文件。
|
||
* `syslog`：将日志转发到 syslog 服务器。
|
||
* `journald`：将日志写入 systemd journal。
|
||
* `fluentd`：将日志转发到 fluentd 收集器。
|
||
* `gelf`：支持 GELF 协议的日志后端 (如 Graylog)。
|
||
* `awslogs`：发送到 Amazon CloudWatch Logs。
|
||
|
||
生产建议：无论采用哪种驱动，都要明确日志的保留周期、容量上限与传输可靠性，避免“日志把磁盘写满”或“链路抖动导致丢日志”。
|
||
|
||
## 19.4 日志平台选型对比与注意事项
|
||
|
||
日志平台通常由“采集/处理/存储/查询展示”几部分组成。常见选型包括：
|
||
|
||
* **EFK/ELK**：Elasticsearch + Fluentd/Logstash + Kibana，适合全文检索与结构化查询。
|
||
* **Loki + Grafana**：更偏“日志像指标一样存储”的思路，部署与成本可能更友好，但查询能力与使用习惯不同。
|
||
|
||
选型时建议关注：
|
||
|
||
* **写入压力与背压**：当存储端变慢时，采集端是否会缓冲、落盘、重试，是否会影响业务。
|
||
* **容量治理**：是否具备按天/按大小滚动、保留策略、生命周期管理 (ILM) 等能力。
|
||
* **安全与合规**：鉴权、TLS、审计、敏感字段脱敏。
|
||
* **可运维性**：升级策略、备份恢复、告警指标是否齐全。
|
||
|
||
## 19.5 上线前检查清单
|
||
|
||
你可以用下面的清单快速检查“是否具备最小生产可用性”：
|
||
|
||
* Prometheus 数据目录已持久化，并设置了合理的保留周期。
|
||
* Prometheus Targets 全部为 `UP`，并且关键查询 (CPU/内存/容器指标) 有数据。
|
||
* Grafana 已导入面板并能定位到具体实例/容器；默认账号密码已修改。
|
||
* 至少有一条关键告警已打通 Alertmanager 的接收链路，并验证告警能被正确发送与抑制。
|
||
* Elasticsearch 数据目录已持久化，并有明确的日志保留周期与容量上限策略。
|
||
* Kibana 能查询到最新日志；当 UI 异常时能用 Elasticsearch API 验证入库。
|
||
* 可观测性组件未直接暴露到公网，访问已加鉴权或置于内网。
|
||
---
|
||
|
||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|