本文首发自“Docker公司”公众号（ID：docker-cn）
编译丨小东
每周一、三、五 与您不见不散！

在传统上，设计和实现集中的日志记录总是成为马后炮。要等到各种问题出现，集中的日志记录成为优先事项，人们才会想到用这样的解决方案查询、查看和分析日志，以找到问题的根本原因。但是到了容器时代，在设计使用 Docker 企业版 (Docker EE) 的容器即服务 (CaaS) 平台时，优先解决集中式日志记录是至关重要的。随着在容器中部署的微服务数量不断增多，它们以日志（或事件）形式产生的数据量会发生指数增长。

您将学到的知识

此参考架构提供了关于 Docker 日志记录功能如何工作的概述，说明了 Docker 日志的两大类别，然后讨论了 Docker 日志记录最佳实践。

了解 Docker 日志记录

在研究设计要素之前，先了解 Docker 日志记录的基本知识很重要。

Docker 支持不同的日志记录驱动，用于存储和/或流式传输主容器进程 (pid 1) 的容器 stdout 和 stderr 日志。默认情况下，Docker 使用 json-file 日志记录驱动，但也可以配置它使用许多其他驱动，方法是在 /etc/docker/daemon.json 中设置 log-driver 的值，然后重启 Docker 守护进程以重新加载其配置。

日志记录驱动设置会应用于重新配置守护进程之后启动的所有容器（在重新配置日志记录驱动之后重启现有容器并不会导致容器使用更新过的配置）。要覆盖默认的容器日志记录驱动，应使用 --log-driver 和 --log-opt 选项运行容器。另一方面，可以使用 docker service update --log-driver--log-opt 对 swarm mode 服务进行运行中更新，使其改用不同的日志记录驱动。

那么 Docker 引擎日志呢？这些日志通常由默认的系统管理节点日志记录器处理。现代的大多数发行版（CentOS 7、RHEL 7、Ubuntu 16 等）都使用 systemd，后者使用 journald 记录日志，使用 journalctl 访问日志。要访问引擎日志，可使用 journalctl -u docker.service。

Docker 日志类别和源

说过 Docker 日志记录的基础知识之后，本节将说明它们的类别和源。

Docker 日志通常可分为两种类别：基础架构管理日志或应用日志。大多数日志根据需访问日志者的角色自然地归入这两种类别。

• 运维人员最关心平台的稳定性以及服务的可用性。
• 开发人员比较关心其应用代码以及服务的性能。

为了实现自助服务平台，运维人员和开发人员都应该有权访问他们为了履行职责而需要访问的日志。开发运维的实践表明，在服务可用性和性能方面，大家要共同承担总体责任。但是，不应该让每一个人都有权访问平台上的每个日志。例如，开发人员应该只需要访问关于其服务和集成点的日志。运维人员则更关心 Docker 守护进程日志、UCP 和 DTR 可用性，以及服务可用性。两者的访问范围有一些重叠，因为开发人员和运维人员都应该了解服务可用性。让每个角色都能访问需要的日志，可以在发生问题时简化故障排除，并缩短解决故障平均时间 (MTTR)。

基础架构管理日志

基础架构管理日志包括 Docker 引擎、运行 UCP 或 DTR 的容器以及任何已部署的容器化基础架构服务（例如容器化的监控代理程序）的日志。

Docker 引擎日志

前文已经提到，默认情况下由 OS 的系统管理节点记录 Docker 引擎日志。可以将这些日志发送到集中的日志记录服务器。

UCP 和 DTR 系统日志

UCP 和 DTR 是作为 Docker 容器部署的。它们的所有日志都记录在容器的 STDOUT/STDERR 中。Docker 引擎的默认日志记录驱动记录这些日志。

可以配置 UCP 使用远程系统日志记录。此操作可以在安装后从 UCP UI 对其所有容器执行。

注：建议在安装 UCP 和 DTR 之前配置 Docker 引擎默认日志记录驱动，使其日志由所选的日志驱动记录。这是因为容器的日志记录驱动一旦创建就无法更改。唯一的例外是 ucp-agent，它是 UCP 的一个组件，作为 Swarm 服务而部署。

基础架构服务

基础架构运维团队部署容器化的基础架构服务，用于各种基础架构操作，例如监控、审核、报告、配置部署等。这些服务也会产生需要记录的重要日志。通常，它们的日志仅限于其容器的 STDOUT/STDERR，因此也会由 Docker 引擎默认日志记录驱动记录下来。否则，就需要另外处理。

应用日志

应用产生的日志可能是定制应用日志和应用主进程的 STDOUT/STDERR 日志的组合。前文已经说过，所有容器的 STDOUT/STDERR 日志都由 Docker 引擎默认日志记录驱动记录。所以不需要执行任何定制配置就能记录它们。如果应用有定制的日志记录（例如在容器中将日志写入 /var/log/myapp.log），那么就必须将其考虑在内。

Docker 日志记录设计注意事项

了解 Docker 日志的类型很重要。同样重要的是，定义哪些实体最适合使用和拥有它们。

分类 Docker 日志

主要有两种类别：基础架构日志和应用日志。

定义组织所有权

根据组织的结构和政策，确定这些类别是否与现有团队有直接对应关系。如果没有，则必须定义负责这些日志类别的合适组织或团队：

如果组织是更大组织的一部分，那么这些类别可能过于宽泛。应将它们细分为更具体的负责团队：

有些组织并不区分基础架构运维和应用运维，因此他们可以将这两种类别合并，让一个运维团队来负责。

选择合适的模式来明确定义每种日志类型的相应所有权，从而缩短解决故障平均时间 (MTTR)。确定各种日志类型的组织所有权之后，就应该开始考察适合部署的日志记录解决方案。

选择日志记录基础架构

Docker 可以方便地与现有日志记录工具和解决方案集成。日志记录生态系统中的主要日志记录实用程序大多已经开发出 Docker 日志记录功能，或者提供了与 Docker 集成的相应文档。

选择的日志解决方案应该符合下列条件：

1. 允许实现上一节定义的组织所有权模式。例如，有些组织可以选择将所有日志发送到单一的日志记录基础架构，然后向职能团队提供合适的访问级别。
2. 组织对其极为熟悉！这是必要条件！
3. 具有 Docker 集成：预配置的仪表板、稳定的 Docker 插件、合适的文档，等等。

Docker 企业版日志

如果使用 Docker 企业版，为了历史记录和系统维护的目的而存储所有容器日志是个好主意。建议您以可加索引的方式收集部分容器的输出，主要是出于政策原因和快速了解集群事件的目的。在下面几节中，我们将详细说明一些 Docker EE 组件和某些可能对组织有用的日志。

UCP

注：

1. ucp-controller - 此容器记录所有登录尝试和集群的常规使用情况。就审核目的而言，这些信息中包含集群的日志使用方面的最重要日志。
2. ucp-kv - 此容器适合用于监控，以确保集群中未失去法定多数。如果失去法定多数，设置警报是个好做法。

DTR

一些可以设置正则表达式的重要日志：

1. dtr-registry- - 解析此容器将显示客户端 IP、用户和集群的一般使用情况。
2. dtr-nginx- - 此容器记录对于集群的所有推送、拉取和 API 调用。
3. dtr-rethinkdb- - 此容器中的日志包含关于 RethinkDB 的法定多数状态的信息。它适合用于监控，在发生任何失去法定多数的情况时可发出警报。

HTTP 网格路由

默认情况下，HTTP 网格路由不会将任何请求记录到 STDOUT。要记录来自 HRM 的日志，请运行下列命令：

docker service update --env-add DEBUG=1 ucp-hrm

然后，日志就会从 HTTP 网格路由输出。如果在引擎级别配置日志驱动，则日志输出遵循引擎级别的配置。