一文入门日志分析系统搭建

问题导读：
1、怎样收集系统日志并进行分析？
2、常见的开源日志系统有哪些？
3、如何选择常用成熟的日志监控分析工具？
4、Logstash 与FluentD(Fluentd)有哪些不同？


目录
一. 背景介绍

二．日志系统比较
1．怎样收集系统日志并进行分析
A.实时模式：
B.准实时模式

2.常见的开源日志系统的比较
A. FaceBook的Scribe
B. Apache的Chukwa
C. LinkedIn的Kafka
E. 总结

三．较为成熟的日志监控分析工具
1.ELK
A.ELK 简介
B.ELK使用场景
C.ELK的优势
D.ELK的缺点：

2.EFK
3. 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.ELK
A.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来进行日志数据的展示工作。

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

• 业务数据分析
  

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

• 错误日志分析
  

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

• 数据预警
  

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

C.ELK的优势
a. 强大的搜索
这是elasticsearch的最强大的功能，他可以以分布式搜索的方式快速检索，而且支持DSL的语法来进行搜索，简单的说，就是通过类似配置的语言，快速筛选数据。
b. 强大的展示
这是Kibana的最强大的功能，他可以展示非常详细的图表信息，而且可以定制展示内容，将数据可视化发挥的淋漓尽致。
所以，借助ELK的这两大优势，我们可以让前端日志的分析与监控展现出强大的优势。
D.ELK的缺点：
1、 三个独立的系统，没有统一的部署、管理工具，用户需要分别部署及管理这三套系统
2、复杂业务下权限的分组管理，企业肯定希望每个业务部分看自身的，但又存在矛盾点，企业想看汇总情况。
3、安全漏洞，之前乌云网站曾爆出Elasticsearch存在严重的安全漏洞。
4、不进行深度开发的话，数据挖掘能力弱

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



3. Logstash 于FluentD(Fluentd)对比
二者都有许多可用插件，被积极的维护着。
技术上：
Lostash： 有良好的并行性支持，jvm有很好的Grok支持
FlentD： 缺少支持windows 平台
传输上： 两者同时提供 向一个非常必要的的选项，即向一个完全成熟的实例读送日志信息的 部署轻量级组件。


安装



特征和表现

多谢分享~