ELK简介

什么是ELK

ELK是ElasticSearch,LogStash以及Kibana三个产品的首字母缩写。是可以和商业产品 Splunk 相媲美开源项目。

2013 年,Logstash 被 Elasticsearch 公司收购,ELK stack 正式成为官方用语。Elasticsearch是近两年最受关注的大数据项目之一,三次融资已经超过一亿美元。

ElasticSearch是一个基于全文检索引擎lucene实现的一个面向文档的schema free的数据库。所有对数据库的配置、监控及操作都通过Restful接口完成。数据格式为json。默认支持节点自动发现,数据自动复制,自动分布扩展,自动负载均衡。适合处理最大千万级别的数据的检索。处理效率非常高。可以理解为elasticSearch是一个在lucene基础上增加了restful接口及分布式技术的整合。

Logstash是一个对文件日志或者syslog日志以及其他各种类型的输入数据流进行解码,过滤,转换并转换为其他类型的数据流的软件,最常见的用法是将系统日志分析,结构化处理后倒入到ElasticSearch中。当然logstash也可以独立的完成很多日志/事件处理的工作,并不是必须要和ElasticSearch配合使用。

Kibana是一个通过Restful接口对ElasticSearch数据库进行检索,通过HTML5形式以柱状图,饼图,线图,地理位置分布图以及表格等形式展示数据的软件。

这三者结合在一起能实现将海量的日志进行分析处理,并最终以丰富图表的形式进行展现。这三个软件虽然经常在一起使用,但是也可以分别单独工作。

实际使用中logstash相对于fluentd几乎完败,其所有的有点fluentd都具备。而且随着libbeat的发展,很多情况下消息都不需要经过logstash转换。所以对于logstash的使用可以简化和慎重考虑。可能的话应该考虑使用fluentd代替。

如果存在更大的数据量,例如大于千万级,ELK可以和Hadoop进行整合,实现对更大数据量的支持。

ELK一直在进行改进,除了上述的对日志的处理,通过使用libbeat的go语言架构还能类似top命令的图形显示以及通过网络流量分析实现应用,例如mysql,http的图形显示。

ELK对我们实际工作的意义

通过ELK我们可以实现以下目的:

l. 海量数据的分析及展示:目前正在进行的数据分析系统就存在原始数据非结构化,数据量大,展示角度多样等特点就非常适合ELK。

2. 文档检索系统:对于海量文档的全文检索及管理系统,非常适合。

3. 实时监控系统:对于大量监控指标,需要实时监控,对界面美观有要求的业务监控系统来说,也非常适合ELK。例如和ganglia的整合。而且有些展示方式是仙人掌不可能实现的,例如饼图,地理位置图,表格等!通过topbeat和packagebeat可以直接实现操作系统以及应用的监控。

4. 集中日志系统:虽然我们使用了syslog-ng来实现集中日志处理,但是存在数据丢失以及不便于检索的问题。对于复杂的应用,不同类型的日志分布在不同的服务器上,对于业务流程分析过程来说,通过ELK可以将各种日志整合在一起,集中分析。便于发现问题之间的关联关系。

ElasticSearch名词解释

Index:存储数据的逻辑区域,类似关系型数据库中的database,是文档的命名空间。如下图的湖蓝色部分所示,Index为twitter。

Type:类似关系型数据库中的Table,是包含一系列field的json数据。储存一系列类似的field。如下图的黄色部分所示,Type为tweet。不同document里面同名的field一定要是相同类型的。

Document:存储的实体数据,类似关系型数据库中的Row,是具体的包含一组filed的资料。如下图橙色部分所示,包含user,post_data,message三个field。

Field:即关系型数据库中Column, Document的一个组成部分,有两个部分组成,name和value。如下图紫色部分所示 post_date及其具体的值就是一个field。

Mapping:存储field的相关映射信息,不同document type会有不同的mapping。

Term:不可分割的单词,搜索最小单元。不同的分析器对同样的内容的分析结果是不同的。也就得到不同的term。

Token:一个Term呈现方式,包含这个Term的内容,在文档中的起始位置,以及类型。

Node:对应这关系型数据库中的数据库实例。

Cluster:由多个node组成的一组服务实例。

Shard:关系型数据库中无此概念,是Lucene搜索的最小单元。一个index可能会存在于多个shards,不同shards可能在不同nodes。一个lucene index在es中我们称为一个shard,而es中的index则是一系列shard。当es执行search操作,会将请求发送到这个index包含的所有shard上去,然后将没一个shard上的执行结果搜集起来作为最终的结果。shard的个数在创建索引之后不能改变!

Replica:shard的备份,有一个primary shard,其余的叫做replica shards。Elasticsearch采用的是Push Replication模式,当你往 master主分片上面索引一个文档,该分片会复制该文档(document)到剩下的所有 replica副本分片中,这些分片也会索引这个文档

文档的录入时,Elasticsearch通过对docid进行hash来确定其放在哪个shard上面,然后在shard上面进行索引存储。

当进行查询时,如果提供了查询的DocID,Elasticsearch通过hash就知道Doc存在哪个shard上面,再通过routing table查询就知道再哪个node上面,让后去node上面去取就好了。如果不提供DocID,那么Elasticsearch会在该Index(indics)shards所在的所有node上执行搜索,然后返回搜索结果,由coordinating node gather之后返回给用户。每个node都可以接收请求,会自动判断是否可以本地处理还是需要其他node协助处理。

Logstash简介

Logstash是用jruby编写的一个收集,分析,处理日志或事件的软件。

每位系统管理员都肯定写过很多类似这样的命令:cat randdata | awk '{print $2}' | sort | uniq -c | tee sortdata。这个管道符 | 可以算是 Linux 世界最伟大的发明之一(另一个是“一切皆文件”)。

Logstash 就像管道符一样!你输入(就像命令行的 cat )数据,然后处理过滤(就像 awk 或者 uniq 之类)数据,最后输出(就像 tee )到其他地方。

Logstash 不只是一个input | filter | output 的数据流,而是一个 input | decode | filter | encode | output 的数据流!codec 就是用来 decode、encode 数据的。

codec 的引入,使得 logstash 可以更好的与其他有自定义数据格式的运维产品共存,比如 ganglia、graphite、fluent、netflow、collectd,以及使用 msgpack、json、edn 等通用数据格式的其他产品等。

丰富的插件,让logstash可以方便的与各种系统进行整合。

Logstash的配置文件是通过一系列的input{},filter{},以及output{}区块,以及if等条件判断语句组成的。每个区块中都应该根据需要配置不同的插件。

Logstash的配置文件可以包含在多个文件中,一般位于/etc/logstash/conf.d目录下,文件名应该以.conf为扩展名。每个文件都可以是某个类型日志处理的完整过程或者一个片段。

具体如何配置,应该参考最新的官方文档,https://www.elastic.co/guide/en/logstash/current/index.html,所以请确认不要参考早期文档。

上一篇:angularjs 路由机制


下一篇:win32 htmlayout点击按钮创建新窗口,以及按钮图片样式