日志分析系统搭建分析与比较

Table of Contents

一. 背景介绍

二.日志系统比较

1.怎样收集系统日志并进行分析

A.实时模式:

B.准实时模式

2.常见的开源日志系统的比较

A. FaceBook的Scribe

B. Apache的Chukwa

C. LinkedIn的Kafka

D. Cloudera的Flume

E. 总结

三.较为成熟的日志监控分析工具

1.ELKA.ELK 简介

2.ELK使用场景

3.ELK的优势

4.EFK

5. Logstash 与FluentD(Fluentd)对比


 

一. 背景介绍

许多公司的平台每天会产生大量的日志(一般为流式数据,如,搜索引擎的pv,查询等),处理这些日志需要特定的日志系统,一般而言,这些系统需要具有以下特征:

  • (1) 构建应用系统和分析系统的桥梁,并将它们之间的关联解耦;
  • (2) 支持近实时的在线分析系统和类似于Hadoop之类的离线分析系统;
  • (3) 具有高可扩展性。即:当数据量增加时,可以通过增加节点进行水平扩展。

二.日志系统比较

1.怎样收集系统日志并进行分析

A.实时模式:

  • 1 在打印日志的服务器上部署agent
  • 2 agent使用低耗方式将日志增量上传到计算集群
  • 3 计算集群解析日志并计算出结果,尽量分布式、负载均衡,有必要的话(比如需要关联汇聚)则采用多层架构
  • 4 计算结果写入最适合的存储(比如按时间周期分析的结果比较适合写入Time Series模式的存储)
  • 5 搭建一套针对存储结构的查询系统、报表系统

补充:常用的计算技术是storm

B.准实时模式

  • 1 在打印日志的服务器上部署agent
  • 2 agent使用低耗方式将日志增量上传到缓冲集群
  • 3 缓冲集群将原始日志文件写入hdfs类型的存储
  • 4 用hadoop任务驱动的解析日志和计算
  • 5 计算结果写入hbase
  • 6 用hadoop系列衍生的建模和查询工具来产出报表

补充:可以用hive来帮助简化

2.常见的开源日志系统的比较

A. FaceBook的Scribe

Scribe是facebook开源的日志收集系统,在facebook内部已经得到大量的应用。它能够从各种日志源上收集日志,存储到一个中央存储系统 (可以是NFS,分布式文件系统等)上,以便于进行集中统计分析处理。它为日志的“分布式收集,统一处理”提供了一个可扩展的,高容错的方案。

特点:容错性好。当后端的存储系统crash时,scribe会将数据写到本地磁盘上,当存储系统恢复正常后,scribe将日志重新加载到存储系统中。

架构:

scribe的架构比较简单,主要包括三部分,分别为scribe agent, scribe和存储系统。

(1) scribe agent

scribe agent实际上是一个thrift client。向scribe发送数据的唯一方法是使用thrift client, scribe内部定义了一个thrift接口,用户使用该接口将数据发送给server。

(2) scribe

scribe接收到thrift client发送过来的数据,根据配置文件,将不同topic的数据发送给不同的对象。scribe提供了各种各样的store,如 file, HDFS等,scribe可将数据加载到这些store中。

(3) 存储系统

存储系统实际上就是scribe中的store,当前scribe支持非常多的store,包括file(文件),buffer(双层存储,一个主储存,一个副存储),network(另一个scribe服务器),bucket(包含多个 store,通过hash的将数据存到不同store中),null(忽略数据),thriftfile(写到一个Thrift TFileTransport文件中)和multi(把数据同时存放到不同store中)。

B. Apache的Chukwa

chukwa是一个非常新的开源项目,由于其属于hadoop系列产品,因而使用了很多hadoop的组件(用HDFS存储,用mapreduce处理数据),它提供了很多模块以支持hadoop集群日志分析。

需求:

  • (1) 灵活的,动态可控的数据源
  • (2) 高性能,高可扩展的存储系统
  • (3) 合适的框架,用于对收集到的大规模数据进行分析

架构:

Chukwa中主要有3种角色,分别为:adaptor,agent,collector。

(1) Adaptor 数据源

可封装其他数据源,如file,unix命令行工具等
目前可用的数据源有:hadoop logs,应用程序度量数据,系统参数数据(如linux cpu使用流率)。

(2) HDFS 存储系统

Chukwa采用了HDFS作为存储系统。HDFS的设计初衷是支持大文件存储和小并发高速写的应用场景,而日志系统的特点恰好相反,它需支持高并发低速率的写和大量小文件的存储。需要注意的是,直接写到HDFS上的小文件是不可见的,直到关闭文件,另外,HDFS不支持文件重新打开。

(3) Collector和Agent

为了克服(2)中的问题,增加了agent和collector阶段。
Agent的作用:给adaptor提供各种服务,包括:启动和关闭adaptor,将数据通过HTTP传递给Collector;定期记录adaptor状态,以便crash后恢复。

Collector的作用:对多个数据源发过来的数据进行合并,然后加载到HDFS中;隐藏HDFS实现的细节,如,HDFS版本更换后,只需修改collector即可。

(4) Demux和achieving

直接支持利用MapReduce处理数据。它内置了两个mapreduce作业,分别用于获取data和将data转化为结构化的log。存储到data store(可以是数据库或者HDFS等)中。

C. LinkedIn的Kafka

Kafka是2010年12月份开源的项目,采用scala语言编写,使用了多种效率优化机制,整体架构比较新颖(push/pull),更适合异构集群。

设计目标:

  • (1) 数据在磁盘上的存取代价为O(1)
  • (2) 高吞吐率,在普通的服务器上每秒也能处理几十万条消息
  • (3) 分布式架构,能够对消息分区
  • (4) 支持将数据并行的加载到hadoop

架构:

Kafka实际上是一个消息发布订阅系统。producer向某个topic发布消息,而consumer订阅某个topic的消息,进而一旦有新的关于某个topic的消息,broker会传递给订阅它的所有consumer。在kafka中,消息是按topic组织的,而每个topic又会分为多个partition,这样便于管理数据和进行负载均衡。同时,它也使用了zookeeper进行负载均衡。

Kafka中主要有三种角色,分别为producer,broker和consumer。

(1) Producer

Producer的任务是向broker发送数据。Kafka提供了两种producer接口,一种是low_level接口,使用该接口会向特定的broker的某个topic下的某个partition发送数据;另一种那个是high level接口,该接口支持同步/异步发送数据,基于zookeeper的broker自动识别和负载均衡(基于Partitioner)。
其中,基于zookeeper的broker自动识别值得一说。producer可以通过zookeeper获取可用的broker列表,也可以在zookeeper中注册listener,该listener在以下情况下会被唤醒:

a.添加一个broker
b.删除一个broker
c.注册新的topic
d.broker注册已存在的topic

当producer得知以上时间时,可根据需要采取一定的行动。

(2) Broker

Broker采取了多种策略提高数据处理效率,包括sendfile和zero copy等技术。

(3) Consumer

consumer的作用是将日志信息加载到中央存储系统上。kafka提供了两种consumer接口,一种是low level的,它维护到某一个broker的连接,并且这个连接是无状态的,即,每次从broker上pull数据时,都要告诉broker数据的偏移量。另一种是high-level 接口,它隐藏了broker的细节,允许consumer从broker上push数据而不必关心网络拓扑结构。更重要的是,对于大部分日志系统而言,consumer已经获取的数据信息都由broker保存,而在kafka中,由consumer自己维护所取数据信息。

D. Cloudera的Flume

Flume是cloudera于2009年7月开源的日志系统。它内置的各种组件非常齐全,用户几乎不必进行任何额外开发即可使用。
设计目标:

(1) 可靠性

当节点出现故障时,日志能够被传送到其他节点上而不会丢失。Flume提供了三种级别的可靠性保障,从强到弱依次分别为:end-to-end(收到数据agent首先将event写到磁盘上,当数据传送成功后,再删除;如果数据发送失败,可以重新发送。),Store on failure(这也是scribe采用的策略,当数据接收方crash时,将数据写到本地,待恢复后,继续发送),Best effort(数据发送到接收方后,不会进行确认)。

(2) 可扩展性

Flume采用了三层架构,分别问agent,collector和storage,每一层均可以水平扩展。其中,所有agent和collector由master统一管理,这使得系统容易监控和维护,且master允许有多个(使用ZooKeeper进行管理和负载均衡),这就避免了单点故障问题。

(3) 可管理性

所有agent和colletor由master统一管理,这使得系统便于维护。用户可以在master上查看各个数据源或者数据流执行情况,且可以对各个数据源配置和动态加载。Flume提供了web 和shell script command两种形式对数据流进行管理。

(4) 功能可扩展性

用户可以根据需要添加自己的agent,colletor或者storage。此外,Flume自带了很多组件,包括各种agent(file, syslog等),collector和storage(file,HDFS等)。

架构:

正如前面提到的,Flume采用了分层架构,由三层组成,分别为agent,collector和storage。其中,agent和collector均由两部分组成:source和sink,source是数据来源,sink是数据去向。

(1) agent

agent的作用是将数据源的数据发送给collector,Flume自带了很多直接可用的数据源(source)

(2) collector

collector的作用是将多个agent的数据汇总后,加载到storage中。它的source和sink与agent类似。
下面例子中,agent监听TCP的5140端口接收到的数据,并发送给collector,由collector将数据加载到HDFS上。

一个更复杂的例子如下:

有6个agent,3个collector,所有collector均将数据导入HDFS中。agent A,B将数据发送给collector A,agent C,D将数据发送给collectorB,agent C,D将数据发送给collectorB。同时,为每个agent添加end-to-end可靠性保障(Flume的三种可靠性保障分别由agentE2EChain, agentDFOChain, and agentBEChain实现),如,当collector A出现故障时,agent A和agent B会将数据分别发给collector B和collector C。

此外,使用autoE2EChain,当某个collector 出现故障时,Flume会自动探测一个可用collector,并将数据定向到这个新的可用collector上。

(3) storage

storage是存储系统,可以是一个普通file,也可以是HDFS,HIVE,HBase等。

E. 总结

根据这四个系统的架构设计,可以总结出典型的日志系统需具备三个基本组件,分别为agent(封装数据源,将数据源中的数据发送给collector),collector(接收多个agent的数据,并进行汇总后导入后端的store中),store(中央存储系统,应该具有可扩展性和可靠性,应该支持当前非常流行的HDFS)。
下面表格对比了这四个系统:

 

三.较为成熟的日志监控分析工具

1.ELKA.ELK 简介

ELK在服务器运维界应该是运用的非常成熟了,很多成熟的大型项目都使用ELK来作为前端日志监控、分析的工具。
前端日志与后端日志不同,具有很强的自定义特性,不像后端的接口日志、服务器日志格式比较固定,大部分成熟的后端框架都有非常完善的日志系统,借助一些分析框架,就可以实现日志的监控与分析,这也是运维工作的一部分。
ELK实际上是三个工具的集合:

  • E:Elasticsearch (弹性搜索)
  • L:Logstash
  • K:Kibana

这三个工具(框架)各司其职,最终形成一整套的监控架构。

Elasticsearch

ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎,基于RESTful web接口。Elasticsearch是用Java开发的,并作为Apache许可条款下的开放源码发布,是当前流行的企业级搜索引擎。设计用于云计算中,能够达到实时搜索,稳定,可靠,快速,安装使用方便。

我们使用Elasticsearch来完成日志的检索、分析工作。

Logstash

Logstash是一个用于管理日志和事件的工具,可以用它去收集日志、转换日志、解析日志并将它们作为数据提供给其它模块调用,例如搜索、存储等。

我们使用Logstash来完成日志的解析、存储工作。

Kibana

Kibana是一个优秀的前端日志展示框架,它可以非常详细的将日志转化为各种图表,为用户提供强大的数据可视化支持。
我们使用Kibana来进行日志数据的展示工作。

2.ELK使用场景

现在已经有非常多的公司在使用这套架构了,例如Sina、饿了么、携程,这些公司都是这方面的先驱。同时,这套东西虽然是后端的,但是『他山之石,可以攻玉』,我们将这套架构借用到前端,可以使用前端日志的分析工作,同样是非常方便的。这里我举一些常用的使用场景。

  • 业务数据分析

通过客户端的数据采集系统,可以将一些业务流程的关键步骤、信息采集到后端,进行业务流程的分析。

  • 错误日志分析

类似Bugly,将错误日志上报后,可以在后端进行错误汇总、分类展示,进行错误日志的分析。

  • 数据预警

利用ELK,可以很方便的对监控字段建立起预警机制,在错误大规模爆发前进行预警。

3.ELK的优势

a. 强大的搜索

这是elasticsearch的最强大的功能,它可以以分布式搜索的方式快速检索,而且支持DSL的语法来进行搜索,简单的说,就是通过类似配置的语言,快速筛选数据。

b. 强大的展示

这是Kibana的最强大的功能,它可以展示非常详细的图表信息,而且可以定制展示内容,将数据可视化发挥的淋漓尽致。
所以,借助ELK的这两大优势,我们可以让前端日志的分析与监控展现出强大的优势。

D.ELK的缺点:

  • 1、 三个独立的系统,没有统一的部署、管理工具,用户需要分别部署及管理这三套系统
  • 2、复杂业务下权限的分组管理,企业肯定希望每个业务部分看自身的,但又存在矛盾点,企业想看汇总情况。
  • 3、安全漏洞,之前乌云网站曾爆出Elasticsearch存在严重的安全漏洞。
  • 4、不进行深度开发的话,数据挖掘能力弱

4.EFK

市场上另外一个非常好的数据收集解决方案即是Fluentd,它也支持Elasticsearch作为数据收集的目的地。所以运用相同的数据存储和前端解决方案,便形成了EFK.许多人选择用Fluentd 代替logtash。

5. Logstash 与FluentD(Fluentd)对比

二者都有许多可用插件,被积极的维护着。

技术上:

  • Lostash:有良好的并行性支持,jvm有很好的Grok支持
  • FlentD:缺少支持windows 平台

传输上:两者同时提供 向一个非常必要的的选项,即向一个完全成熟的实例读送日志信息的 部署轻量级组件。

安装

特征和表现

本文引自作者: levycui

https://www.aboutyun.com/thread-29633-1-1.html

 

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 酷酷鲨 设计师:CSDN官方博客 返回首页