?京东大数据日志生命周期与告警避坑指南

导读：本文将分享京东大数据日志生命周期与告警避坑指南，主要内容包括：

01

背景介绍

京东智能城市操作系统是以数据汇聚、数据治理、数据管理、数据分析挖掘为核心场景的应用产品体系，在整个大的产品体系下，我们有很多微服务子系统都存在大量的离散日志，这些日志记录着很多有价值的信息，比如程序运行日志、安全相关日志、SQL相关日志、调度系统的日志，以及数据链路相关的日志。要想从这些离散的日志中通过低成本的接入以及处理，提取相应的有价值的信息，就需要建立一整套完整的管理体系。因为我们有一些私有化部署的政府项目，所以希望日志系统能够提供一些组件化的分析工具，可以让运维人员和数据工程师快速定位问题发现问题，提升整体的业务运维效率。在这个大背景下，我们就需要一个完整的日志解决方案。

--

02

平台能力

1. 功能概要

日志平台的核心功能，主要分为日志采集、数据存储、数据加工、数据投递、日志告警模块。

首先，通过不同的日志采集手段，将日志从不同的环境进行全方位的采集。采集之后，利用核心的数据加工功能，把离散的非结构化日志进行分类分级，提取有特定业务属性的日志，通过业务属性的唯一标识把具有相同业务属性的日志分别进行存储。离散日志结构化存储之后，可以提供一些基本的检索查询或者问题定位相关的功能，还可以将相应的业务日志输出到Hadoop平台或者消息平台，供下游的日志分析系统进行离线计算或者实时计算。最后，可以根据业务日志制定基于关键字或者基于时间窗口聚类的告警，加速运维小伙伴和数据工程师排查定位问题以及解决问题的效率。

2. 日志系统选型

目前在市面上比较主流的三大类日志解决方案有ELK、splunk和Graylog。

上图所示是针对ELK和Graylog做的一些对比。ELK和Graylog都是开源免费的产品，但是Graylog运维成本比较低，并且自带告警支持，可视化比较强，扩展性也比较强。

下面总结一下Graylog的优势。

首先是部署维护简单，扩展性方面可以自定义开发一些扩展脚本，通过curl方式直接发送到Graylog。它的查询语法比较简单，并且提供了搜索高亮的功能，此外查询条件可以导出为elasticsearch的搜索json文本，可以无缝对接ES的api，直接使用json文本进行ES的封装。日志查询时会通过相对时间或绝对时间先锁定时间范围，再固定相应的服务把结果数据查询出来。Graylog做了一层基于时间的查询索引，它会把索引的开始结束时间以及索引的名称，存储到一个索引表中，每次查询时先去命中索引表，查询相应时间段的索引集。

Graylog的UI操作比较友好，提供了可以监控Graylog整个集群情况的监控管理页面，支持上下线和动态扩容等操作，还可以做一些ES集群分片级别的简单监控。

3. 采集技术

以上是对整个日志框架的介绍，日志系统最重要的技术在于采集技术的选型与使用，日志采集技术我们分为两大部分，一种是非入侵方式，一种是入侵方式。

先介绍下非入侵方式，市面上使用比较多的是Filebeat、Logstash和FLume。Filebeat在资源占用和CPU内存方面表现比较出色，和其他相比它的运行情况比较稳定。它们都支持二次开发并且都是单点的，但是Filebeat的二次开发能力比较强，而且Filebeat有个极其轻量的二进制文件，部署安装时可以节省很多运维成本。与其它两个相比，它最重要的功能是具有背压能力，在流量比较大的情况下，会给系统带来极大的提升，让系统不至于崩溃。

介绍入侵方式前，先介绍一种日志的格式——GELF，它是一种扩展的类JSON的日志格式，它的每一条日志都会有以下字段：日志来源主机或者ip、时间戳、版本、消息的长版和短板，还可以自定义一些静态字段。比如我们会植入服务所在的系统、应用、以及所处的服务名称，这样可以形成一条服务数的静态的元数据链条，日志系统再根据日志来源的主机ip上报日志的服务数。服务数包括静态数据和动态数据，静态数据包括系统应用和服务，动态数据包括服务ip。检索时，我们会根据服务数以及相应的实例和时间，精确的锁定服务在这个时间内出现的问题。与syslog相比GELF的日志长度更多一些，大概是六万五千多字节，它可以区分日志是数字类型还是字符串类型，而且GELF格式可以压缩传输，大大提高网络传输的性能，并且网络传输的一些规范，RFC比较严格。在有很多方言的情况下，下游解析时无法使用这种方言，会造成日志的丢失或者解析错误的问题，所以我们采用GELF这种格式并对它进行了封装。

入侵方式有GELF kafka和GELF UDP这两种方式，我们可以基于对日志的要求进行选择，如果对日志的完整性和可靠性要求不高，允许少量丢失，可以采用GELF UDP这种方式，如果对日志的采集要求非常高，日志一定不能丢，推荐使用GELF kafka这种方式，并且我们会提供基于kafka的降级的方案。

目前我们SDK内嵌这种方式支持的框架是logback、log4j和log4j2这三大主流的日志框架。关于日志采集我们还有基于磁盘的非微服务方案，我们推荐使用线上微服务，也推荐使用agent这种方式进行日志采集，首先它是非入侵的，不需改动任何代码，只需要在服务器上一键部署安装包，安装包主要有sidecar守护进程、filebeat日志采集器。sidecar主要是通过守护进程对filebeat进行生命周期的管理，比如管理它的配置文件、启动停止操作。Agent可以做到页面的完全可配置，因为它是非入侵的方式，我们还提供了cgroup级别的资源控制，从系统级别限制它的CPU内存，在操作系统级别控制它不使用swap交换内存。在oom情况下服务器不够用时会优先杀死agent，原则上是尽可能小的影响业务系统。服务器重启之后，agent支持自动重启，不需要任何的手动操作。这是关于SDK和Agent的两种日志采集方式。

降级方案可以使用磁盘降级的方案，它会将写入kafka失败的日志落盘，落盘后会使用agent定时或实时的抽取，进行数据的补偿。

4. 日志生命周期

接下来介绍一下日志生命周期。

首先会有一个接入层，数据接入后会有一个内存级别的接入缓存层，数据编解码层对接入的数据进行编解码，编解码之后将数据存到基于kafka的api实现的本地缓存层，我们可以定制一个像kafka topic一样的数据保存时间和保存量，作为一层磁盘级别的数据缓存。数据存到本地磁盘之后，所有的加工操作都在业务处理层进行，业务处理层消费本地缓存层的数据，可以对日志格式相对混乱的日志进行清洗转换加工，转变成格式化的日志，有相同业务属性的日志会提取出来写入同一个ES索引集，日志处理过程中还可以将日志转发第三方的日志系统。以上就是日志在我们服务端的生命周期。

5. SDK封装

介绍一下我们SDK的封装。

这是一条Logback日志生命周期的时序图，SDK的能力就是在第9阶段做扩展，我们可以植入微服务的链路id以及格式的预处理，MDC可以植入一些当前进程相关的字段，比如页面需要执行一个调度任务，调度任务每次执行都会有个实例id，可以通过MDC这种方式植入到日志当中。格式的预处理更多的是业务日志的转换，因为SDK主要是对GELF这种日志扩展的封装，所有我们通过定义JavaBean定义了一个业务日志的打印规范，SDK拦截逻辑会基于这个JavaBean进行拦截，把它们增加到GELF日志当中。这一部分主要做日志的预处理和链路id的植入。

6. 数据加工

日志采集后需要对日志进行加工，主要有三类功能：数据规整、数据脱敏、数据过滤。

数据规整主要是将混乱的系统日志、业务日志等进行提取和格式转换，获取格式化的数据，以支持后续的流处理和数仓的计算。如果日志没有对敏感字段进行加密或脱密，我们的系统可以进行二次的加密或脱密。数据规整后具有相同特性的日志会单独提取出来输出，可以针对这部分日志过滤出关键服务的日志用于重点分析，也可以在关键日志上制定一些基于时间窗口的聚类以及基于时间窗口的关键字告警。

数据加工时需要一些加工函数的支撑应用程序日志，我们内置了400多种加工函数，用户可以自定义注册自己的加工函数。主要的函数分类有GROK，GROK可以在filebeat二进制方式采集的文本进行GROK的关键字提取，包括正则的方式提取关键字，或者时间时区相关的转换等操作，还可以对数据进行编解码的操作。

加工函数可以通过脚本的方式，在选择数据加工任务时选择相应的脚本就可以对日志进行相应的加工处理。

7. 数据存储

加工处理之后的日志有了唯一的业务标识，我们可以通过标识进行分桶存储，相当于分索引集进行存储，分索引集进行存储支持的策略可以按照时间或者数据量进行切分索引集，索引的保存策略可以按照时间进行删除或者将不常查的数据放在ES冷节点上。

我们的索引策略最大的特点是可以动态调整，比如现在的日志流量大概是10万QPS，如果突然增到20万，索引策略就不能支撑现在的流量，我们可以动态地进行调整，调整完之后的下一个索引就会按照调整过后的索引集策略进行索引滚动。

我们的数据存储还支持冷热架构，主要是用ES部署时的冷热数据节点做支撑，通过Curator写定时脚本的方式做冷热数据的定时迁移，迁移过去的数据会把它的副本调为0，尽可能的减少磁盘的占用。对外提供查询时，会提供实时查询及历史数据的查询，会去命中相应的ES索引集。

8. 数据查询

数据查询主要分为三大类，第一大类是我们通用的日志能力，我们会通过类SQL或者DSL语法的扩展抽象出一层指标层，我们自己的日志系统有内置的仪表盘的数据支持，对接第三方的可视化工具。第二大类是支持上下文查询、日志聚类等功能。第三类是第三方如果要接入日志，可以通过http/rpc方式通过写SQL或DSL语法进行指标的即时查询。

9. DSL扩展

数据查询完之后，介绍一下DSL的扩展，主要分为四个部分，第一部分是查询语句，有组合查询、模糊查询、精确查询等查询语法，着重介绍一下模糊查询，它支持冒号和星号查询，冒号支持单个单次的模糊，星号支持后续有多个单词。同一个查询groupby条件下，同一个时间范围内可以提取出多个指标，比如同时提取sum的这种不同字段的指标提取，可以通过同一个接口进行提取。因为我们的日志查询包括日志指标数据的提取，基本上都是基于相对时间或者绝对时间进行提取，我们对这部分也进行了一次封装。

10. 数据投递

数据经过采集和加工区分后，一些日志是第三方系统需要的，比如做一些实时或者离线的计算，我们通过日志系统把它输出到kafka当中，支持下游的离线分析或者实时计算的场景。这是我们数据投递相关的能力。

下面讲一下数据投递的使用场景，我们有一个协调办公的业务线，主要给政府提供协同办公的软件。将应用系统日志采集到日志系统后，通过日志系统的能力做一些清洗转换的操作，对离散的日志做业务集中化的处理之后，把他们输出到相应的kafka topic，下游的实时计算基于特定的业务日志，写一些flink sql做实时计算，将结果输出到相应的mysql表中，后续的监控大屏从数据库查询，提供业务监控大屏的能力。图示是注册用户、外部用户、激活用户和在线用户的24小时统计，而且区分PC、Android和ios等的客户端。

11. 告警

最后介绍一下日志平台的告警，主要分为两大类，一个是事件的定义，我们可以通过模糊检索的方式进行查询，进行关键字的告警。流，相当于不同的索引集，我们可以针对不同的业务日志进行告警，不同的索引集可以多选。日志平台还支持聚类告警，可以针对字段进行阈值的告警定义。事件定义完之后我们会定义一个通知，有个Webhook的功能，对接咚咚、微信等第三方推送系统，还可以通过脚本的方式自定义通知的模板。

图示是我们的使用场景，可以清晰的知道系统在哪个时间，哪个微服务哪个实例上发出关键字的告警，我们可以从日志中提取相应的关键告警字段，比如告警的message。

（编辑：威海站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!