一、ELK简介
ELK Stack是软件集合Elasticsearch、Logstash、Kibana的简称，由这三个软件及其相关的组件可以打造大规模日志实时处理系统。
Elasticsearch 是一个基于 Lucene 的、支持全文索引的分布式存储和索引引擎，主要负责将日志索引并存储起来，方便业务方检索查询。
Logstash是一个日志收集、过滤、转发的中间件，主要负责将各条业务线的各类日志统一收集、过滤后，转发给 Elasticsearch 进行下一步处理。
Kibana是一个可视化工具，主要负责查询 Elasticsearch 的数据并以可视化的方式展现给业务方，比如各类饼图、直方图、区域图等。
所谓“大规模”，指的是 ELK Stack 组成的系统以一种水平扩展的方式支持每天收集、过滤、索引和存储TB规模以上的各类日志。通常，各类文本形式的日志都在处理范围，包括但不限于 Web 访问日志，如 Nginx/Apache Access Log 。
基于对日志的实时分析，可以随时掌握服务的运行状况、统计 PV/UV、发现异常流量、分析用户行为、查看热门站内搜索关键词等。
二、ELK架构分析及应用场景
架构一：
首先由Logstash分布于各个节点上搜集相关日志、数据，并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。Elasticsearch将数据以分片的形式压缩存储并提供多种API供用户查询，操作。用户也可以更直观的通过配置Kibana Web Portal方便的对日志查询，并根据数据生成报表。
优点：搭建简单，易于上手。
缺点：logstash消耗资源大，运行占用cpu和内存高，另外没有消息队列缓存，存在数据丢失隐患。
应用场景：适合小规模集群使用。
ELK架构介绍：http://blog.sina.com.cn/s/blog_87113ac20102wasl.html
架构二：
第二种架构引入了消息队列机制，位于各个节点上的Logstash Agent先将数据/日志传递给Kafka（或者Redis），并将队列中消息或数据间接传递给Logstash，Logstash过滤、分析后将数据传递给Elasticsearch存储。最后由Kibana将日志和数据呈现给用户。因为引入了Kafka（或者Redis）,所以即使远端Logstash server因故障停止运行，数据将会先被存储下来，从而避免数据丢失
优点：引入了消息队列机制，均衡了网络传输，从而降低了网络闭塞尤其是丢失数据的可能性。
缺点：依然存在Logstash占用系统资源过多的问题。
应用场景：适合较大集群方案。
ELK架构介绍：http://blog.csdn.net/wenlixing110/article/details/56277603
架构三：
第三种架构引入了Logstash-forwarder。首先，Logstash-forwarder将日志数据搜集并统一发送给主节点上的Logstash，Logstash分析、过滤日志数据后发送至Elasticsearch存储，并由Kibana最终将数据呈现给用户。
优点：
1、解决了logstash占用系统资源较高的问题。
2、Logstash-forwarder和Logstash间的通信是通过SSL加密传输，起到了安全保障。
小结：如果是较大集群，用户亦可以如结构三那样配置logstash集群和Elasticsearch集群，引入High Available机制，提高数据传输和存储安全。更主要的配置多个Elasticsearch服务，有助于搜索和数据存储效率。
缺点：Logstash-forwarder和Logstash间通信必须由SSL加密传输，这样便有了一定的限制性。
应用场景：适合较大集群。
架构四：
第四种架构将Logstash-forwarder替换为Beats。经测试，Beats满负荷状态所耗系统资源和Logstash-forwarder相当，但其扩展性和灵活性有很大提高。Beats platform目前包含有Packagebeat、Topbeat和Filebeat三个产品，均为Apache 2.0 License。同时用户可根据需要进行二次开发。
这种架构原理基于第三种架构，但是更灵活，扩展性更强。同时可配置Logstash 和Elasticsearch 集群用于支持大集群系统的运维日志数据监控和查询。
总结：不管采用上面哪种ELK架构，都包含了其核心组件，即：Logstash、Elasticsearch 和Kibana。当然这三个组件并非不能被替换，只是就性能和功能性而言，这三个组件已经配合的很完美，是密不可分的。在系统运维中究竟该采用哪种架构，可根据现实情况和架构优劣而定。
三、ELK功能模块介绍
ELK组件各个功能模块如下图所示，它运行于分布式系统之上，通过搜集、过滤、传输、储存，对海量系统和组件日志进行集中管理和准实时搜索、分析，使用搜索、监控、事件消息和报表等简单易用的功能，帮助运维人员进行线上业务的准实时监控、业务异常时及时定位原因、排除故障、程序研发时跟踪分析Bug、业务趋势分析、安全与合规审计，深度挖掘日志的大数据价值。同时Elasticsearch提供多种API（REST JAVA PYTHON等API）供用户扩展开发，以满足其不同需求。
四、ELK在大数据运维中作用
1、日志查询，问题排查，上线检查。
2、服务器监控，应用监控，错误报警，bug管理。
3、性能分析，用户行为分析，安全漏洞分析，时间管理。
小结：ELK组件在大数据运维中的应用是一套不可少的且方便、易用的开源解决方案。
http://blog.csdn.net/wenlixing110/article/details/56277603
- 前言
日志，对于任何系统来说都是及其重要的组成部分。在计算机系统里面，更是如此。但是由于现在的计算机系统大多比较复杂，很多系统都不是在一个地方，甚至都是跨国界的；即使是在一个地方的系统，也有不同的来源，比如，操作系统，应用服务，业务逻辑等等。他们都在不停产生各种各样的日志数据。根据不完全统计，我们全球每天大约要产生2EB的数据。1EB=1024PB 1PB=1024TB
面对如此海量的数据，又是分布在各个不同地方，如果我们需要去查找一些重要的信息，难道还是使用传统的方法，去登陆到一台台机器上查看？看来传统的工具和方法已经显得非常笨拙和低效了。于是，一些聪明人就提出了建立一套集中式的方法，把不同来源的数据集中整合到一个地方。
一个完整的集中式日志系统，是离不开以下几个主要特点的:
- 收集－能够采集多种来源的日志数据
- 传输－能够稳定的把日志数据传输到*系统
- 存储－如何存储日志数据
- 分析－可以支持 UI 分析
- 警告－能够提供错误报告，监控机制
开源实时日志分析ELK平台能够完美的解决我们上述的问题，ELK由ElasticSearch、Logstash和Kibana三个开源工具组成。
ElasticSearch：是个开源分布式搜索引擎，它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。
Logstash： 是一个完全开源的工具，他可以对你的日志进行收集、分析，并将其存储供以后使用。
Kibana：也是一个开源和免费的工具，Kibana可以为 Logstash
和 ElasticSearch 提供的日志分析友好的 Web 界面，可以帮助汇总、分析和搜索重要数据日志。
ELK 其实并不是一款软件，而是一整套解决方案，是三个软件产品的首字母缩写，Elasticsearch，Logstash 和 Kibana。这三款软件都是开源软件，通常是配合使用，而且又先后归于 Elastic.co 公司名下，故被简称为ELK协议栈。
在需要收集日志的所有服务上部署logstash，Logstash收集AppServer产生的Log，将日志收集在一起交给全文搜索服务ElasticSearch，而Kibana则从ES集群中查询数据生成图表，再返回给客户端Browser。
3.1、什么是ElasticSearch ES
ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。
Elasticsearch是一个实时分布式搜索和分析引擎。与数据库对比来说：现在大部分数据库在提取可用知识方面显得异常无能。的确，它们能够通过时间戳或者精确匹配做过滤查询，但是它们不能够进行全文搜索，不能处理同义词，以及根据相关性给文档打分。而Elasticsearch能根据同一份数据生成分析和聚合的结果，最重要的是，它们在没有大量工作进程（线程）的情况下能做到对数据的实时处理。
3.2、ElasticSearch的主要应用场景
互联网的时代，建立一个网站或应用程序，要添加搜索功能，实现站内搜索和站外搜索，但是想要完成搜索工作并保证运行的功能和性能是非常困难的。我们希望搜索解决方案要运行速度快，我们希望能有一个零配置和一个完全免费的搜索模式，我们希望能够简单地使用JSON通过HTTP来索引数据，我们希望我们的搜索服务器始终可用，我们希望能够从一台开始并扩展到数百台应用，我们要实时搜索，我们要简单的多租户，我们希望建立一个云的解决方案。因此我们利用Elasticsearch来解决所有这些问题以及可能出现的更多其它问题。
3.3、ElasticSearch的安装部署入门
参考文档
ELK官网：https://www.elastic.co/
ELK官网文档：https://www.elastic.co/guide/index.html
ELK中文手册：https://www.elastic.co/guide/cn/elasticsearch/guide/current/index.html
ELK中文社区：https://elasticsearch.cn/
ELK-API :https://www.elastic.co/guide/en/elasticsearch/client/java-api/current/transport-client.html
进入到es安装目录下的config文件夹中，修改elasticsearch.yml 文件
扩展：
YML文件格式是YAML (YAML Aint Markup Language)编写的文件格式，YAML是一种直观的能够被电脑识别的的数据数据序列化格式，并且容易被人类阅读，容易和脚本语言交互的。
它的基本语法规则如下。
# 表示注释，从这个字符一直到行尾，都会被解析器忽略
|
修改的主要内容：
|
#配置es的集群名称，默认是elasticsearch，es会自动发现在同一网段下的es，如果在同一网段下有多个集群，就可以用这个属性来区分不同的集群。 cluster.name: my-es #节点名称 node.name: node1 #设置索引数据的存储路径 path.data: /export/servers/data #设置日志的存储路径 path.logs: /export/servers/logs #设置当前的ip地址,通过指定相同网段的其他节点会加入该集群中 network.host: 192.168.200.100 #设置对外服务的http端口 http.port: 9200 #设置集群中master节点的初始列表，可以通过这些节点来自动发现新加入集群的节点 discovery.zen.ping.unicast.hosts: ["node1"] |
3.4、解决启动时报错
(1)、在root用户下启动时报错
因为安全问题elasticsearch 不让用root用户直接运行，所以要创建新用户。
|
具体操作如下： useradd es -m passwd es chown -R es:es /export/servers/elasticsearch |
然后使用es用户启动
切换es用户命令：su es
启动集群命令：bin/elasticsearch
(2)、在es用户下启动时报错
原因：Centos6不支持SecComp，而ES默认bootstrap.system_call_filter为true进行检测，所以导致检测失败，失败后直接导致ES不能启动。
详见 ：https://github.com/elastic/elasticsearch/issues/22899
解决方案：
在elasticsearch.yml中新增配置bootstrap.system_call_filter，设为false。
bootstrap.system_call_filter: false
(3)、在es用户下启动继续报错
第一个问题的原因：
|
原因：无法创建本地文件问题,用户最大可创建文件数太小 解决方案：切换到root用户，编辑limits.conf配置文件， 添加类似如下内容： vi /etc/security/limits.conf 添加如下内容: 注意*不要去掉了 * soft nofile 65536 * hard nofile 131072 备注：* 代表Linux所有用户名称（比如 hadoop） 需要保存、退出、重新登录才可生效。 |
第二个错误的原因：
|
原因：无法创建本地线程问题,用户最大可创建线程数太小 解决方案：切换到root用户，进入limits.d目录下，修改90-nproc.conf 配置文件。 vi /etc/security/limits.d/90-nproc.conf 找到如下内容： * soft nproc 1024 #修改为 * soft nproc 4096 |
第三个错误的原因：
|
原因：最大虚拟内存太小 每次启动机器都手动执行下。 root用户执行命令： 执行命令：sysctl -w vm.max_map_count=262144 查看修改结果命令：sysctl -a|grep vm.max_map_count 看是否已经修改
永久性修改策略： echo "vm.max_map_count=262144" >> /etc/sysctl.conf |
3.5、ES基础概念
Elasticsearch有几个核心概念。从一开始理解这些概念会对整个学习过程有莫大的帮助。
接近实时（NRT）
Elasticsearch是一个接近实时的搜索平台。这意味着，从索引一个文档直到这个文档能够被搜索到有一个轻微的延迟（通常是1秒）。
集群（cluster）
一个集群就是由一个或多个节点组织在一起，它们共同持有你整个的数据，并一起提供索引和搜索功能。一个集群由一个唯一的名字标识，这个名字默认就是 “elasticsearch”。这个名字是重要的，因为一个节点只能通过指定某个集群的名字，来加入这个集群。在产品环境中显式地设定这个名字是一个好习惯，但是使用默认值来进行测试/开发也是不错的。
节点（node）
一个节点是你集群中的一个服务器，作为集群的一部分，它存储你的数据，参与集群的索引和搜索功能。和集群类似，一个节点也是由一个名字来标识的，默认情况下，这个名字是一个随机的漫威漫画角色的名字，这个名字会在启动的时候赋予节点。这个名字对于管理工作来说挺重要的，因为在这个管理过程中，你会去确定网络中的哪些服务器对应于Elasticsearch集群中的哪些节点。
一个节点可以通过配置集群名称的方式来加入一个指定的集群。默认情况下，每个节点都会被安排加入到一个叫做“elasticsearch”的集群中，这意味着，如果你在你的网络中启动了若干个节点，并假定它们能够相互发现彼此，它们将会自动地形成并加入到一个叫做“elasticsearch”的集群中。
在一个集群里，只要你想，可以拥有任意多个节点。而且，如果当前你的网络中没有运行任何Elasticsearch节点，这时启动一个节点，会默认创建并加入一个叫做“elasticsearch”的集群。
索引（index）
一个索引就是一个拥有几分相似特征的文档的集合。比如说，你可以有一个客户数据的索引，另一个产品目录的索引，还有一个订单数据的索引。一个索引由一个名字来标识（必须全部是小写字母的），并且当我们要对对应于这个索引中的文档进行索引、搜索、更新和删除的时候，都要使用到这个名字。在一个集群中，如果你想，可以定义任意多的索引。
类型（type）
在一个索引中，你可以定义一种或多种类型。一个类型是你的索引的一个逻辑上的分类/分区，其语义完全由你来定。通常，会为具有一组共同字段的文档定义一个类型。比如说，我们假设你运营一个博客平台并且将你所有的数据存储到一个索引中。在这个索引中，你可以为用户数据定义一个类型，为博客数据定义另一个类型，当然，也可以为评论数据定义另一个类型。
文档（document）
一个文档是一个可被索引的基础信息单元。比如，你可以拥有某一个客户的文档，某一个产品的一个文档，当然，也可以拥有某个订单的一个文档。文档以 JSON（Javascript Object Notation）格式来表示，而JSON是一个到处存在的互联网数据交互格式。
在一个index/type里面，只要你想，你可以存储任意多的文档。注意，尽管一个文档，物理上存在于一个索引之中，文档必须被索引/赋予一个索引的type。
分片和复制（shards & replicas）
一个索引可以存储超出单个结点硬件限制的大量数据。比如，一个具有10亿文档的索引占据1TB的磁盘空间，而任一节点都没有这样大的磁盘空间；或者单个节点处理搜索请求，响应太慢。
为了解决这个问题，Elasticsearch提供了将索引划分成多份的能力，这些份就叫做分片。当你创建一个索引的时候，你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的“索引”，这个“索引”可以被放置到集群中的任何节点上。
分片之所以重要，主要有两方面的原因：
- 允许你水平分割/扩展你的内容容量
- 允许你在分片（潜在地，位于多个节点上）之上进行分布式的、并行的操作，进而提高性能/吞吐量
至于一个分片怎样分布，它的文档怎样聚合回搜索请求，是完全由Elasticsearch管理的，对于作为用户的你来说，这些都是透明的。
默认一个索引有5个分片，每个分片都1个副本。
3.6、访问ES
在Google Chrome浏览器中，访问以下地址：http://node1:9200?pretty
注意：在任意的查询字符串中增加pretty参数，会让Elasticsearch美化输出(pretty-print)JSON响应以便更加容易阅读。
4、Kibana 基础入门
4.1 什么是kibana
Kibana 是一个开源的分析和可视化平台，旨在与 Elasticsearch 合作。Kibana 提供搜索、查看和与存储在 Elasticsearch 索引中的数据进行交互的功能。开发者或运维人员可以轻松地执行高级数据分析，并在各种图表、表格和地图中可视化数据。
4.2 kibana安装部署
下载安装包
访问elasticSearch官网地址 https://www.elastic.co/
进入到kibana安装目录下的config文件夹中，修改kibana.yml 文件
|
server.host: "node1" elasticsearch.url: "http://node1:9200" chown -R es:es /export/servers/kibana |
后台运行：
nohup /export/servers/kibana/bin/kibana >/dev/null 2>&1 &
ps -ef|grep kibana 查看kibana进程
访问kibana界面
具体操作可参照：
https://blog.csdn.net/ming_311/article/details/50619859
批量加载数据方式：
curl -XPOST 'http://node4:9200/bank/account/_bulk?pretty' --data-binary @accounts.json
添加参数：
url -XPOST 'node3:9200/bank100/account/_bulk?pretty' --data-binary @accounts.json -H 'Content-Type:application/json'
5、Logstash基础入门
5.1 什么是Logstash
Logstash 是一个开源的数据收集引擎，它具有备实时数据传输能力。它可以统一过滤来自不同源的数据，并按照开发者的制定的规范输出到目的地。
顾名思义，Logstash 收集数据对象就是日志文件。由于日志文件来源多（如：系统日志、服务器日志等），且内容杂乱，不便于人类进行观察。因此，我们可以使用 Logstash 对日志文件进行收集和统一过滤，变成可读性高的内容，方便开发者或运维人员观察，从而有效的分析系统/项目运行的性能，做好监控和预警的准备工作等。
5.2 Logstash的组成结构
Logstash 通过管道进行运作，管道有两个必需的元素，输入（input）和输出(output)，还有一个可选的元素-过滤器(filter)。输入插件从数据源获取数据，过滤器插件根据用户指定的数据格式修改数据，输出插件则将数据写入到目的地。如下图：
5.3 Logstash安装部署
下载安装包
访问elasticSearch官网地址 https://www.elastic.co/
5.4 logstash入门案例
Logstash 提供了一个 shell 脚本叫 logstash 方便快速运行，-e意指执行
|
bin/logstash -e 'input { stdin { } } output { stdout {} }' |
Hello World（输入）经过 Logstash 管道（过滤）变成：
2018-03-16T13:14:19.342Z node2 Hello World （输出）。
5.5 Logstash的插件介绍
在生产环境中，Logstash 的管道要复杂很多，可能需要配置多个输入、过滤器和输出插件。因此，需要一个配置文件管理输入、过滤器和输出相关的配置。配置文件内容格式如下：
|
# 输入 input { ... } # 过滤器 filter { ... } # 输出 output { ... } |
根据自己的需求在对应的位置配置输入插件、过滤器插件、输出插件和编码解码插件即可。
在使用插件之前，我们先了解一个概念：事件。Logstash 每读取一次数据的行为叫做事件。在 Logstach 目录中创建一个配置文件，名为 logstash.conf（名字任意）。
5.5.1 输入插件
输入插件允许一个特定的事件源可以读取到 Logstash 管道中，配置在 input {} 中，且可以设置多个。
修改配置文件：vi demo1.conf
|
input { # 从文件读取日志信息 file { # 文件路径 path => "/root/access.log" start_position => "beginning" } } # filter { # # } output { # 标准输出 stdout { codec => rubydebug } } |
执行：bin/logstash -f config/demo1.conf
Codec 是 logstash 从 1.3.0 版开始新引入的概念(Codec 来自 Coder/decoder 两个单词的首字母缩写)。
在此之前，logstash 只支持纯文本形式输入，然后以过滤器处理它。
但现在，我们可以在输入 期处理不同类型的数据，这全是因为有了 codec 设置。所以，这里需要纠正之前的一个概念。Logstash 不只是一个 input | filter | output 的数据流，而是一个 input | decode |filter | encode | output 的数据流！codec 就是用来 decode、encode 事件的。codec 的引入，使得 logstash 可以更好更方便的与其他有自定义数据格式的运维产品共存，。事实上，我们在第一个 "hello world" 用例中就已经用过 codec 了 —— rubydebug 就是一种 codec！虽然它一般只会用在stdout 插件中，作为配置测试或者调试的工具。
5.5.2 数据写入到ES中
编写配置文件：vi data2es.conf
|
input { file { #指定类型 type => "game" #监控的文件路径 path => "/root/log.json" #每隔多久去检查一次被监听的文件是否有新增的内容 discover_interval => 5 #start_position可以设置为beginning或者end，beginning表示从头开始读取文件，end表示读取最新的 start_position => "beginning" } } output { #数据写入到es中 elasticsearch { #定义数据写入到es中的哪个索引中 index => "game-%{+YYYY.MM.dd}" #定义es集群地址 hosts => ["192.168.200.100:9200"] } }
|
执行：bin/logstash -f config/data2es.conf
5.5.3 数据写入到kafka中
编写配置文件data2kafka.conf
|
input { file { #监控的文件路径 path => "/root/access.log" #start_position可以设置为beginning或者end，beginning表示从头开始读取文件，end表示读取最新的 start_position => "beginning" #sincedb_path表示文件读取进度的记录 sincedb_path => "/export/servers/logstash/config/index" } } output { kafka { #topic的名称 topic_id => "accesslog" #kafka集群地址 bootstrap_servers => ["node1:9092,node2:9092,node3:9092"] } } |
执行：bin/logstash -f config/data2kafka.conf
5.5.4 读取kafka中topic数据
(1) 启动zookeeper kafka集群
(2) 创建主题:
kafka-topics.sh --zookeeper node1:2181 --create --topic hello --replication-factor 1 --partitions 3
- 执行生产者脚本:
kafka-console-producer.sh --broker-list node1:9092 --topic hello
执行消费者脚本，查看是否写入:
kafka-console-consumer.sh --zookeeper node1:2181 --from-beginning --topic hello
- 编写logstash配置文件 readDataFromKafka.conf
|
input{ kafka { #codec的默认值为plain，表示一个空的解析器，codec可以让用户自己指定格式 codec => "plain" #消费者组id group_id => "logstash1" #消费者消费的策略 #earliest--从提交的offset开始消费；无提交的offset时，从头开始消费 #latest--从提交的offset开始消费；无提交的offset时，消费新产生的该分区下的数据 auto_offset_reset => "earliest" #topic的名称 topics => ["accesslog"] #kafka集群地址 bootstrap_servers => ["node1:9092,node2:9092,node3:9092"] }
} output{ stdout{ # 采用Ruby库来解析日志,直接输出在控制台 codec => rubydebug } } |
执行：bin/logstash -f config/readDataFromKafka.conf
5.5.5 数据写入到HDFS上
编写配置文件信息 vi data2hdfs.conf
|
input { file{ #正则表达式匹配/root目录下所有的以.log结尾的文件 path =>"/root/data/*.log" #多久检查该目录下是否有新的文件生成 discover_interval => 5 #Logstash开始读取文件的位置：开头或结尾 start_position => "beginning" #sincedb_path表示文件读取进度的记录 sincedb_path => "/export/servers/logstash/config/index" } } output { #指定数据保存在hdfs上 webhdfs { #namenode的所在的主机名 host => "node1" #hdfs web端口 port => 50070 #保存的路径 path => "/logstash/dt=%{+YYYY-MM-dd}/logstash-%{+HH}.log" #用户名 user => "root" } }
|
执行：bin/logstash -f config/data2hdfs.conf
其他丰富插件使用说明：
http://blog.csdn.net/iguyue/article/details/77006201