文档章节

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

牧师-Panda
 牧师-Panda
发布于 2017/08/31 16:26
字数 3051
阅读 120
收藏 3

背景

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

    现如今互联网大规模,分布式的特性,日志源头也比较分散,日志产生的速度也越来越快,传统工具(如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

 

© 著作权归作者所有

共有 人打赏支持
牧师-Panda
粉丝 30
博文 146
码字总数 180044
作品 0
浦东
微信公众号如何运营?公众平台推广技巧

     在新媒体时代,微信营销是一种很流行的营销方式,这种营销不仅体现在直接盈利方面,同时也体现在提高公司品牌知名度方面,利用新媒体传播营销是一种受欢迎,在短时间内也很有效。 ...

公众开发运营官网
01/02
0
0
有孚网络副总裁吕鑫:合纵连横,云领未来—如何打造低成本混合云架构

上海有孚网络公司已成功打造知名的服务品牌"阳光互联",通过云计算方式向企业提供低成本高性能的平台式信息化服务,已成为中国首批最大的云计算服务商之一。从设计初衷就前瞻性的定位成为中国...

玄学酱
04/24
0
0
商汤科技、阿里巴巴及香港科技园联手成立 AI 实验室

今日,人工智能创业公司商汤科技、阿里巴巴集团及香港科技园公司宣布合作成立“香港人工智能实验室”。 据雷锋网了解,这是继5月14日中央宣布系列政策,推动香港加强与内地的科技合作,创建国...

技术小能手
05/21
0
0
.Net架构篇:实用中小型公司支付中心设计

前言 说起支付平台,支付宝量级的支付平台和一个小型公司的支付不可同日耳语。一个初创或刚创业一两年的公司,一没人力,二没财力的情况下,如果也想对接支付那怎么办呢?感谢支付宝和微信支...

范存威
09/08
0
0
50余家AI企业倒闭了!风口这么大,还能倒闭?

人工智能,是当前最大风口,充满无限的想象力。直接的影响就是,在这个领域涌现了大批的创业公司。2017年,是人工智能的元年,但是人工智能产业也开始进入休整阶段。据初步估计,已有50余家企...

智能编辑
06/14
0
0

没有更多内容

加载失败,请刷新页面

加载更多

初级开发-编程题

` public static void main(String[] args) { System.out.println(changeStrToUpperCase("user_name_abc")); System.out.println(changeStrToLowerCase(changeStrToUpperCase("user_name_abc......

小池仔
今天
5
0
现场看路演了!

HiBlock
昨天
16
0
Rabbit MQ基本概念介绍

RabbitMQ介绍 • RabbitMQ是一个消息中间件,是一个很好用的消息队列框架。 • ConnectionFactory、Connection、Channel都是RabbitMQ对外提供的API中最基本的对象。Connection是RabbitMQ的s...

寰宇01
昨天
9
0
官方精简版Windows10:微软自己都看不过去了

微软宣布,该公司正在寻求解决方案,以减轻企业客户的Windows 10规模。该公司声称,企业客户下载整个Windows 10文件以更新设备既费钱又费时。 微软宣布,该公司正在寻求解决方案,以减轻企业...

linux-tao
昨天
19
0
TypeScript基础入门之JSX(二)

转发 TypeScript基础入门之JSX(二) 属性类型检查 键入检查属性的第一步是确定元素属性类型。 内在元素和基于价值的元素之间略有不同。 对于内部元素,它是JSX.IntrinsicElements上的属性类型...

durban
昨天
12
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部