日志分析系统调研分析-ELK-EFK
日志分析系统
目录
一. 背景介绍 (3)
二．日志系统比较 (3)
1．怎样收集系统日志并进行分析 (3)
A.实时模式： (3)
B.准实时模式 (3)
2.常见的开源日志系统的比较 (4)
A. FaceBook的Scribe (4)
B. Apache的Chukwa (4)
C. LinkedIn的Kafka (5)
E. 总结 (9)
三．较为成熟的日志监控分析工具 (9)
1.ELK (10)
A.ELK 简介 (10)
B.ELK使用场景 (11)
C.ELK的优势 (12)
D.ELK的缺点： (12)
2.EFK (13)
3. Logstash 于FluentD(Fluentd)对比 (13)
一. 背景介绍
许多公司的平台每天会产生大量的日志（一般为流式数据，如，搜索引擎的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）。
Scribe Chukwa Kafka Flume
公司Facebook Apache/yahoo LinkedIn Cloudera
开源时间2008/10 2009/11 2010/12 2009/7
实现语言C/C++ JAVA SCALA JAVA
框架Push/push Push/push Push/pull Push/push
容错性Collector
和store之
间有容错机
制，而agent
和
collector
之间的容错
需要客户自
己实现Agent定期记录
已发送给
collector 的
数据偏移量，一
旦出现故障后，
可根据漂移量
继续发送数据
Agent可用通过
collector自动识
别机制获取可用
的collector，
store 自己保存
以获取的数据的
偏移量，一旦
collector出故障
后，可根据偏移量
获取数据
Agent和
collector，
collector和
store之间均
有容错机制，
且提供了三种
级别的可靠保
证
负载均衡无无使用zookeeper 使用
zookeeper 可扩张性好好好好
Agent Thrift
client，需
要自己实现自带一些
agent，如获取
hadoop log的
agent
用户需根据Kafka
提供的low-level
和high-level API
自行实现
提供了各种非
常丰富的
agent
Collector 实际上是一
个thrift
server -- 使用了sendfile，
zero-copy等技术
提高性能
系统提供了很
多collector，
直接可以使用
Store 直接支持
HDFS
直接支持HDFS 直接支持HDFS 直接支持HDFS
总体评价设计简单，
易于使用，
但容错和负
载均衡方面
不够好，且
资料较少属于hadoop系
列产品，直接支
持hadoop，目前
版本升级较快，
但还有待完善
设计构架
（push/pull）非
常巧妙，适合异构
集群，但产品叫
新，其稳定性有待
验证
非常优秀
三．较为成熟的日志监控分析工具
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 平台
传输上： 两者同时提供 向一个非常必要的的选项，即向一个完全成熟的实例读送日志信息的 部署轻量级组件。
Fluentd
Logstash 安装过程 Repository
(apt/yum) or
Compressed
Archive
占磁盘大小 165.3M
154.9M 难易程度
简单 简单 支持平台 Linux
Mac OS X
Windows
Linux Mac OS X 需求
-- JVM 技术
CRuby JRuby
特征和表现
Fluentd Logstash
输入路由 Tagging Better for complex routing Algorithmic
Statements
Better
for Structural or
Procedural
Programming
数据传输 Uses a Buffering System that is highly
configurable.
Could
be both in-memory or on-disk No
built-in persistent message queue. So for persistence relies on a third-party messaging queue like Redis
or Zeromq. Checkout
this github issue.
可用传输协议 Active-Standby
(Where logs are sent to secondary server in case primary fails)
Active-Active
(Where logs are
sent to multiple
destinations via
load-balancing
and/or weighted Active-Standby (Where logs are
sent to secondary server in case primary fails)
load-balancing)
Require
Acknowledgement
(Where logs are
re-transmitted
until a receipt or
acknowledment is
not received back.
This may affect
the performance
though.)
配置Simple Complex
可扩扩张性Support
extensibility via
plugins.
Plugins List
Support
extensibility via
plugins.
Plugins Repository
内存消耗
(平均)
20 – 40MB100 – 130MB
日志分析系统 目录 一. 背景介绍 (2) 二．日志系统比较 (2) 1．怎样收集系统日志并进行分析 (2) A.实时模式： (2) B.准实时模式 (2) 2.常见的开源日志系统的比较 (3) A. FaceBook的Scribe (3) B. Apache的Chukwa (3) C. LinkedIn的Kafka (4) E. 总结 (8) 三．较为成熟的日志监控分析工具 (8) 1.ELK (9) A.ELK 简介 (9) B.ELK使用场景 (10) C.ELK的优势 (10) D.ELK的缺点： (11) 2.EFK (11) 3. Logstash 于FluentD(Fluentd)对比 (11)
一. 背景介绍 许多公司的平台每天会产生大量的日志（一般为流式数据，如，搜索引擎的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来帮助简化
Web日志集中管理系统的研究与实现 吴海燕朱靖君程志锐戚丽 （清华大学计算机与信息管理中心，北京100084） E-mail：wuhy@https://www.doczj.com/doc/b51974593.html, 摘要： Web服务是目前互联网的第一大网络服务，Web日志的分析对站点的安全管理与运行维护非常重要。在实际运行中，由于应用部署的分散性和负载均衡策略的使用，使得Web日志被分散在多台服务器上，给日志的管理和分析带来不便。本文设计并实现了一个Web日志集中管理系统（命名为ThuLog），系统包括日志集中、日志存储和日志分析三个模块。目前，该系统已经在清华大学的多个关键Web应用系统上进行了应用，能够帮助系统管理员清晰地了解系统运行情况，取得了较好的运行效果。 关键词：Web日志日志分析日志集中管理系统 The Research and Implementation of a Centralized Web Log Management System Wu Haiyan Zhu Jingjun Cheng Zhirui Qi Li (Computer&Information Center,Tsinghua University,Beijing100084) Abstract：Web is now the biggest network service on the Internet.The analysis of Web logs plays an important role in the security management and the maintenance of a website.But because of the decentralization of deployment and the use of load balancing,Web logs are often seperated on each Web server,which makes the management and analysis of them not so convenient.This paper designs and implements a Web Log Centralized Management System(named ThuLog),which includes3modules:the centralization of logs,the storage of logs and the analysis of logs.Through log analysis of several critical Web systems in Tsinghua University,it could help system administrators learn clearly what happens in information systems and achieves good operating results. Key words：Web Logs Log Analysis Web Log Centralized Management System 1.引言 近年来，随着计算机网络技术的迅速发展，Web正以其广泛性、交互性、快
技术参数：日志实时监视：系统提供实时的日志滚动显示和查询，可自定义实时监视的日志内容，可查看实时日志详细信息；统一监控主页：系统应提供从总体上把握日志告警和日志统计分析的实时综合性监控界面。界面由多个监控组件组成，用户可以自定义监控主页；生产厂商：北京启明星辰信息安全技术有限公司；日志关联分析告警：系统支持异常行为分析，维护一个与用户信息 系统相关的合法账号的正常行为集合，以此区分入侵者的行为和合法用户的异常行为；系统应至少默认有50条告警规则，系统提供可视化规则编辑器，对告警规则进行增删改查。系统内置针对服务器和其他安全设备的访问ip地址、访问账户和访问时间的访问控制规则；告警规则可按照树型结构组织，并可在该树型结构上直接查看该规则的告警信息，对告警日志可按各告警字 段进行分组排序。可对不同类型设备的日志之间进行关联分析，支持递归关联，统计关联，时序关联，这几种关联方式能同时应用于一个关联分析规则；日志审计查询：所有日志采用统一的日志查询界面，用户可以自定义各种查询场景。查询场景可保存，并可支持在查询结果中继续查询。支持原始消息中的关键字查询，可进行全文检索，可对查询结果进行分组排序，查询结 果可导出；二次开发接口：支持二次开发功能；型号：TSOC-SA-SW-SC；趋势分析：可对收集的日志根据过滤条件，针对设备地址、源地址、目标地址等进行事件数量等的趋势分析；支持端口监控：支持对服务器开启的无用端口、短时间使用不同的口令多次尝试连接服务器的审计；告警和响应管理：通过关联分析，对于发现的严重事件可以进行自动告警，告警内容支持 用户自定义字段。告警方式包括邮件、短信、SNMP Trap、Syslog等。响应方式包括：自动执行预定义脚本，自动将事件属性作为参数传递给特定命令行程序；移动存储介质使用痕迹审计：应能够对受控主机使用过的移动存储介质进行常规审计；应能够将受控主机删除后的移动存储介质使用痕迹进行深度审计；备份归档：支持数据库备份归档；支持历史日志恢复导入；支 持各种配置项的备份和导入；报表管理：提供丰富的报表管理功能，预定义了针对各类服务器、网络设备、防火墙、入侵检测系统、防病毒系统、终端安全管理系统、数据库、策略变更、流量，设备事件趋势以及总体报表，根据时间、数据类型等生成报表，提供导出以及邮件送达等服务；直观地为管理员提供决策和分析的数据基础，帮助管理员掌握网络及业务系统的状况。 报表可以保存为html、excel、pdf等多种格式。提供自定义报表，用户可根据自身需要进行定制。报表可根据设置自动运行,调度生成日报、周报和月报；日志实时分析和统计：可对收集的日志进行分类实时分析和统计，从而快速识别安全事故。分析统计结果支持柱图、饼图、曲线图等形式并自动实时刷新，图表数据支持数据下钻。日志实时图表数据支持数据下钻。日志实时分析在内存中完成，不需借助数据库和文件系统；告警查询：支持显示所有和按规则树结果分别显示告警事件信息，对告警查询结果字段可以分别二次排序显示；采集方式：审计中心可通过syslog、snmptrap、jdbc/odbc、agent等多种方式完成日志收集功能；告警：支持告警，告警动作支持多种常规告警方式；支持主机状态监控与审计：应能审计账户快照、操作系统版 本、主机名称、内存容量、硬盘容量、CPU信息等；售后服务内容：1、为最终用户提供技术服务热线。2、提供3年的产品授权和原厂服务，原厂服务为与产品出厂市场服务标准一致的原厂服务。3、提供5*8小时技术支持服务。4、提供如下 故障保修服务：两小时电话响应，两个工作日解决问题。对于未能解决的问题和故障应提供可行的升级方案等。5、发生非人为因素故障，在七日内免费对产品进行补充或者更换。；核心功能：对日志进行归一、汇总、分析将海量安全日志转化为少量安全事件；采集器：日志采集前置可以分布式部署，以降低网络传输、分散负载，可以在需要时增设新的日志采集前置，从而 提高系统的伸缩性；支持异常监控审计：主要审计终端电脑上对CPU占有率、内存占有率和运行时间超过策略中设置值的信息，包括计算机账户、IP地址、MAC地址、事件类型、运行时间等信息；支持多操作系统：支持Windows、Linux等主流操作系统；供货要求：供货商按照客户约定的时间和地点提供相应的产品和服务，并完成现场交付和安全调试：（1）负责产品的安 装与现场调试服务（2）完成软件的安装与调试服务（3）负责提供安装与调试所需的相应工具和设备等（4）负责提供所需相关保护设备。(5)交付产品时应提供配套的技术资料，包括但不限于：系统说明文件、用户手册（安装、操作、维护、故障排除）等；支持文件操作痕迹检查：系统应能够对主机文件操作痕迹进行检查，操作行为应包括：编辑、保存、复制、粘贴等常规文件操作行为；日志关联分析：系统具有日志关联分析的能力，能够对不同的日志进行相关性分析，发掘潜在的信息；系统支持编写自定义关联规则；品牌：启明/QEEMEE；过滤归并：支持对无用日志的可设置过滤条件和归并规则；支持未授权操作信息：支持对未经授权卸载、删除、修改终端审计；应能够审计未经过授权删除终端安装目录文件的日志，包括计算机账户、IP地址 、MAC地址、时间类型、进程路径、文件路径等信息；管理权限分级分域：管理员分级分权，可以自行设置管理员权限和策略。如管理员、安全员、操作员、审计员等。；报表：提供报表功能，支持自定义生成报表；是否需要安装：需要；综合日志审计：采集日志，日志信息汇集到审计中心，通过统一的控制台界面进行实时、可视化的呈现分析，能对网络设备、安全设备和 系统、主机操作系统、数据库以及各种应用系统的日志、事件、告警等安全信息进行全面的审计；日志范式化：系统具备日志范式化功能，实现对异构日志格式的统一化；针对不支持的事件类型做范式化不需改动编码，通过修改配置文件即可完成；日志审计对象：包括主流网络设备、安全设备、安全系统、主机操作系统、数据库、应用系统、网管系统告警日志、终端管理系
Linux 系统日志收集分析系统 一、搭建环境 系统：centos6.5 软件：lamp、rsyslog、rsyslog-mysql 、loganalyzer rsyslog用来收集远程服务器系统日志信息 rsyslog-mysql是rsyslog连接数据库的模块 loganalyzer用来分析系统日志 二、软件安装 a、httpd安装 tar -jxvf apr-1.5.1.tar.bz2 ./configure --prefix=/usr/local/apr make && make install tar -zxvf apr-util-1.5.4.tar.gz ./configure --prefix=/usr/local/apr-util --with-apr=/usr/local/apr/ make && make install tar -zxvf httpd-2.4.12.tar.gz yum install -y pcre-devel zlib-devel openssl-devel ./configure --prefix=/data/program/apache2 --enable-so --enable-rewrite --enable-ssl --enable-cgi --enab le-cgid --enable-modules=most --enable-mods-shared=most --enable- mpms-share=all --with-apr=/usr/local/apr --with-apr-util=/usr/local/apr-util --enable-deflate make -j 6 && make install ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 修改httpd配置文件，添加如下两行 AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps 定位至DirectoryIndex index.htm DirectoryIndex index.php index.html 注释掉主服务的站点目录 #DocumentRoot "/data/program/apache2/htdocs" 开启虚拟主机需要加载 Include conf/extra/httpd-vhosts.conf LoadModule log_config_module modules/mod_log_config.so 添加虚拟主机
日志分析系统 1.前言 随着江苏中烟信息化程度的不断提升，信息化系统的数目也不断增加，运维任务也不断增加。为了应对日益增加的信息化需求，提升服务质量，减轻运维工作，在信息系统服务化的基础上，迫切需要一个管理平台，实现对所有服务的管理和监控，这就是微服务平台。微服务平台能够实现devOps，服务的注册、发现、权限管理、监控、测试、故障预警，故障恢复等。 日志分析系统是微服务平台的重要组成部分，它能够对各服务的日志进行采集，存储，分析(找出异常的请求、统计报错情况、统计QPS、统计系统功能的使用情况、超负荷预警等)。同时，对系统资源的监控信息也可以以日志的形式，由日志分析系统分析。日志分析系统后台使用大数据平台来存储和分析日志，能够支持大量的日志，不需要担心日志的存储问题。 2.日志分析系统 2.1.功能 日志分析系统主要功能包括日志的采集、存储、分析。 日志采集常见的场景如：对webserver服务器的log文件进行监控，发现有变动时，采集变动的信息；对网络的某个端口监控，当此端口出现数据流时，采集数据流；监控程序定时的获取系统资源信息(同理，也适用于对JVM，tomcat的监控)；采集Http请求和响应(同理适用于rpc远程调用)。 日志的存储使用大数据平台。根据日志的类型，可以以非结构化或者结构化数据存储，也可以使用图数据库存储。 日志分析包括日志的离线和在线分析。离线分析借助大数据平台提供的SQL，对日志数据库中的所有数据进行统计分析，适合于统计QPS，系统功能使用情况。在线分析(实时分析)处理即时产生的日志信息，适合于预警，异常请求的监控。 2.2.结构
3.实现 3.1.要求 ?能够适配不同的日志数据，例如web server log、rpc log、syslog ?能够处理突发的大流量数据 ?能够检测日志系统的个节点的运行状态，并自动恢复 ?能够方便的和Hive、Spark、Hbase等集成 ?稳定的运行，尽量少占用资源 3.2.日志收集和路由 logstash是一种分布式日志收集框架，非常简洁强大，经常与ElasticSearch，Kibana配置，组成著名的ELK技术栈，非常适合用来做日志数据的分析。Logstash分为Shipper（收集日志），Broker（日志集线器，可以连接多个Shipper），Indexer（日志存储）。Shipper 支持多种类型的日志文件，且可以自定义插件支持更多的种类。Logstash采用JRuby语言实现，插件开发相对困难。Logstash可以通过配置正则表达式的方式，将日志解析为结构化数
日志分析:千亿级数量下日志分析系统的技术架构选型 随着数据已经逐步成为一个公司宝贵的财富，大数据团队在公司往往会承担更加重要的角色。大数据团队往往要承担数据平台维护、数据产品开发、从数据产品中挖掘业务价值等重要的职责。所以对于很多大数据工程师，如何根据业务需求去选择合适的大数据组件，做合适的大数据架构工作就是日常工作中最常遇到的问题。在这里根据七牛云在日增千亿级的日志分析工作，和大家分享一下大数据技术架构选型的一些经验。 大数据架构师在关注什么 在一个大数据团队中，大数据架构师主要关注的核心问题就是技术架构选型问题。架构选型问题一般会受到哪些因素的影响呢？在我们的实践中，一般大数据领域架构选型最受以下几个因素影响： 数据量级 这一点在大数据领域尤其是一个重要的因素。不过从根本上讲，数据量级本身也是一种业务场景的衡量。数据量级的不同往往也就昭示着业务场景的不同。
业务需求 经验丰富的大数据架构师能够从纷繁的业务需求中提炼出核心技术点，根据抽象的技术点选择合适的技术架构。主要的业务需求可能包括：应用实时性要求、查询的维度和灵活程度、多租户、安全审计需求等等。 维护成本 这一点上大数据架构师一方面要能够清楚的了解各种大数据技术栈的优劣势，在满足业务需求的要求下，能够充分的优化架构，合理的架构能够降低维护的成本，提升开发的效率。 另一方面，大数据架构师要能清楚的了解自己团队成员，能了解其他同学的技术专长和品位，能够保证自己做的技术架构可以得到认可和理解，也能得到最好的维护和发展。 接下来我们会围绕这几个方面去看看，做一个最适合自己团队业务的架构选型会如何受到这些因素的影响？ 技术架构选型 业务需求是五花八门的，往往影响我们做技术选型的不是种种需求的细节，而是经过提炼后的一些具体的场景。就好比，业务需求提出我们要做一个日志分析系统，或者要做一个用户行为分析系统，这些具体需求背后我们要关注哪些具体的点？这是一个很有趣的问题，我们在做大数据的过程中，常发现我们对这些需求的疑问很多时候会落在以下几个问题上。 其中数据量级作为一个重要的因素影响着我们对于技术选型的决定，另外在数据量的变化之外各种业务场景的需要也会影响我们对技术组件的选择。 数据量级
点击文章中飘蓝词可直接进入官网查看 大数据日志分析系统 大数据时代，网络数据增长十分迅速。大数据日志分析系统是用来分析和审计系统及 事件日志的管理系统，能够对主机、服务器、网络设备、数据库以及各种应用服务系统等 产生的日志进行收集和细致分析，大数据日志分析系统帮助IT管理员从海量日志数据中准确查找关键有用的事件数据，准确定位网络故障并提前识别安全威胁。大数据日志分析系 统有着降低系统宕机时间、提升网络性能、保障企业网络安全的作用。 南京风城云码软件公司（简称：风城云码）南京风城云码软件技术有限公司是获得国 家工信部认定的“双软”企业，具有专业的软件开发与生产资质。多年来专业从事IT运维监控产品及大数据平台下网络安全审计产品研发。开发团队主要由留学归国软件开发人员 及管理专家领衔组成，聚集了一批软件专家、技术专家和行业专家，依托海外技术优势， 使开发的软件产品在技术创新及应用领域始终保持在领域上向前发展。 审计数据采集是整个系统的基础，为系统审计提供数据源和状态监测数据。对于用户 而言，采集日志面临的挑战就是：审计数据源分散、日志类型多样、日志量大。为此，系 统综合采用多种技术手段，充分适应用户实际网络环境的运行情况，采集用户网络中分散 在各个位置的各种厂商、各种类型的海量日志。 分析引擎对采集的原始数据按照不同的维度进行数据的分类，同时按照安全策略和行 为规则对数据进行分析。系统为用户在进行安全日志及事件的实时分析和历史分析的时候 提供了一种全新的分析体验——基于策略的安全事件分析过程。用户可以通过丰富的事件分析策略对的安全事件进行多视角、大跨度、细粒度的实时监测、统计分析、查询、调查、追溯、地图定位、可视化分析展示等。
第44卷 增刊厦门大学学报(自然科学版) Vo l.44 Sup. 2005年6月 Journal of Xiam en U niversity (Natural Science) Jun.2005 基于关联规则的日志分析系统的设计与实现 收稿日期:2005 01 21 基金项目:福建省自然基金项目(A0310008),福建省高新技术研究 开放计划重点项目(2003H 043),厦门大学中央行动计划院士基金项目(X01122)资助 作者简介:文娟(1982-),女,硕士研究生. 文 娟,薛永生,段江娇,王劲波 (厦门大学计算机科学系,福建厦门361005) 摘要:网上广告势必成为中国广告业不可取代的部分,广告人总是期望广告能获得最好的效果.为此,本文设计并实现了 一个基于关联规则数据挖掘的日志分析系统,数据挖掘引擎在实现过程中针对挖掘数据的特点对A prior i 算法进行了改进,并通过仿真数据库对挖掘结果进行了验证,日志分析系统获得的 知识 可以直接用于改善Web 的信息服务. 关键词:日志分析系统;数据挖掘;关联规则 中图分类号:T P 311 文献标识码:A 文章编号:0438 0479(2005)Sup 0258 04 数据挖掘技术在科学发现、商业应用、市场营销、金融投资等领域都有广阔的应用前景.目前,大型数据挖掘系统有Intelligent Miner,SPSS,DBM iner 等,国 内也有研究[1,2],但是,这些大型的数据挖掘系统功能布局相对不合理,并且价格昂贵,当实现某些行业的某些特定目的的数据挖掘时,没有突出的特色. 网上广告已经成为广告业中不可忽视的部分,这涉及如何从网站上丰富的数据中提取有效信息的问题.W eb 日志挖掘可以发现用户的浏览模式,用于改进Web 服务器的设计以方便用户使用和提高Web 服务器的性能,增加个性化服务和在电子商务中发现潜在的客户群等.目前用于Web 日志挖掘的关联规则算法有FP [3] ,Tv p [4] ,Apriori [5] 等.本文以邮政网络的日志分析为例,实现了基于Aprior i 算法的关联规则的分析系统,对网站日志进行挖掘分析,得到网页组相应的最大频繁项集,即商家决策者所感兴趣的 黄金网页组合 ,据此改善Web 的信息服务,有效地提高网站的效益,同时在实现过程中针对挖掘数据的特点对Apri o ri 算法做了一些改进,并通过仿真数据库对挖掘结果进行了验证. 1 日志分析系统的基本模块 本文基于关联规则的日志分析系统是专门为邮政部门优化网络系统开发的.该系统分为数据预处理,数据挖掘和知识转化3个模块.数据预处理模块将原始日志文件先导入数据库管理系统SQL Ser ver 2000 中,然后数据过滤得到用户会话文件,即数据库的表,最后生成布尔型事务数据库,事务数据存于文本文件中;数据挖掘引擎采用关联规则中的经典算法Apriori 算法实现,并针对挖掘数据的特点对Apiro ri 算法进行了改进;知识转化模块将挖掘得到最大频繁项集及相关信息转化成知识,生成强关联规则,网站设计者可根据这些强关联规则改善信息服务.整个系统的模块结构如图1所示. 图1 日志分析系统的模块结构 F ig.1 M odule structur e of W eblog analysis system 2 日志分析系统的具体实现 2.1 数据预处理 数据预处理一般根据具体源数据的数据要求进行再加工,如检查数据的完整性及数据的一致性,对丢失的数据进行填补,消除 脏 数据等.常见的预处理方法有:数据清理、数据集成、数据变换和数据归约.该系统的数据预处理不仅面临数据清理问题,还需要将数据转化成数据挖掘引擎需要的数据形式,即如何将源数据转换成事务数据库的问题,所以,预处理分为数据导入,数据清理和生成布尔型事务数据库三步来实现.2.1.1数据导入和清理 挖掘的原始日志数据如下,且保存在文本文档中.
用Kibana和logstash快速搭建实时日志查询、收集与分析系统 Logstash是一个完全开源的工具，他可以对你的日志进行收集、分析，并将其存储供以后使用（如，搜索），您可以使用它。说到搜索，logstash带有一个web界面，搜索和展示所有日志。 kibana 也是一个开源和免费的工具，他可以帮助您汇总、分析和搜索重要数据日志并提供友好的web界面。他可以为 Logstash 和 ElasticSearch 提供的日志分析的 Web 界面 说到这里，我们看看 kibana 和 logstash到底能为我们做些什么呢？下面是kibana的界面 简单来讲他具体的工作流程就是 logstash agent 监控并过滤日志，将过滤后的日志内容发给redis(这里的redis只处理队列不做存储)，logstash index将日志收集在一起交给
全文搜索服务ElasticSearch 可以用ElasticSearch进行自定义搜索通过Kibana来结合自定义搜索进行页面展示，下图是 Kibana官网上的流程图 好了让我们一步步的把这套环境搭建起来吧，先看看都需要安装什么软件包 ruby 运行Kibana 必须， rubygems 安装ruby扩展必须 bundler 功能类似于yum JDK 运行java程序必须 redis 用来处理日志队列 logstash 收集、过滤日志
ElasticSearch 全文搜索服务(logstash集成了一个) kibana 页面展示 这里有三台服务器 192.168.233.128 logstash index，ElasticSearch，kibana，JDK 192.168.233.129 logstash agent，JDK 192.168.233.130 redis 首先到 logstash index服务器上面，logstash分为 index和aget ，agent负责监控、过滤日志，index负责收集日志并将日志交给ElasticSearch 做搜索 此外 logstash 的收集方式分为 standalone 和 centralized。 standalone 是所有功能都在一个服务器上面，自发自收，centralized 就是集中收集，一台服务器接收所有shipper(个人理解就是logstash agent)的日志。 其实 logstash本身不分什么 shipper 和 collector ，只不过就是配置文件不同而已，我们这次按照集中的方式来测试 在 logstash index上安装基础的软件环境 1.[19 2.168.23 3.128 root@nodec:~] 2.# cd /soft/ 3.[192.168.233.128 root@nodec:/soft] 4.# wget https://www.doczj.com/doc/b51974593.html,/distfiles/jdk-6u13-dlj-linux-i586. bin 5.从oracle下载实在是太慢了，从CU下载会快一些，如果需要最新版本请访问这里 6.https://www.doczj.com/doc/b51974593.html,/technetwork/java/javase/downloads/jdk7-downloa ds-1880260.html 7.[192.168.233.128 root@nodec:/soft] 8.# sh jdk-6u13-dlj-linux-i586.bin
题目：基于C#的服务器日志分析系统 的设计与实现 学院：计算机科学与工程学院专业：计算机科学与技术 班级：2013级1班 姓名：樊慧波 学号：20131303040 指导教师：祁瑞丽 2017 年 4 月27 日
毕业作品基本信息
摘要 随科技发展，越来越多的科技型企业都需要对数据中心已老化的服务器进行 更换，也就是我们所说的数据中心IDC迁移。而一众的老牌服务器厂商（HUAWEI、IBM、CISICO、DELL、HP、Lenovo、H3C等）均对此提供一定的 技术支持，为客户提供相应的技术服务方案。然而，国内大多企业数据中心往往 不会单一采用某一家公司的产品，而各大厂商单一服务成本昂贵。为解决此现状，第三方服务运维应运而生。 2016年7月始，实习于神州数码系统集成服务有限公司，该公司旗下品牌 《锐行服务》作为国内最大的第三方维护商，为众多公司服务器运维提供复杂的 技术解决方案。实习期间，在国家税务总局、中国外运长航集团的数据中心迁移 中参与完成3000余台设备迁移。 在服务器主机系统迁移中，主要由p2v、v2p两项构成。其中，必须先对服务 器信息进行调研，才能够进行迁移方案的规划。在此过程中，任何一项信息调研 出错都有可能导致迁移不成功。面对两千余台服务器，单一服务器信息调研数量 20余条的巨大工作量，我们花费了大量的时间以及人力完成此工作，而调研自动 化便成为我们工作中的迫切需求。 为提高工作效率，简化工作流程，结合所学知识，针对调研关键环节日志信 息读取设计并开发此Log日志分析系统。该系统主要采用基于面向对象的C#开发，能够对log日志进行批量读取、分析，并能按需提取有效信息进行分析、统计，并生成直观、简洁、可进行格式调整的Excel文档。 【关键词】服务器系统日志日志分析调研自动化
日志分析系统调研分析-ELK-EFK
日志分析系统 目录 一. 背景介绍 (3) 二．日志系统比较 (3) 1．怎样收集系统日志并进行分析 (3) A.实时模式： (3) B.准实时模式 (3) 2.常见的开源日志系统的比较 (4) A. FaceBook的Scribe (4) B. Apache的Chukwa (4) C. LinkedIn的Kafka (5) E. 总结 (9) 三．较为成熟的日志监控分析工具 (9) 1.ELK (10) A.ELK 简介 (10) B.ELK使用场景 (11) C.ELK的优势 (12) D.ELK的缺点： (12) 2.EFK (13) 3. Logstash 于FluentD(Fluentd)对比 (13)
一. 背景介绍 许多公司的平台每天会产生大量的日志（一般为流式数据，如，搜索引擎的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来帮助简化
点击文章中飘蓝词可直接进入官网查看 日志收集与分析系统 安全日志就是计算机系统、设备、软件等在某种情况下记录的信息。日志收集与分析 是其中比较重要的环节，事前及时预警发现故障，事后提供详实的数据用于追查定位问题，下面给大家介绍一下日志收集与分析系统中关于日志审计数据收集，日志分析，审计管理 平台等相关内容。并谈一谈日志收集与分析系统哪家好？ 南京风城云码软件技术有限公司是获得国家工信部认定的“双软”企业，具有专业的 软件开发与生产资质。多年来专业从事IT运维监控产品及大数据平台下网络安全审计产品研发。开发团队主要由留学归国软件开发人员及管理专家领衔组成，聚集了一批软件专家、技术专家和行业专家，依托海外技术优势，使开发的软件产品在技术创新及应用领域始终 保持在领域上向前发展。 目前公司软件研发部门绝大部分为大学本科及以上学历；团队中拥有系统架构师、软 件工程师、中级软件工程师、专业测试人员；服务项目覆盖用户需求分析、系统设计、代码开发、测试、系统实施、人员培训、运维整个信息化过程，并具有多个项目并行开发的 能力。 日志收集与分析系统通过高性能的日志收集引擎，实时自动化收集日志，解决手工处 理的低效率问题。收集到的所有日志均统一加密存储管理，可根据存储空间情况灵活扩展 存储位置。支持常见操作系统、应用系统、数据库、网络设备、安全设备等类型的日志收集，对于客户网络中特定的日志类型，支持定制扩展收集分析脚本，不再忧心类型复杂问题。可将不同系统和设备日志授权给指定人员进行管理，管理人员各司其职，负责自身所 管辖的系统或设备日志的审计管理，互不干涉、互不影响，使日志审计工作更加清晰、易 操作。 实时收集应用程序的日志信息，进行实时的统计和数据过滤。 实时显示应用程序中业务功能的动态性能视图，提供阀值报警。
日志分析系统 目录
一. 背景介绍 许多公司的平台每天会产生大量的日志（一般为流式数据，如，搜索引擎的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中）。
日志分析平台建设方案 目录 一、现状和需求 (2) （一）现状与问题 (2) （二）需求说明与分析 (2) 二、建设目标 (2) 三、系统设计 (2) （一）技术选型 (2) （二）系统架构 (2) 1. 架构图 (3) 2. 架构分析 (3) （三）系统介绍 (3) 四、实施方案 (4) （一）系统配置 (4) 1. 软件 (4) 2. 硬件 (4) （二）系统搭建 (4)
一、现状和需求 （一）现状与问题 1. 日志文件分散在各个应用服务器，开发人员必须远程登录才能查看日志，不利于 服务器安全管控，加大生产服务器的风险； 2. 服务器上各项目日志配置很随意，文件分布杂乱，没有统一的规范和管理； 3. 日志文件占用服务器大量的硬盘空间，如不及时清理会发生硬盘占满，影响系统的正常运行； 4. 对于超过百兆的日志文件根本没法打开和关键字搜索，不利于问题的快速定位和 排查； 5. 集群和分布式的系统需要查看多个服务器的日志 6. 日志保存的时间不统一，不能长时间保存日志 （二）需求说明与分析 1. 不需要开发人员登录生产服务器就能查看日志； 2. 统一规范日志的配置和输出格式； 3. 实时的将日志文件从服务器中迁出； 4. 提供日志的检索和统计分析的平台； 二、建设目标 搭建支持高并发高可靠的日志分析平台，方便开发人员快速的检索日志，排查问题，同时提供友好的分析和统计的界面。 三、系统设计 （一）技术选型 针对这些问题，为了提供分布式的实时日志搜集和分析的监控系统，我们采用了业界通用的日志数据管理解决方案-它主要包括 Elasticsearch、 Logstash和Kibana 三个系统。通常，业界把这套方案简称为ELK,取三个系统的首字母。调研了ELK技术 栈，发现新一代的 logstash-forward 即 Filebeat，使用了 golang，性能超 logstash，部署简单，占用资源少，可以很方便的和logstash和ES对接，作为日志文件采集组件。 所以决定使用ELK+Filebeat的架构进行平台搭建。 为了支持日志的高并发和高可靠需要进了消息队列（MQ），这里选择了 kafka，相对其他消息中间件，kafka有支持大并发，快速持久化等优点，而且ELK+Filebeat对kafka 的兼容性也很好。 最终，我们采用 Elasticsearch+ Logstash+ Kiba na+ Filebeat+ Kafka+ Zookeeper 的架 构搭建日志分析平台。