面向容器日志的技术实践

背景

自 2013 年 dotCloud 公司开源 Docker 以来，以 Docker 为表明的容器产品凭借着隔离性好、可移植性高、资源占用少、启动迅速等特性迅速风靡世界。下图展现了 2013 年以来 Docker 和 OpenStack 的搜索趋势。

 

容器技术在部署、交付等环节给人们带来了不少便捷，但在日志处理领域却带来了许多新的挑战，包括：

1. 若是把日志保存在容器内部，它会随着容器的销毁而被删除。因为容器的生命周期相对虚拟机大大缩短，建立销毁属于常态，所以须要一种方式持久化的保存日志；
2. 进入容器时代后，须要管理的目标对象远多于虚拟机或物理机，登陆到目标容器排查问题会变得更加复杂且不经济；
3. 容器的出现让微服务更容易落地，它在给咱们的系统带来松耦合的同时引入了更多的组件。所以咱们须要一种技术，它既能帮助咱们全局性的了解系统运行状况，又能迅速定位问题现场、还原上下文。

日志处理流程

本文以 Docker 为例，依托阿里云日志服务团队在日志领域深耕多年积累下的丰富经验，介绍容器日志处理的通常方法和最佳实践，包括：

1. 容器日志实时采集；
2. 查询分析和可视化；
3. 日志上下文分析；
4. LiveTail - 云上 tail -f。

容器日志实时采集

容器日志分类

采集日志首先要弄清日志存在的位置，这里以 Nginx、Tomcat 这两个经常使用容器为例进行分析。

Nginx 产生的日志包括 access.log 和 error.log，根据 nginx Dockerfile 可知 access.log 和 error.log 被分别重定向到了 STDOUT 和 STDERR 上。

Tomcat 产生的日志比较多，包括 catalina.log、access.log、manager.log、host-manager.log 等，tomcat Dockerfile 并无将这些日志重定向到标准输出，它们存在于容器内部。

容器产生的日志大部分均可以归结于上述情形。这里，咱们不妨将容器日志分红如下两类。

容器日志分类	定义
标准输出	经过 STDOUT、STDERR 输出的信息，包括被重定向到标准输出的文本文件。
文本日志	存在于容器内部而且没有被重定向到标准输出的日志。

标准输出

使用 logging driver

容器的标准输出会由 logging driver 统一处理。以下图所示，不一样的 logging driver 会将标准输出写往不一样的目的地。

 

经过 logging driver 采集容器标准输出的优点在于使用简单，例如：

# 该命令表示在 docker daemon 级别为全部容器配置 syslog 日志驱动
dockerd -–log-driver syslog –-log-opt syslog-address=udp://1.2.3.4:1111 # 该命令表示为当前容器配置 syslog 日志驱动 docker run -–log-driver syslog –-log-opt syslog-address=udp://1.2.3.4:1111 alpine echo hello world

缺点

除了 json-file 和 journald，使用其余 logging driver 将使 docker logs API 不可用。

例如，当您使用 portainer 管理宿主机上的容器，而且使用了上述二者以外的 logging driver，您会发现没法经过 UI 界面观察到容器的标准输出。

使用 docker logs API

对于那些使用默认 logging driver 的容器，咱们能够经过向 docker daemon 发送 docker logs 命令来获取容器的标准输出。使用此方式采集日志的工具包括 logspout、sematext-agent-docker 等。下列样例中的命令表示获取容器自2018-01-01T15:00:00以来最新的5条日志。

docker logs --since "2018-01-01T15:00:00" --tail 5 <container-id>

缺点

当日志量较大时，这种方式会对 docker daemon 形成较大压力，致使 docker daemon 没法及时响应建立容器、销毁容器等命令。

采集 json-file 文件

默认 logging driver 会将日志以 json 的格式写入宿主机文件里，文件路径为/var/lib/docker/containers/<container-id>/<container-id>-json.log。这样能够经过直接采集宿主机文件来达到采集容器标准输出的目的。

该方案较为推荐，由于它既不会使 docker logs API 变得不可用，又不会影响 docker daemon，而且如今许多工具原生支持采集宿主机文件，如 filebeat、logtail 等。

文本日志

挂载宿主机目录

采集容器内文本日志最简单的方法是在启动容器时经过 bind mounts 或 volumes 方式将宿主机目录挂载到容器日志所在目录上，以下图所示。

 

针对 tomcat 容器的 access log，使用命令docker run -it -v /tmp/app/vol1:/usr/local/tomcat/logs tomcat将宿主机目录/tmp/app/vol1挂载到 access log 在容器中的目录/usr/local/tomcat/logs上，经过采集宿主机目录/tmp/app/vol1下日志达到采集 tomcat access log 的目的。

计算容器 rootfs 挂载点

使用挂载宿主机目录的方式采集日志对应用会有必定的侵入性，由于它要求容器启动的时候包含挂载命令。若是采集过程能对用户透明那就太棒了。事实上，能够经过计算容器 rootfs 挂载点来达到这种目的。

和容器 rootfs 挂载点密不可分的一个概念是 storage driver。实际使用过程当中，用户每每会根据 linux 版本、文件系统类型、容器读写状况等因素选择合适的 storage driver。不一样 storage driver 下，容器的 rootfs 挂载点遵循必定规律，所以咱们能够根据 storage driver 的类型推断出容器的 rootfs 挂载点，进而采集容器内部日志。下表展现了部分 storage dirver 的 rootfs 挂载点及其计算方法。

Storage driver	rootfs 挂载点	计算方法
aufs	/var/lib/docker/aufs/mnt/<id>	id 能够从以下文件读到。 /var/lib/docker/image/aufs/layerdb/mounts/\<container-id\>/mount-id
overlay	/var/lib/docker/overlay/<id>/merged	完整路径能够经过以下命令获得。 docker inspect -f '{{.GraphDriver.Data.MergedDir}}' <container-id>
overlay2	/var/lib/docker/overlay2/<id>/merged	完整路径能够经过以下命令获得。 docker inspect -f '{{.GraphDriver.Data.MergedDir}}' <container-id>
devicemapper	/var/lib/docker/devicemapper/mnt/<id>/rootfs	id 能够经过以下命令获得。 docker inspect -f '{{.GraphDriver.Data.DeviceName}}' <container-id>

Logtail 方案

在充分比较了容器日志的各类采集方法，综合整理了广大用户的反馈与诉求后，日志服务团队推出了容器日志一站式解决方案。

 

功能特色

logtail 方案包含以下功能：

1. 支持采集宿主机文件以及宿主机上容器的日志（包括标准输出和日志文件）；
2. 支持容器自动发现，即当您配置了采集目标后，每当有符合条件的容器被建立时，该容器上的目标日志将被自动采集；
3. 支持经过 docker label 以及环境变量过滤指定容器，支持白名单、黑名单机制；
4. 采集数据自动打标，即对收集上来的日志自动加上 container name、container IP、文件路径等用于标识数据源的信息；
5. 支持采集 K8s 容器日志。

核心优点

1. 经过 checkpoint 机制以及部署额外的监控进程保证 at-least-once 语义；
2. 历经屡次双11、双十二的考验以及阿里集团内部百万级别的部署规模，稳定和性能方面很是有保障。

K8s 容器日志采集

和 K8s 生态深度集成，能很是方便地采集 K8s 容器日志是日志服务 logtail 方案的又一大特点。

采集配置管理：

1. 支持经过 WEB 控制台进行采集配置管理；
2. 支持经过 CRD（CustomResourceDefinition）方式进行采集配置管理（该方式更容易与 K8s 的部署、发布流程进行集成）。

采集模式：

1. 支持经过 DaemonSet 模式采集 K8s 容器日志，即每一个节点上运行一个采集客户端 logtail，适用于功能单一型的集群；
2. 支持经过 Sidecar 模式采集 K8s 容器日志，即每一个 Pod 里以容器的形式运行一个采集客户端 logtail，适用于大型、混合型、PAAS 型集群。

关于 Logtail 方案的详细说明可参考文章全面提高，阿里云Docker/Kubernetes(K8S) 日志解决方案与选型对比。

查询分析和可视化

完成日志采集工做后，下一步须要对这些日志进行查询分析和可视化。这里以 Tomcat 访问日志为例，介绍日志服务提供的强大的查询、分析、可视化功能。

快速查询

容器日志被采集时会带上 container name、container IP、目标文件路径等信息，所以在查询的时候能够经过这些信息快速定位目标容器和文件。查询功能的详细介绍可参考文档查询语法。

实时分析

日志服务实时分析功能兼容 SQL 语法且提供了 200 多种聚合函数。若是您有使用 SQL 的经验，可以很容易写出知足业务需求的分析语句。例如：

1. 统计访问次数排名前 10 的 uri。

* | SELECT request_uri, COUNT(*) as c GROUP by request_uri ORDER by c DESC LIMIT 10

1. 统计当前15分钟的网络流量相对于前一个小时的变化状况。

* | SELECT diff[1] AS c1, diff[2] AS c2, round(diff[1] * 100.0 / diff[2] - 100.0, 2) AS c3 FROM (select compare( flow, 3600) AS diff from (select sum(body_bytes_sent) as flow from log))

该语句使用同比环比函数计算不一样时间段的网络流量。

可视化

为了让数据更加生动，您可使用日志服务内置的多种图表对 SQL 计算结果进行可视化展现，并将图表组合成一个仪表盘。

 

下图展现了基于 Tomcat 访问日志的仪表盘，它展现了错误请求率、网络流量、状态码随时间的变化趋势等信息。该仪表盘展示的是多个 Tomcat 容器数据聚合后的结果，您可使用仪表盘过滤器功能，经过指定容器名查看单个容器的数据。

 

日志上下文分析

查询分析、仪表盘等功能能帮助咱们把握全局信息、了解系统总体运行状况，但定位具体问题每每须要上下文信息的帮助。

上下文定义

上下文指的是围绕某个问题展开的线索，如日志中某个错误的先后信息。上下文包含两个要素：

• 最小区分粒度：区分上下文的最小空间划分，例如同一个线程、同一个文件等。这一点在定位问题阶段很是关键，由于它可以使得咱们在调查过程当中避免不少干扰。
• 保序：在最小区分粒度的前提下，信息的呈现必须是严格有序的，即便一秒内有几万次操做。

下表展现了不一样数据源的最小区分粒度。

分类	最小区分粒度
单机文件	IP + 文件
Docker 标准输出	Container + STDOUT/STDERR
Docker 文件	Container + 文件
K8s 容器标准输出	Namespace + Pod + Container + STDOUT/STDERR
K8s 容器文件	Namespace + Pod + Container + 文件
SDK	线程
Log Appender	线程

上下文查询面临的挑战

在日志集中式存储的背景下，采集端和服务端都很难保证日志原始的顺序：

1. 在客户端层面，一台宿主机上运行着多个容器，每一个容器会有多个目标文件须要采集。日志采集软件须要利用机器的多个 cpu 核心解析、预处理日志，并经过多线程并发或者单线程异步回调的方式处理网络发送的慢 IO 问题。这使得日志数据不能按照机器上的事件产生顺序依次到达服务端。
2. 在服务端层面，因为水平扩展的多机负载均衡架构，使得同一客户端机器的日志会分散在多台存储节点上。在分散存储的日志基础上再恢复最初的顺序是困难的。

原理

日志服务经过给每条日志附加一些额外的信息以及服务端的关键词查询能力巧妙地解决了上述难题。原理以下图所示。

 

1. 日志被采集时会自动加入用于标识日志来源的信息（即上文提到的最小区分粒度）做为 source_id。针对容器场景，这些信息包括容器名、文件路径等；
2. 日志服务的各类采集客户端通常会选择批量上传日志，若干条日志组成一个数据包。客户端会向这些数据包里写入一个单调递增的 package_id，而且包内每条日志都拥有包内位移 offset；
3. 服务端会将 source_id、package_id、offset 组合起来做为一个字段并为其创建索引。这样，即便各类日志在服务端是混合存储的状态，咱们也能够根据 source_id、package_id、offset 精肯定位某条日志。

想了解更多有关上下文分析的功能可参考文章上下文查询、分布式系统日志上下文查询功能。

LiveTail - 云上 tail -f

除了查看日志的上下文信息，有时咱们也但愿可以持续观察容器的输出。

传统方式

下表展现了传统模式下实时监控容器日志的方法。

类别	步骤
标准输出	1. 定位容器，获取容器 id； 2. 使用命令docker logs –f <container id>或kubectl logs –f <pod name>在终端上观察输出； 3. 使用grep或grep –v过滤关键信息。
文本日志	1. 定位容器，获取容器 id； 2. 使用命令docker exec或kubectl exec进入容器； 3. 找到目标文件，使用命令tail –f观察输出； 4. 使用grep或grep –v过滤关键信息。

痛点

经过传统方法监控容器日志存在如下痛点：

1. 容器不少时，定位目标容器耗时耗力；
2. 不一样类型的容器日志须要使用不一样的观察方法，增长使用成本；
3. 关键信息查询展现不够简单直观。

功能和原理

针对这些问题，日志服务推出了 LiveTail 功能。相比传统模式，它有以下优势：

1. 能够根据单条日志或日志服务的查询分析功能快速定位目标容器；
2. 使用统一的方式观察不一样类型的容器日志，无需进入目标容器；
3. 支持经过关键词进行过滤；
4. 支持设置关键列。

 

在实现上，LiveTail 主要用到了上一章中提到的上下文查询原理快速定位目标容器和目标文件。而后，客户端按期向服务端发送请求，拉取最新数据。

视频样例

您还能够经过观看视频，进一步理解容器日志的采集、查询、分析和可视化等功能。

原文连接本文为云栖社区原创内容，未经容许不得转载。