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

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

关于docker的容器日志

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

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

docker logs ${containerName}

日志形如:

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

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

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

docker ps --no-trunc

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

这相当于两层日志格式,外面这一层是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.

时间: 2024-10-01 05:23:47

日志系统之基于flume收集docker容器日志的相关文章

Docker容器日志管理介绍

Docker容器日志分为2类: Docker引擎日志(Docker本身运行的日志). 容器日志,各个容器内产生的日志. Docker引擎日志Centos系统下Docker引擎log一般给systemd管理,可通过 journalctl -u docker.service 命令查看. 容器日志一.查看日志命令docker logs 容器ID 显示当前运行容器的log,输出Linux下的STDOUT(标准输出).STDERR(标准错误输出),docker logs 显示的内容包含STDOUT和STD

Docker容器日志清理

前言 最近发现公司Gitlab服务器磁盘满了,经排查发现是docker容器日志占用了几十个G容量,那么这些日志怎么去查看和清理呢? 本节主要讲到的知识点如下: (1)Docker容器日志路径 (2)如何清理Docker容器日志 (3)如何从根本上解决Docker容器日志占用空间问题 Docker容器日志路径 在linux上,容器日志一般存放在/var/lib/docker/containers/container_id/下面,以json.log结尾的文件(业务日志).如下: 如何清理Docker

docker logs-查看docker容器日志

只限制最后100条的日志,并持续更新日志显示 docker logs -f --tail=100 CONTAINER_ID docker logs -f --tail 100 CONTAINER_ID https://docs.docker.com/engine/reference/commandline/logs/ https://www.jianshu.com/p/1eb1d1d3f25e 分类: docker系列 标签: docker logs-查看docker容器日志 原文地址:http

Graylog2实现Docker容器日志收集

Graylog2 是一个开源的日志存储系统,是由java语言编写的server,能够接收TCP,UDP,AMQP的协议发送的日志信息,并且基于mongodb数据库服务器快速存储,能够通过一个基于ruby编写的web管理界面,让轻松管理你的日志. 1.组件准备 名称 组件名称 备注 1 mongodb 2 elasticsearch 3 graylog2 2.安装使用Docker-compose部署docker-compose安装,参考:http://hujianxiong.com/linuxan

日志系统之基于Zookeeper的分布式协同设计

最近这段时间在设计和实现日志系统,在整个日志系统系统中Zookeeper的作用非常重要--它用于协调各个分布式组件并提供必要的配置信息和元数据.这篇文章主要分享一下Zookeeper的使用场景.这里主要涉及到Zookeeper在日志系统中的使用,但其实它在我们的消息总线和搜索模块中也同样非常重要. 日志元数据 日志的类型和日志的字段这里我们统称为日志的元数据.我们构建日志系统的目的最终主要是为了:日志搜索,日志分析.这两大块我们很大程度上依赖于--ElasticSearch(关于什么是Elast

基于Flume+LOG4J+Kafka的日志采集架构方案

本文将会介绍如何使用 Flume.log4j.Kafka进行规范的日志采集. Flume 基本概念 Flume是一个完善.强大的日志采集工具,关于它的配置,在网上有很多现成的例子和资料,这里仅做简单说明不再详细赘述.Flume包含Source.Channel.Sink三个最基本的概念: Source——日志来源,其中包括:Avro Source.Thrift Source.Exec Source.JMS Source.Spooling Directory Source.Kafka Source.

Docker 容器日志的那些事儿

如果时光可以倒流,现实世界的每一步都可以分解到最小,记录下来,就是日志,万物即日志. 面对历史,审视日志,可以选择忘却,也可以选择铭记:经历过的,可以选择珍藏,同样也可以让它尘封. Docker容器又何尝不是?日志就像一根时间轴,你在或者不在,他都在那.有人对其善意,有人却对其随意.如若不信,可以回忆,自己是否善待Docker容器的日志. 1.传统应用的日志 如若不是被过去伤得太深,踏入一个新的世界,应该还是会怀念过往的吧.新世界的"诱惑"与崭新的节奏,相信依旧无法掩盖旧世界的铅印.数

efk收集k8s 容器日志安装记录

部署环境 $ kubectl get node NAME STATUS ROLES AGE VERSION master01 Ready master 13d v1.14.0 master02 Ready master 13d v1.14.0 master03 Ready master 13d v1.14.0 node01 Ready <none> 13d v1.14.0 node02 Ready <none> 13d v1.14.0 node03 Ready <none&g

使用jar包格式化Docker 容器日志

前面使用JS格式化textarea中的日志内容,但局限于JS语言性能,在日志内容较多时效率无法接受,建议日志内容大于5000行时转投本java程序,文末提供jar包下载. LogsFormat.java package com.geostar.gfstack.docker.util; import com.google.gson.JsonObject; import com.google.gson.JsonParser; import org.apache.commons.io.IOUtils;