通过关键词采集文章采集api(容器日志实时采集日志分类定义标准输出标准和实践(组图) )

　　通过关键词采集文章采集api(容器日志实时采集日志分类定义标准输出标准和实践(组图)

)

　　背景

　　自2013年dotCloud开源Docker以来，以Docker为代表的容器产品以隔离性好、可移植性高、资源占用少、启动快等特点迅速风靡全球。下图显示了 2013 年以来 Docker 和 OpenStack 的搜索趋势。

　　

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

　　如果日志保存在容器内，在容器销毁时会被删除。由于容器的生命周期与虚拟机相比大大缩短，因此创建和销毁是常态。因此，需要一种持久保存日志的方法。进入容器时代后，需要管理的目标对象远多于虚拟机或物理机。登录到目标容器。故障排除将变得更加复杂和不经济；容器的出现使得微服务的实现变得更加容易，微服务引入了更多的组件，同时给我们的系统带来了松耦合。因此，我们需要一种既能帮助我们全局了解系统运行情况，又能快速定位问题现场、还原上下文的技术。日志处理流程

　　本文以Docker为例，介绍容器日志处理的一般方法和最佳实践，包括：

　　容器日志实时采集; 查询分析和可视化；日志上下文分析；LiveTail - 云尾 -f。容器日志实时采集 容器日志分类

　　采集Logs 首先，我们需要找出日志存在的位置。这里以两个常见的容器 Nginx 和 Tomcat 为例进行分析。

　　Nginx 生成的日志包括 access.log 和 error.log。众所周知，access.log 和 error.log 分别被重定向到 STDOUT 和 STDERR。

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

　　容器产生的大部分日志都可以归结为上述情况。在这里，我们不妨将容器日志分为以下两类。

　　容器日志分类定义

　　标准输出

　　通过 STDOUT、STDERR 输出的信息，包括重定向到标准输出的文本文件。

　　文本日志

　　存在于容器内且未重定向到标准输出的日志。

　　使用日志记录驱动程序的标准输出

　　容器的标准输出会被日志驱动统一处理。如下图所示，不同的日志驱动程序会将标准输出写入不同的目的地。

　　

　　通过日志记录驱动程序 采集 的容器标准输出的优点是使用简单，例如：

　　# 该命令表示在 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 以外的其他日志记录驱动程序将使 docker logs API 不可用。比如当你在宿主机上使用portainer管理容器，并且使用上述两种以外的日志驱动时，你会发现无法通过UI界面观察到容器的标准输出。

　　使用 docker 日志 API

　　对于那些使用默认日志驱动的容器，我们可以通过向 docker daemon 发送 docker logs 命令来获取容器的标准输出。使用这种方法采集log的工具有logspout、sematext-agent-docker等。下面例子中的命令意思是获取容器自2018-01-01T15:00:00以来的最新5条日志。

　　docker logs --since "2018-01-01T15:00:00" --tail 5

　　缺点

　　当日志量较大时，这种方式会给 docker daemon 带来很大的压力，导致 docker daemon 无法及时响应创建容器、销毁容器等命令。

　　采集 json 文件文件

　　默认的日志驱动程序会将日志以json格式写入主机文件，文件路径为/var/lib/docker/containers//-json.log。这样，采集容器标准输出的目的就可以通过直接采集host文件来实现。

　　推荐这种方案，因为它既不会使 docker logs API 不可用，也不会影响 docker daemon，而且现在很多工具都原生支持 采集host 文件，例如 filebeat、logtail 等。

　　文本日志挂载主机目录

　　采集容器中的文本日志最简单的方法是在启动容器时通过bind mounts或者volumes将宿主目录挂载到容器日志所在的目录，如下图所示。

　　

　　对于tomcat容器的访问日志，使用命令docker run -it -v /tmp/app/vol1:/usr/local/tomcat/logs tomcat挂载主机目录/tmp/app/vol1到访问日志中容器在目录/usr/local/tomcat/logs上，通过采集主机目录/tmp/app/vol1下的日志实现采集tomcat访问日志的目的。

　　计算容器rootfs挂载点

　　使用挂载宿主目录采集log的方法会侵入应用程序，因为它需要容器在启动时收录mount命令。如果 采集 进程对用户是透明的，那就太好了。实际上，这可以通过计算容器 rootfs 挂载点来实现。

　　与容器 rootfs 挂载点密不可分的一个概念是存储驱动程序。在实际使用中，用户往往会根据Linux版本、文件系统类型、容器读写条件等因素来选择合适的存储驱动。在不同的存储驱动下，容器的rootfs挂载点遵循一定的规则，所以我们可以根据存储驱动的类型推断出容器的rootfs挂载点，然后采集容器的内部日志。下表显示了某些存储驱动程序的 rootfs 挂载点以及如何计算它们。

　　存储驱动rootfs挂载点计算方法

　　奥夫斯

　　/var/lib/docker/aufs/mnt/

　　id 可以从以下文件中读取。

　　/var/lib/docker/image/aufs/layerdb/mounts//mount-id

　　覆盖

　　/var/lib/docker/overlay//合并

　　可以使用以下命令获取完整路径。

　　docker inspect -f '{{.GraphDriver.Data.MergedDir}}'

　　覆盖2

　　/var/lib/docker/overlay2//合并

　　可以使用以下命令获取完整路径。

　　docker inspect -f '{{.GraphDriver.Data.MergedDir}}'

　　设备映射器

　　/var/lib/docker/devicemapper/mnt//rootfs

　　id 可以通过以下命令获取。

　　docker inspect -f '{{.GraphDriver.Data.DeviceName}}'

　　Logtail解决方案

　　日志服务团队在充分对比采集容器日志的各种方法，综合梳理用户的反馈和诉求后，推出了容器日志的一站式解决方案。

　　

　　特征

　　logtail解决方案包括以下功能：

　　支持主机上容器的采集主机文件和日志（包括标准输出和日志文件）；支持容器自动发现，即配置采集目标时，只要有满足条件的容器创建时，容器上的目标日志就会自动采集；支持通过docker标签和环境变量过滤指定容器，支持白名单和黑名单机制；采集数据自动标记，即对采集的日志自动添加容器名、容器IP、文件路径等用于识别数据源的信息；支持 采集 K8s 容器日志。核心优势是通过检查点机制和部署额外的监控流程来确保至少一次语义；经过多次双十一、双十二测试和阿里巴巴集团内部百万级部署规模，稳定性和性能都非常不错。保证。K8s 容器日志采集

　　与K8s生态深度融合，非常方便采集 K8s容器日志是日志服务logtail解决方案的另一大特色。

　　采集配置管理：

　　支持采集通过WEB控制台进行配置管理；支持采集通过CRD(CustomResourceDefinition)方式进行配置管理（这种方式更容易与K8s部署发布流程集成）。

　　采集模式：

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

　　关于Logtail方案的详细说明，请参考文章综合改进、阿里云Docker/Kubernetes(K8S)日志方案及选型对比。

　　查询分析和可视化

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

　　快速搜索

　　当容器日志为采集时，会携带容器名称、容器IP、目标文件路径等信息，所以在查询的时候可以通过这些信息快速定位目标容器和文件。查询功能的详细介绍请参考文档查询语法。

　　实时分析

　　日志服务的实时分析功能兼容SQL语法，提供200多种聚合功能。如果您有使用 SQL 的经验，您可以轻松编写满足您业务需求的分析语句。例如：

　　计算访问的前 10 个 uri。

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

　　统计当前 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访问日志的dashboard，展示了不良请求率、网络流量、状态码随时间变化趋势等信息。此仪表板显示多个 Tomcat 容器的聚合数据。您可以使用仪表盘过滤功能，通过指定容器名称来查看单个容器的数据。

　　

　　日志上下文分析

　　查询分析、仪表盘等功能可以帮助我们掌握全局信息，了解系统的整体运行情况，但定位具体问题往往需要上下文信息的帮助。

　　上下文定义

　　上下文是指围绕问题的线索，例如日志中错误的上下文。上下文由两个元素组成：

　　下表显示了不同数据源的最小区分粒度。

　　分类最小区分粒度

　　独立文件

　　IP + 文件

　　码头工人标准输出

　　容器 + STDOUT/STDERR

　　Dockerfile

　　容器+文件

　　K8s 容器标准输出

　　命名空间 + Pod + 容器 + STDOUT/STDERR

　　K8s 容器文件

　　命名空间 + Pod + 容器 + 文件

　　SDK

　　线

　　日志附加器

　　线

　　上下文查询的挑战

　　在集中式日志存储的情况下，采集 端和服务器端都很难保证日志的原创顺序：

　　在客户端层面，一个主机上运行着多个容器，每个容器都会有多个需要采集的目标文件。log采集软件需要利用机器的多个CPU核对日志进行解析和预处理，通过多线程并发或单线程异步回调处理网络发送的IO慢问题。这可以防止日志数据按照机器上事件的生成顺序到达服务器。在服务器层面，由于采用水平可扩展的多机负载均衡架构，同一客户端机器的日志会分散在多个存储节点上。根据分散的日志很难恢复原来的顺序。原则

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

　　

　　当日志为采集时，用于标识日志源的信息（即上面提到的最小区分粒度）会自动添加为source_id。对于容器场景，这些信息包括容器名称、文件路径等。日志服务的各种采集客户端一般都会选择批量上传日志，多条日志形成一个数据包。客户端会在这些包中写入一个单调递增的package_id，包中的每条日志在包内都有一个偏移量；服务器会将 source_id、package_id 和 offset 组合为一个字段并为其创建索引。这样，即使各种日志在服务器上以混合状态存储，我们也可以根据source_id、package_id和offset，精确定位到一条日志。

　　如果想详细了解上下文分析的功能，请参考文章上下文查询，分布式系统日志上下文查询功能。

　　LiveTail - 云尾 -f

　　除了查看日志的上下文信息，有时我们还希望能够持续观察容器的输出。

　　传统方式

　　下表展示了如何在传统模式下实时监控容器日志。

　　类别步骤

　　标准输出

　　1. 定位容器，获取容器id；

　　2. 使用命令 docker logs –f 或 kubectl logs –f

　　观察终端上的输出；

　　3. 使用 grep 或 grep -v 过滤掉关键信息。

　　文本日志

　　1. 定位容器，获取容器id；

　　2. 使用命令 docker exec 或 kubectl exec 进入容器；

　　3. 找到目标文件，使用命令tail -f 观察输出；

　　4. 使用 grep 或 grep -v 过滤掉关键信息。

　　痛点

　　通过传统方式监控容器日志存在以下痛点：

　　当容器较多时，定位目标容器耗时耗力；不同类型的容器日志需要不同的观察方式，增加了使用成本；关键信息的查询和展示并不简单直观。功能与原理

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

　　可以根据单个日志或日志服务的查询分析功能快速定位目标容器；在不进入目标容器的情况下，统一观察不同类型的容器日志；支持关键词过滤；支持设置键列。

　　

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

　　视频样本

　　也可以观看视频进一步了解采集的功能，容器日志的查询、分析和可视化。

　　参考 技术支持