日志系统之基于flume收集docker容器日志

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: 最近我在日志收集的功能中加入了对docker容器日志的支持。这篇文章简单谈谈策略选择和处理方式。 关于docker的容器日志 docker 我就不多说了,这两年火得发烫。最近我也正在把日志系统的一些组件往docker里部署。

最近我在日志收集的功能中加入了对docker容器日志的支持。这篇文章简单谈谈策略选择和处理方式。

关于docker的容器日志

docker 我就不多说了,这两年火得发烫。最近我也正在把日志系统的一些组件往docker里部署。很显然,组件跑在容器里之后很多东西都会受到容器的制约,比如日志文件就是其中之一。

当一个组件部署到docker中时,你可以通过如下命令在标准输出流(命令行)中查看这个组件的日志:

docker logs ${containerName}

日志形如:

终端查看docker容器日志

但这种方式并不能让你实时获取日志并对它们进行收集。但是docker还是比较友好的,它把这些日志文件都保存在以容器ID为文件名的文件系统中。如果你是标准安装的话,那么它应该在文件系统的如下位置:

/var/lib/docker/containers/${fullContainerId}/${fullContainerId}-json.log

这个fullContainerId应该如何获得呢?简单一点,你可以通过如下命令来查看full container-id:

docker ps --no-trunc

然后通过vi 命令来查看日志文件。但基于文件的日志和基于标准输出流的日志是有区别的,区别是基于文件的日志是json形式的,并且以标准输出流的一行作为日志的间隔。形如:

文件查看docker容器日志

这相当于两层日志格式,外面这一层是docker封装的,格式是固定的;而内层则是因具体的组件而不同的。外面的格式其实对我们而言是无用的,但还是要先解析完外层日志之后,才能回到我们收集组件格式的上下文中来。

如果这是docker给我们日志收集带来的麻烦之一,那么下面还有一个更棘手的问题就是:多行日志的关联性问题。比较常见的一个例子就是程序的异常堆栈(stacktrace)。因为在标准输出流中,这些异常堆栈是分多行输出的,所以在docker日志中一个异常堆栈被以多条日志拆开记录就像上面的示例日志一样。

其实在基于非docker日志文件的日志收集中,我们已经针对以异常堆栈为主的多行关联性日志的收集进行了支持,但现在的一个问题是docker不但把关联性日志拆成多条,而且在外面包裹了自己的格式,导致我们在不解析的情况下根本拿不到真正的日志分隔符,日志分隔符用于区分多行日志内容中真正的日志分隔界限。比如上图示例的log4j日志,我们通过判断行首前缀是否有[,来判断某一行是一条日志的起点还是应该被追加到上一条日志中。

处理方案

客户端不解析

在没有遇到docker容器日志之前,我们遵循的规则是:agent只负责采集,不作任何解析,解析在storm里进行。针对上面这种docker容器的多行关联性日志,在客户端不解析自然没办法识别关联性,那么就只能作逐行收集,然后在服务端解析。如果在服务端解析,就要保证同一个日志文件中日志的顺序性。

  • 基于队列的顺序性

我说的这种队列是日志收集之后暂存在消息中间件中的消息队列。这可以确保日志在解析之前一直保证顺序性,但这样的代价显然是很高的,为了一个节点上的一种日志就要单开一个队列,那么多节点上的多日志类型将会使得消息中间件中的队列快速增多,而性能开销也非常大。并且还有个问题是,单纯保证在消息队列里有序还不够,还必须让消费者(比如storm)的处理逻辑针对这个队列是单一的,如果一个消费者负责多个不同的日志队列,那么还是无法识别单一文件的日志顺序性。但是如果消费者跟日志队列一对一处理,那么像storm这种消费者应对新日志类型的扩展性就会降低。因为storm的实时处理是基于topology的,一个topology既包含输入(spout)也包含输出逻辑。这种情况下每次新增一个日志列队,topology就必须重启一次(为了识别新的spout)。

  • 基于自增序列排序的顺序性

如果不通过外部的数据结构来维持单一日志文件中日志的顺序性,那就只能通过为每个日志添加序列号来标识日志的顺序性。这种方式可以允许日志在消息中间件中无序、混合存储。但它同样存在弊端:

(1)单一的序列号还不足够,还需要额外的标识才能区分同类、不同主机的日志(集群环境)

(2)为了得到前后有关联的日志,日志必须先落数据库,然后借助于排序机制还原原先的顺序,然后按顺序进行合并或者单一处理

上面这两点都比较棘手。

客户端解析docker日志格式

上面分析了客户端不解析存在的问题,另一种做法是客户端解析。因为docker的格式是固定的,这相对省了点事,我们可以选择只做外层解析,也就是对docker容器日志的格式做解析,以此来还原原始日志(注意这里原始日志还是纯文本),而拿到原始日志之后,就可以根据原先的日志分隔符解析多行关联性日志,其他问题也就不存在了。但毫无疑问,这需要对日志采集器进行定制。

flume的定制

flume对日志的读取逻辑组件称之为EventDeserializer,这里我们使用的MultiLineDeserializer是基于LineDeserializer定制的。

首先我们定义一个配置项来标识日志是否是docker产生的:

wrappedByDocker = true

接着,我们根据docker的json格式定义其对应的Java Bean:

    public static class DockerLog {

        private String log;
        private String stream;
        private String time;

        public DockerLog() {
        }

        public String getLog() {
            return log;
        }

        public void setLog(String log) {
            this.log = log;
        }

        public String getStream() {
            return stream;
        }

        public void setStream(String stream) {
            this.stream = stream;
        }

        public String getTime() {
            return time;
        }

        public void setTime(String time) {
            this.time = time;
        }
    }

然后,当我们读取一行之后,如果日志是docker产生的,那么先用gson将其反序列化为java对象,然后取出我们关心的log字段拿到原始日志文本,接下来的处理就跟原来一样了。

readBeforeOffset = in.tell();
String preReadLine = readSingleLine();

if (preReadLine == null) return null;

    //if the log is wrapped by docker log format,
    //should extract origin log firstly
    if (wrappedByDocker) {
        DockerLog dockerLog = GSON.fromJson(preReadLine, DockerLog.class);
        preReadLine = dockerLog.getLog();
    }

这样agent采集到的日志就都是原始日志了,也就保证了后续一致的解析逻辑。

针对flume的完整定制开源在github/flume-customized.


原文发布时间为:2016-02-07
本文作者:vinoYang
本文来自云栖社区合作伙伴CSDN博客,了解相关信息可以关注CSDN博客。
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
2月前
|
存储 数据采集 数据处理
【Flume拓扑揭秘】掌握Flume的四大常用结构,构建强大的日志收集系统!
【8月更文挑战第24天】Apache Flume是一个强大的工具,专为大规模日志数据的收集、聚合及传输设计。其核心架构包括源(Source)、通道(Channel)与接收器(Sink)。Flume支持多样化的拓扑结构以适应不同需求,包括单层、扇入(Fan-in)、扇出(Fan-out)及复杂多层拓扑。单层拓扑简单直观,适用于单一数据流场景;扇入结构集中处理多源头数据;扇出结构则实现数据多目的地分发;复杂多层拓扑提供高度灵活性,适合多层次数据处理。通过灵活配置,Flume能够高效构建各种规模的数据收集系统。
30 0
|
7天前
|
Kubernetes API Docker
跟着iLogtail学习容器运行时与K8s下日志采集方案
iLogtail 作为开源可观测数据采集器,对 Kubernetes 环境下日志采集有着非常好的支持,本文跟随 iLogtail 的脚步,了解容器运行时与 K8s 下日志数据采集原理。
|
2月前
|
缓存 NoSQL Linux
【Azure Redis 缓存】Windows和Linux系统本地安装Redis, 加载dump.rdb中数据以及通过AOF日志文件追加数据
【Azure Redis 缓存】Windows和Linux系统本地安装Redis, 加载dump.rdb中数据以及通过AOF日志文件追加数据
【Azure Redis 缓存】Windows和Linux系统本地安装Redis, 加载dump.rdb中数据以及通过AOF日志文件追加数据
|
1月前
|
JSON 缓存 fastjson
一行日志引发的系统异常
本文记录了一行日志引发的系统异常以及作者解决问题的思路。
|
6天前
使用装饰器实现自动化日志系统
使用装饰器实现自动化日志系统
|
2月前
|
存储 JSON Kubernetes
容器日志收集与管理
【8月更文挑战第26天】Kubernetes中的集群级日志处理确保应用程序日志在容器、Pod或节点出现故障时仍可获取。
|
2月前
|
存储 分布式计算 大数据
【Flume的大数据之旅】探索Flume如何成为大数据分析的得力助手,从日志收集到实时处理一网打尽!
【8月更文挑战第24天】Apache Flume是一款高效可靠的数据收集系统,专为Hadoop环境设计。它能在数据产生端与分析/存储端间搭建桥梁,适用于日志收集、数据集成、实时处理及数据备份等多种场景。通过监控不同来源的日志文件并将数据标准化后传输至Hadoop等平台,Flume支持了性能监控、数据分析等多种需求。此外,它还能与Apache Storm或Flink等实时处理框架集成,实现数据的即时分析。下面展示了一个简单的Flume配置示例,说明如何将日志数据导入HDFS进行存储。总之,Flume凭借其灵活性和强大的集成能力,在大数据处理流程中占据了重要地位。
36 3
|
2月前
|
存储 消息中间件 监控
Java日志详解:日志级别,优先级、配置文件、常见日志管理系统ELK、日志收集分析
Java日志详解:日志级别,优先级、配置文件、常见日志管理系统、日志收集分析。日志级别从小到大的关系(优先级从低到高): ALL < TRACE < DEBUG < INFO < WARN < ERROR < FATAL < OFF 低级别的会输出高级别的信息,高级别的不会输出低级别的信息
|
2月前
|
存储 大数据 索引
【Azure Contianer Apps】在云上使用容器应用时收集日志遇见延迟问题
【Azure Contianer Apps】在云上使用容器应用时收集日志遇见延迟问题
|
5月前
|
存储 分布式计算 监控
【Flume】Flume 监听日志文件案例分析
【4月更文挑战第4天】【Flume】Flume 监听日志文件案例分析
下一篇
无影云桌面