初创型公司日志中心平台的搭建的历程

2019独角兽企业重金招聘Python工程师标准>>>

背景

    日志的重要性，我想大家都比较清楚，不管是小型系统还是大型复杂系统，都需要使用日志，日志是保障高可靠服务的基础。它记录着程序运行时产生的错误信息、状态信息、调试信息、耗时等信息，在生产环境中，日志是我们查找问题的主要依据。

    现如今互联网大规模，分布式的特性，日志源头也比较分散，日志产生的速度也越来越快，传统工具（如cat/tail/awk/grep等命令），已经不能满足我们的需求。（即日志量大，速度快）

    日志使用的范围扩大，不仅仅用来查找bug解决问题，可以用来做数据分析或者监控等等。我们可以通过分析日志数据，了解用户行为、系统性能等。不断帮助我们改进产品，快速成长。

    基于以上的几点，构建日志中心是必然的趋势。那么下面我们来谈一谈日志中心的产品定位是什么样的。首先，它是一个集中的日志查询、统计分析平台，其次，它是一个灵活易用的数据收集，分析，可视化开放平台。

整体架构

    日志中心架构从无到有，肯定是要经过很多迭代的。最初，刚刚搭建的日志中心可能是以下这个样子

采用fluentd（一款开源的日志收集工具）进行采集和收集数据，缓存在kafka中，最后写入es集群，这个是最原始的结构。使用fluentd_kafka插件，消费kafka中的数据。这种架构在日志量少的时候没什么问题，但是当部署的采集端越来越多，日志堆积就成了一个显而易见的毛病。而且有些公司采用fluented没有考虑到维护的问题，因为它是由ruby写的，没有ruby工程师。后来决定从卡夫卡到es中间开发了一个，日志同步模块，将卡夫卡的数据同步到ES中

后来我们想让中转过程灵活多变，例如灵活分配日志的输出队列，核对信息添加，总之就是想自己在中转部分控制更多，那么结构又发生了变化，我们开发了自己的中转组件，形成了现有的架构体系。

采用的是EFK框架，elasticsearch+fluentd+kibana，从左到右来看，分为采集层+中转层+同步层+存储层。

采集端的话，有落盘和不落盘两种方式，前者我们在应用所在节点部署fluentd进行采集，后者应用log-sender组件，将日志通过网络方式直接发送到中转中心。目前，日志中心负责采集公司所有业务日志，日志类型包括：应用日志，监控日志，系统日志，cdn日志等等。

同步服务，负责将kafka中的数据同步到ES，Cassandra中去，Cassandra是用来做归档存储用的。上图从上往下看，是平台对外提供的服务，kibana，作为日志中心平台的主要入口，用户可以查询日志、统计分析日志，数据可视化。监控平台，用户可以灵活的配置监控报警，查询API，业务线研发人员可以方便地使用es中的数据。下面我们从宏观的角度讲讲：采集层+中转层+同步层+存储层。

这里我们提出一个概念，unified logging layer，缩写ULL统一日志收集层。日志收集，是有价值数据来源的 一个重要的构成，ULL可以帮助我们更快、更可靠、并且可扩展的收集日志。大家对比一下下面两张图：

ULL就相当于一个管家一样，把杂乱无章的日志分析归并整理到一起去。其实无论是使用flume还是fluentd或者logstash都是在解决这个问题，那么fluentd是ULL的一种实现形式，是一个开源工程，它的几个重要的特性是：

• 使用json作为统一的格式
• 保证可靠传输，支持基于内存或者文件的缓存，支持强大的故障转移，保障高可用
• 通过插件方式实现所有的input和output，具有灵活的插件机制
• 使用ruby编写，占用系统资源较少

在日志中，tag这个概念很重要，我们使用tag来标识一条数据流，这个概念在整个日志中心平台都是非常重要。每个应用都有一个appname来唯一标识，业务日志数据流，tag为log.{appname}。统计分析数据流或者监控流，tag为monitor.{appname}.{label}。接下来介绍中转transfer4j和同步fluent4j。中转transfer4j，我们是使用netty实现的，支持fluented-forward协议，难点在于msgpack协议跨语言的问题。

接下来我们说一下es集群，如下图所示：

目前我们拥有两种类型的集群，日志集群和监控集群（或者叫统计分析集群）

日志集群主要用来存放业务的日志数据。业务集群中的节点又划分为hot和warm节点，hot节点使用ssd，warm节点使用sata盘。hot节点用来存储近5天的数据，warm节点用来存放历史数据。

监控集群，用来存放监控数据和待分析数据。监控集群采用的全部都是ssd。

下面我们来讲一下，设计时候的考虑因素，从三个方面进行讲解：可用性，可靠性，可扩展性

可用性，是指固定周期内系统无故障运行总时间，要想保障高可用，就得解决单点问题。采集端挂了或者是堆积了，我们对采集端是有监控的，监控是否存活，监控是否有堆积，如果有问题会立即重启。中转挂了，我们的中转有两种类型，fluentd和自己开发的transfer4j，每种类型的中转都部署了很多，都有负载均衡的策略，并且采集端都是有重试机制的，当某个中转不能使用的时候，采集端会将数据发送到其他中转。

Kafka挂了的话，我们的中转无法将数据发送到kafka，这时候会将数据写入到磁盘进行缓存，kafka恢复以后，我们将数据刷新到kafka中，另外我们有两套kafka，如果坏了，我们也可以通过切换的方式将数据同步到另一个kafka集群中。

当同步数据变慢的情况，一般情况下变慢的主要原因是es的问题，写失败比较多，这种情况下，我们会进行同步限流，当然写失败的数据我们会再存入lost队列里。正是由于这种机制，当es集群出问题的时候，同步过程会进行限流，数据也都还在队列中，可以留下足够的时间来给工程师修复。

接下来说一下可靠性，主要说两点

• 采集端，中转，同步文件都有文件缓存机制，保证可靠传输。
• 日志核对方案

第二点我们来重点说明一下，日志核对方案的来源，是twitter distributedlog的log分段

当时，做日志核对问题，很头疼怎么核对都有问题。后来看到了这个图，找到了方案。

• 每个应用启动以后，会产生一个唯一的init_id，每天凌晨会新产生一个init_id
• 每条日志会有一个行号linenum

那我们只需要针对一个init_id来核对日志，看是否连续即可。

接下来介绍可扩展性

• 采集端，每个虚机装一个fluentd或者采用log-sender将数据发送到远端。采集端可以任意扩展，不受限制。如果采集端数量比较大，可能受限于中转，由于中转到采集端有负载均衡，所以中转可以做线性扩展。
• 中转，可以快速进行线性扩展，它可能受制于kafka队列，我们可以增加中转队列，提高同步并发。
• 同步，根据队列的个数，进行线性扩展即可。它很可能受限于ES。
• ES集群，分布式的，我们可以通过扩展节点，或者增加新集群的方式，来解决问题。

接下来我们说一下运维管理方面

• 索引管理工具，curator在索引很多的情况下，并不理想，我们自己开发了索引运维工具，自动创建索引，自动关闭索引，删除索引，合并索引等等。
• es监控，我们使用monitoring插件以及cerebro（kopf替代品）
• 监控，一个大型的复杂系统，监控是非常重要的，有助于我们及时发现问题，保障高可用以及高可靠。我们做了很多监控仪表盘，以及报警机制。

在采集端，我们监控采集端状态以及堆积情况。

中转端，监控中转速率和缓存大小以防止堵塞。

同步组件，我们会监控同步组件的一些健康信息，如同步线程数，同步线程的信箱大小。

kafka：我们监控队列的入速和出速、消息堆积情况。

es：master节点负载均衡情况监控， 节点丢失情况监控，OOM监控，第二天的索引是否创建成功监控等等。索引是否有数据监控。

接下来我们介绍一下应用场景：

1. 日志查询

亦即查日志，排错处理，对日志进行统计分析，快速定位问题。

这是一个日志查询截图，大家都比较熟悉，下面我再来介绍计算平台数据分析相关，在没有平台的情况下，实现一个业务监控或者统计分析，步骤如下：

1. 数据收集，没有一个统一的方式，即便是有数据库的ETL，但并非所有的数据都可以从数据库中来。
2. 数据存储，独自管理和维护
3. 数据实时化处理，可视化，查询接口，定制化开发
4. 数据核对，数据归档，数据重放，工作繁琐，大多数业务开发人员都会力不从心。

有了日志中心这个平台，我们就可以这样实现我们的业务监控或者统计分析：

统一的数据收集，然后通过计算平台，进行数据加工，数据最终存储在es中。我们还可以通过kibana来配置图表，通过查询接口，简单访问数据，通过监控平台，配置监控报警。这样，开发周期大大减少，平台化，减少重复造轮子，降低使用门槛，提高工作效率。

接下来介绍监控部分，监控配置集成在kibana中，简单易用，基于资源对象的监控，可以设置通用指标，快速实施监控报警。通知方式，支持短信邮件电话。支持类型有单值类型，比值类型，凑笔数比值类型，最近单值型，最近比值型。

目前，支持异常日志监控，业务监控，系统监控，接口调用情况监控，jvm监控，Tomcat监控。

监控，我想说两点，第一，配置集成在kibana中，

1. kibana可视化，图表功能，即是数据的获取方式（aggdsl）
2. 将监控配置集成在kibana中，最合适不过了，所见即所得
3. 简化了监控指标的生成方式，可视化配置报警，简单易用
4. 监控平台开发，也降低了难度

第二点 基于资源对象的监控模型

可以设置通用指标，快速实施监控报警，接下来我们介绍一下kibana二次开发相关内容。

XXXXXXXXXX

 

转载于:https://my.oschina.net/hunglish/blog/1527017