背景
一直对ELK一知半解，之前看到别人提到的好处，自己没有搭建过，在此，做一个学习笔记，为将来搭建储备一些知识。
本文主要参考了一篇网上的文章，主要对自己感兴趣的内容写了一些理解，更多的内容参见原文链接
ELK架构
首先要对ELK大体的架构有所了解，这样对后面每个组件的学习，才能够做到心中有数，从网上找到了这张图，感觉很适合我的学习。从图中可以看出，整个ELK平台各个组件的作用如下：
Logstash收集AppServer产生的Log，并存放到ElasticSearch集群中，而Kibana则从ES集群中查询数据生成图表，再返回给Browser。可见，虽然简称是ELK，其实按照下图的日志采集顺序来说，真正的简称应该是LEK。
从部署角度看，从网上找到了这段文字和一张图，感觉写的不错，分享一下：
- 在每台生成日志文件的机器上，部署Logstash，作为Shipper的角色，负责从日志文件中提取数据，但是不做任何处理，直接将数据输出到Redis队列(list)中；1
- 需要一台机器部署Logstash，作为Indexer的角色，负责从Redis中取出数据，对数据进行格式化和相关处理后，输出到Elasticsearch中存储；
- 部署Elasticsearch集群，当然取决于你的数据量了，数据量小的话可以使用单台服务，如果做集群的话，最好是有3个以上节点，同时还需要部署相关的监控插件；
- 部署Kibana服务，提供Web服务。
![ELK部署图]()
下面就来逐个介绍LEK各个组件的作用。
LogStash
依然用一个图来做解释，从图中可以看出LogStash的作用。其实就是输入，过滤，输出，起到了采集、处理、传输的作用。
ElasticSearch
ES之前也看过不少文章，曾经也有项目使用过，个人最大的感受是，ES特别耗费资源，如果项目涉及的服务或者机器不多，建议使用ES要慎重。毕竟单点ES方案并不是长远之计，如果要建立ES集群的话，需要注意以下几点：
- 关于集群节点，第一，节点类型包括：候选Master节点、数据节点和Client节点。通过设置两个配置项node.master和node.data为true或false，来决定将一个节点分配为什么类型的节点。第二，尽量将候选Master节点和Data节点分离开，通常Data节点负载较重，需要考虑单独部署。
- 关于内存，Elasticsearch默认设置的内存是1GB，对于任何一个业务部署来说，这个都太小了。通过指定ES_HEAP_SIZE环境变量，可以修改其堆内存大小，服务进程在启动时候会读取这个变量，并相应的设置堆的大小。建议设置系统内存的一半给Elasticsearch，但是不要超过32GB。
- 关于存储，Elasticsearch默认将数据存储在/var/lib/elasticsearch路径下，随着数据的增长，一定会出现硬盘空间不够用的情形，此时就需要给机器挂载新的硬盘，并将Elasticsearch的路径配置到新硬盘的路径下。通过“path.data”配置项来进行设置，比如“path.data: /data1,/var/lib/elasticsearch,/data”。需要注意的是，同一分片下的数据只能写入到一个路径下，因此还是需要合理的规划和监控硬盘的使用。
Kibana笔记
Kibana提供的是数据查询和显示的Web服务，有丰富的图表样板，能满足大部分的数据可视化需求，这也是很多人选择ELK的主要原因之一。UI的操作没有什么特别需要介绍的，经常使用就会熟练。
为什么采用redis，原文中有解释，有兴趣的可以去学习一下。 ↩︎