Elasticsearch集群部署（一）
前面已经对flume这种日志收集方式进行了记录https://blog.51niux.com/?id=196，这里开始记录ELK的日志收集。ELK大家已经很熟悉了主要是用来日志收集分析展示。
一、ELK介绍
1.1 ELK简介
一个完整的集中式日志系统，是离不开以下几个主要特点的：
收集－能够采集多种来源的日志数据 传输－能够稳定的把日志数据传输到中央系统 存储－如何存储日志数据 分析－可以支持 UI 分析 警告－能够提供错误报告，监控机制 #基于上述思路，于是许多产品或方案就应运而生了。比如，简单的 Rsyslog，Syslog-ng；商业化的 Splunk ；开源的有 FaceBook 公司的 Scribe，Apache 的 Chukwa，Linkedin 的 Kafak，Cloudera 的 Fluentd，ELK 等等。
ELK 其实并不是一款软件，而是一整套解决方案，是三个软件产品的首字母缩写，Elasticsearch，Logstash 和 Kibana。这三款软件都是开源软件，通常是配合使用，而且又先后归于 Elastic.co 公司名下，故被简称为 ELK 。三个工具的简单介绍：
Elasticsearch #是个开源分布式搜索引擎，具有分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等特性。 Logstash #是一个完全开源的工具，他可以对日志进行收集、分析，并将其存储. Kibana #是一个开源和免费的工具，可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面.
#上图是ELK的体系结构，基本流程是 logstash 负责从各种数据源里采集数据，然后再写入 Elasticsearch，Elasticsearch 对这些数据创建索引，然后由 Kibana 对其进行各种分析并以图表的形式展示。
1.2 Lucene简介
Lucene是一个免费、开源、高性能、纯Java编写的全文检索引擎。2005年，Lucene升级成为Apache顶级项目。Lucene：底层的API，工具包。
Solr：基于Lucene开发的企业级的搜索引擎产品。Elasticsearch：基于Lucene开发的企业级的搜索引擎产品。
Lucene的主要模块有：
Analysis模块：主要负责词法分析及语言处理，也就是我们常说的分词，通过该模块可最终形成存储或者搜索的最小单元Term。 Index模块：主要负责索引的创建工作。 Store模块：主要负责索引的读和写，主要是对文件的一些操作，其主要目的是抽象出和平台文件系统无关的存储。 QueryParser模块：主要负责语法分析，把查询语句生成Lucene底层可以识别的条件。 Search模块：主要负责对索引的搜索工作。 Similarity模块：主要负责相关性打分和排序的实现。
Lucene中核心术语：
Term：索引中最小的存储和查询单元。 Term Dictionary（字典）：是Term的集合。 Posting List（倒排表)：一篇文章由多个词组成，倒排表记录的是某个词在哪些文章中出现过。 正向信息：原始的文档信息，可以用来做排序、聚合、展示等。 Segment(段)：索引中最小的独立存储单元。一个索引文件由一个或者多个段组成。在Lucene中，段有不变性，段一旦生成，在段上只能读取、不可写入。
1.3 三个工具较详细介绍
elasticsearch
ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。
Logstash
Logstash 是一款强大的数据处理工具，它可以实现数据传输，格式处理，格式化输出，还有强大的插件功能，常用于日志处理。
Logstash工作的三个阶段：
下面是一些主要的,了解详细的还是要参照官网：
input 数据输入端，可以接收来自任何地方的源数据。官网：https://www.elastic.co/guide/en/logstash/current/input-plugins.html
file：从文件中读取 syslog：监听在514端口的系统日志信息，并解析成RFC3164格式。 redis：从redis-server list中获取 beat：接收来自Filebeat的事件 kafka：从kafka的topic读取数据
Filter 数据中转层，主要进行格式处理，数据类型转换、数据过滤、字段添加，修改等，常用的过滤器如下。
grok: 通过正则解析和结构化任何文本。Grok 目前是logstash最好的方式对非结构化日志数据解析成结构化和可查询化。logstash内置了120个匹配模式，满足大部分需求。 mutate: 在事件字段执行一般的转换。可以重命名、删除、替换和修改事件字段。 drop: 完全丢弃事件，如debug事件。 clone: 复制事件，可能添加或者删除字段。 geoip: 添加有关IP地址地理位置信息。
output 是logstash工作的最后一个阶段，负责将数据输出到指定位置，兼容大多数应用，常用的有:
elasticsearch: 发送事件数据到 Elasticsearch，便于查询，分析，绘图。 file: 将事件数据写入到磁盘文件上。 mongodb:将事件数据发送至高性能NoSQL mongodb，便于永久存储，查询，分析，大数据分片。 redis:将数据发送至redis-server，常用于中间层暂时缓存。 graphite: 发送事件数据到graphite。 statsd: 发送事件数据到 statsd。
非常好的博客：https://www.cnblogs.com/xing901022/p/6596182.html
Kibana
Kibana是一个开源的分析与可视化平台，设计出来用于和Elasticsearch一起使用的。你可以用kibana搜索、查看、交互存放在Elasticsearch索引里的数据，使用各种不同的图表、表格、地图等kibana能够很轻易地展示高级数据分析与可视化。
Kibana让我们理解大量数据变得很容易。它简单、基于浏览器的接口使你能快速创建和分享实时展现Elasticsearch查询变化的动态仪表盘。
# 简单来讲他具体的工作流程就是 logstash agent 监控并过滤日志，logstash index将日志收集在一起交给全文搜索服务ElasticSearch 可以用ElasticSearch进行自定义搜索 通过Kibana 来结合 自定义搜索进行页面展示，如上图。
博文来自：www.51niux.com
1.4 Elasticsearch的核心概念
术语表官方文档：https://www.elastic.co/guide/en/elastic-stack-glossary/current/terms.html
Near Realtime (NRT)：Elasticsearch是一个接近实时的搜索平台.这意味着从索引文档的时间到可搜索的时间都有一个小的延迟（通常是一秒）。
Node(节点): 节点是组成Elasticsearch集群的基本服务单元，集群中的每个运行中的Elasticsearch服务器都可称之为节点。节点是作为集群一部分的单个服务器，存储数据并参与集群的索引和搜索功能。就像一个集群一样，一个节点由一个名字来标识，默认情况下它是一个在启动时分配给节点的随机通用唯一标识符（UUID）。如果你不需要默认值，你可以定义任何你想要的节点名称。
Cluster(集群): Elasticsearch的集群是由具有相同cluster.name （默认值为elasticsearch）的一个或多个Elasticsearch节点组成的，各个节点协同工作，共享数据。同一个集群内节点的名字不能重复，但集群名称一定要相同。在Elasticsearch集群中，节点的状态有Green(集群健康,主分片和副本分片都正常）、Yellow(预警状态集群依旧可以正常工作,主分片正常,但至少有一个副本分片不能正常工作)和Red(集权无法正常使用,集群中至少有一个分片的主分片及它的全部副本分片都不可正常工作。集群的查询操作还可以进行,但是也只能返回正常分片的数据)三种.
Shards(分片)：当索引的数据量太大时，受限于单个节点的内存、磁盘处理能力等，节点无法足够快地响应客户端的请求，此时需要将一个索引上的数据进行水平拆分。拆分出来的每个数据部分称之为一个分片。一般来说，每个分片都会放到不同的服务器上。Elasticsearch依赖Lucene，Elasticsearch中的每个分片其实都是Lucene中的一个索引文件，因此每个分片必须有一个主分片和零到多个副本分片。设置有多分片的索引写入数据时,是通过路由来确定的,因此创建索引时需要指定分片的数量,并且分配的数量一旦确定就不能更改。当查询索引时,Elasticsearch会把查询发送给每个相关的分片，并汇总各个分片的查询结果。在Elasticsearch中，默认为一个索引创建5个主分片，并分别为每个主分片创建一个副本。
primary shard（主分片）：每个文档都存储在一个主分片中。 索引文档时，首先在主分片上索引，然后在主分片的所有副本上索引。 默认情况下，索引有5个主分片。 可以指定更少或更多的主分片来缩放索引可以处理的文档数量。 创建索引后，无法更改索引中的主分片数量。
Replicas(备份)：也可称为副本。副本指的是对主分片的备份，主分片和备份分片都可以对外提供数据查询,当构建索引进入写入操作时,首先在主分片上完成数据的索引，然后数据会从主分片分发到备份分片上进行索引。当主分片不可用时，Elasticsearch会在备份分片中选举出一个分片作为主分片，从而避免数据丢失。 默认情况下，每个主分片都有一个副本，但副本的数量可以在现有索引上动态更改。 副本分片将永远不会在与其主分片相同的节点上启动。虽然备份分片提升了搜索时的并发性能,但是备份分片数量太多会增加写操作时数据同步的负担。
Index(索引)：索引就像关系数据库中的表。 它有一个映射，其中包含一个类型，其中包含索引中的字段。 索引是逻辑名称空间，映射到一个或多个主分片，可以有零个或多个副本分片。
Type(类别): 类别指的是索引内部的逻辑分区,通过Type的名字在索引内进行唯一标识。在查询时如果没有该值,则表示需要在整个索引中查询。6.x为了考虑兼容性是单index多type，7.x之后只能是单Index和单type，现在索引的type就是doc,类似于Mysql的表。
Document(文档): 索引中每一条数据叫做一个文档,一条文档数据通过_id在Type内进行唯一标识。文档是存储在Elasticsearch中的JSON文档。 它就像一个关系数据库中的表格中的一行。 索引的原始JSON文档将存储在_source字段中，在获取或搜索文档时默认返回该字段。
id: 文档的标识。文档的索引/标识必须是唯一的。 如果没有提供ID，则会自动生成。
field: document中的键值对,请参阅Mapping。该值可以是简单（标量）值（例如字符串，整数，日期），也可以是嵌套结构（如数组或对象）。 字段与关系数据库中的表中的列相似。 每个字段的映射都有一个字段类型（不要与文档类型混淆），它指示可以存储在该字段中的数据的类型，例如整数，字符串，对象。
Settings(设置): 对集群中索引的定义信息,如一个索引默认的分片数、副本数等。
Mapping(映射)：Mapping表中保存了定义索引中字段（Field）的存储类型、分词方式、是否存储等信息，有点类似于关系数据库（如MySQL）中的表结构信息。Mapping是可以动态识别的,如没有特殊需求，则不需要手动创建Mapping，因为Elasticsearch会根据数据格式自动识别它的类型。当需要对某些字段添加特殊属性时，如定义使用其他分词器、是否分词、是否存储等，就需要手动设置Mapping了。一个索引的Mapping一旦创建，若已经存储了数据，就不可修改了。
analysis(分析)：将非结构化文本转换为优化搜索的格式的过程。
routing(路由)：索引文档时，它将存储在单个主分片上。 该分片是通过散列路由值来选择的。 默认情况下，路由值是从文档ID派生的，或者如果文档具有指定的父文档，则从父文档的ID派生（以确保子文档和父文档存储在同一个分片上）。 此值可以通过在索引时指定路由值或映射中的路由字段来覆盖。
source field（源字段）：默认情况下，索引的JSON文档将存储在_source字段中, _source字段本身未索引（因此无法搜索）。
term：已针对搜索优化的非结构化文本块，索引的确切值。term是精确查询，搜索前不会再对搜索词进行分词，如foo，Foo，FOO不等价。
keyword和text：ES有两个数据类型，keyword和text。keyword表示不会被自动分词，而text会自动分词分词后的字母会全部转为小写。
1.5 数据写入过程
分段存储
索引数据在磁盘上是以分段形式存储的。在索引中，索引文件被拆分为多个子文件，其中每个子文件就叫作段，每个段都是一个倒排索引的小单元。段具有不变性，一旦索引的数据被写入硬盘，就不能再修改,分段是为了进行修改时,不至于全量更新当前的倒排索引文件。
当分段被写入磁盘后会生成一个提交点，提交点意味着一个用来记录所有段信息的文件已经生成。因此，一个段一旦拥有了提交点，就表示从此该段仅有读的权限，永远失去了写的权限。Elasticsearch为了加快写入的速度，写入过程往往是并发实施的。为了解决在并发写的过程中出现的数据冲突的问题，Elasticsearch通过乐观锁进行控制，每个文档都有一个version （版本号）,当文档被修改时版本号递增。Elasticsearch根据文档标识符ID将文档分配到多个分片上,读取的时候也是路由默认根据id字段通过hash得到数据在哪个分片上。
当段在内存中时，此时分段拥有只写的权限，数据还会不断写入，而不具备读数据的权限，意味着这部分数据不能被Elasticsearch用户检索到。数据新增只需在当前文档新增一个段即可。删除数据时，由于分段不可修改的特性，Elasticsearch不会把文档从旧的段中移除，因而是新增一个.del文件，.del文件中会记录这些被删除文档的段信息。被标记删除的文档仍然可以被查询匹配到，但它会在最终结果被返回前通过.del文件将其从结果集中移除。当更新数据时，由于分段不可修改的特性，Elasticsearch无法通过修改旧的段来反映文档的更新，于是，更新操作变成了两个操作的结合，即先删除、后新增。Elasticsearch会将旧的文档从.del文件中标记删除，然后将文档的新版本索引到一个新的段中。在查询数据时，两个版本的文档都会被一个查询匹配到，但被删除的旧版本文档在结果集返回前就会被移除。这样段的优势表现在不需要锁,从而提升了Elasticsearch的读写性能。当然段的不变性也会导致删除和更新数据时,导致存储空间的浪费和增加查询负担。
延迟策略
在Elasticsearch中，索引写入磁盘的过程是异步的。为了提升写的性能，Elasticsearch并没有每新增一条数据就增加一个段到磁盘上，而是采用延迟写策略。每当有新的数据写入时，就将其先写入JVM的内存中。在内存和磁盘之间是文件系统缓存，文件缓存空间使用的是操作系统的空间。当达到默认的时间或者内存的数据达到一定量时，会触发一次刷新（Refresh）操作。刷新操作将内存中的数据生成到一个新的分段上并缓存到文件缓存系统，稍后再被刷新到磁盘中并生成提交点。
由于新的数据会继续写入内存，而内存中的数据并不是以段的形式存储的，因此不能提供检索功能。只有当数据经由内存刷新到文件缓存系统，并生成新的段后，新的段才能供搜索使用，而不需要等到被刷新到磁盘才可以搜索。
在Elasticsearch中，写入和打开一个新段的过程叫作刷新。在默认情况下，每个分片会每秒自动刷新一次。这就是Elasticsearch能做到近实时搜索的原因，因为文档的变化并不是立即对搜索可见的，但会在一秒之内变为可见。当然也可以手动触发刷新。还可以在创建索引时，在Settings中通过配置refresh_interval的值，来调整索引的刷新频率,默认是毫秒,当refresh_interval=-1时，表示关闭索引的自动刷新。
为了防止数据没落盘突然断电等问题导致数据丢失的问题,Elasticsearch引入事务日志（Translog）机制。事务日志用于记录所有还没有持久化到磁盘的数据,在添加了事务日志机制后，数据写入索引的流程如下所示：
（1）新文档被索引之后，先被写入内存中。为了防止数据丢失，Elasticsearch会追加一份数据到事务日志中。如：/data/es/data/nodes/0/indices/ia69YhavSWGOIt-7n10NRA/0/translog #就是一份json日志 （2）新的文档持续在被写入内存时，同时也会记录到事务日志中。当然，此时的新数据还不能被检索和查询。 （3）当达到默认的刷新时间或内存中的数据达到一定量后，Elasticsearch会触发一次刷新，将内存中的数据以一个新段形式刷新到文件缓存系统中并清空内存。这时新段虽未被提交到磁盘，但已经可以对外提供文档的检索功能且不被修改。 （4）随着新文档索引不断被写入，当日志数据大小超过某个值（如512MB），或者超过一定时间（如30 min）时，Elasticsearch会触发一次Flush。
此时，内存中的数据被写入一个新段，同时被写入文件缓存系统，文件缓存系统中的数据通过Fsync刷新到磁盘中，生成提交点。而日志文件被删除，创建一个空的新日志。
段合并
在Elasticsearch自动刷新流程中，每秒都会创建一个新的段。这自然会导致短时间内段的数量猛增，而当段数量太多时会带来较大的资源消耗，如对文件句柄、内存和CPU的消耗。而在内容搜索阶段，由于搜索请求要检查到每个段，然后合并查询结果，因此段越多，搜索速度越慢。为此，Elasticsearch引入段合并机制。段合并机制在后台定期进行，从而小的段被合并到大的段，然后这些大的段再被合并到更大的段。
在段合并过程中，Elasticsearch会将那些旧的已删除文档从文件系统中清除。被删除的文档不会被拷贝到新的大段中，当然，在合并的过程中不会中断索引和搜索。段合并是自动进行索引和搜索的，在合并进程中，会选择一小部分大小相似的段，在后台将它们合并到更大的段中，这些段既可以是未提交的，也可以是已提交的。
在合并结束后，老的段会被删除，新的段被Flush到磁盘，同时写入一个包含新段且排除旧的和较小的段的新提交点。打开新的段之后，可以用来搜索。
由于段合并的计算量较大，对磁盘I/O的消耗也较大，因此段合并会影响正常的数据写入速率，为了不让段合并影响搜索性能。Elasticsearch在默认情况下会对合并流程进行资源限制，这就是搜索服务仍然有足够的资源仍然可以执行的原因。
二、ELK集群的简单部署
2.1 环境简单规划
就照着线上的环境来了：
Elasticsearch: 192.168.14.60-64,单挂一个500G硬盘，线上是（6T*12做的RAID5，也就是一个节点是66T存储空间，但是不建议这样用大盘存储读写性能就很差做RAID5性能就更差了，可以多搞几个RAID0卷组），4C8G(线上是24C当然CPU用的不狠也就20%-30%，内存是64G内存要大基本全用)。
Logstash: 192.168.14.65 4C 8G(线上是四台16C 64G 当然内存就用不了上面那么多了也就6G左右)
Kibana: 192.168.14.66 4C 8G（线上8C 16G）
2.2 Elasticsearch安装配置(所有节点的操作)
官网部署文档：https://www.elastic.co/guide/en/elasticsearch/reference/current/_installation.html
#所有节点关闭selinux,防火墙,时间同步,然后安装java。
# java -version #jdk选择1.8版本
java version "1.8.0_74" Java(TM) SE Runtime Environment (build 1.8.0_74-b02) Java HotSpot(TM) 64-Bit Server VM (build 25.74-b02, mixed mode) [root@localhost java]# date 2017年 12月 05日 星期二 14:19:31 CST
# wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.0.0.tar.gz #就下载最新版吧，我线上用的是2.3.4版本，所以jdk用的是1.7
# useradd elk #创建个elk普通用户吧，线上可以用统一的管理用户来管理没必要单独创建elk用户
# tar zxf elasticsearch-6.0.0.tar.gz
# mv elasticsearch-6.0.0 /home/elk/
# chown -R elk:elk /home/elk/elasticsearch-6.0.0
# ln -s /home/elk/elasticsearch-6.0.0 /home/elk/elasticsearch
注：elasticsearch的目录结构
bin文件夹：命令目录 config文件夹：配置文件。 jdk文件夹：存放的是Java运行环境。 lib文件夹：Elasticsearch自身所需lib文件。 logs文件夹：存放的是日志文件。 modules文件夹：Elasticsearch的各个模块。 plugins文件夹：配置插件，每个插件都包含在一个子目录中。
2.3 Elasticsearch的配置
#vim /etc/security/limits.conf #这个初始优化的时候一般都会做好
* soft nofile 1024000 * hard nofile 1024000 # End of file
# vi /etc/sysctl.conf
vm.max_map_count = 655360
# sysctl -p
#如果不调大字符集和提高了vm.max_map_count的大小的话会有下面的报错：
[2017-12-05T16:59:49,110][INFO ][o.e.b.BootstrapChecks ] [192.168.14.63] bound or publishing to a non-loopback or non-link-local address, enforcing bootstrap checks ERROR: [2] bootstrap checks failed [1]: max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536] [2]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
$ ls -l /home/elk/elasticsearch/config/
总用量 16 -rw-rw----. 1 elk elk 2854 11月 11 02:40 elasticsearch.yml #主配置文件 -rw-rw----. 1 elk elk 2672 11月 11 02:40 jvm.options #jvm参数配置文件 -rw-rw----. 1 elk elk 5091 11月 11 02:40 log4j2.properties #日志配置文件
$ vim /home/elk/elasticsearch/config/elasticsearch.yml
cluster.name: elasticsearch_51niux node.name: 192.168.14.61 path.data: /data/es/data #索引数据位置,数据写入操作是在Elasticsearch的内存中执行的，数据会被分配到特定的分片和副本上，最终会落盘持久化。 path.logs: /data/es/log #日志记录位置 network.host: 192.168.14.61 node.master: true #是否有资格选举和被选举为主节点,主节点要负责创建索引、删除索引、追踪集群中节点的状态，以及跟踪哪些节点是群集的一部分，并决定将哪些分片分配给相关的节点等。 node.data: true #是否为数据节点，数据节点负责数据的存储相关的操作，如对数据进行增、删、改、查和聚合等,所以对机器的配置要求较高。 discovery.zen.ping.unicast.hosts: ["192.168.14.60","192.168.14.61","192.168.14.62","192.168.14.63","192.168.14.64"] #在单播模式下，节点应该自动发现哪些节点列表 discovery.zen.minimum_master_nodes: 3 #集群中选举主节点时至少需要有多少个节点参与 discovery.zen.fd.ping_timeout: 120s #节点与节点之间连接ping命令执行的超时时长 discovery.zen.fd.ping_retries: 6 discovery.zen.fd.ping_interval: 30s cluster.routing.allocation.cluster_concurrent_rebalance: 40 cluster.routing.allocation.node_concurrent_recoveries: 40 cluster.routing.allocation.node_initial_primaries_recoveries: 40
#直接复制2.X的elasticsearch.yml配置文件5.0改变了好多会有大量报错：
1）”node settings must not contain any index level settings”不支持索引级别设置 2）不支持脚本设置script。 3）bootstrap.mlockall 改为了 bootstrap.memory_lock。 4) 直接在5.0的elasticsearch.yml进行参数设定。 5）./config/ 里面新增了 vm.options和log4j2.properties，取消了logging.yml。 6）内存的配置可以直接在 jvm.options 里面。
#注：下面是2.X的配置
cluster.name: elasticsearch_51niux #集群名称 node.name: 192.168.14.61 #本node节点的名称 network.host: 192.168.14.61 #服务监听的IP地址 path.data: /data/es/data #设置索引数据的存储路径，多存储路径的话用逗号隔开，磁盘就是我们单挂的500G的盘，线上是几十T的挂载盘，xfs文件系统格式。 path.logs: /data/es/log #日志存放路径 node.master: true #是否可以为主节点。这个属性表示节点是否具有成为主节点的资格注意：此属性的值为true，并不意味着这个节点就是主节点。因为真正的主节点，是由多个具有主节点资格的节点进行选举产生的。所以，这个属性只是代表这个节点是不是具有主节点选举资格。 node.data: true #这个属性表示节点是否存储数据。 index.number_of_shards: 3 #设置索引分片个数分3，默认为5片 index.number_of_replicas: 1 #副本备份数量为1,默认是1分别为每个分片创建一个副本。 index.refresh_interval: 120s #默认值是 1s，这迫使Elasticsearch集群每秒创建一个新的 segment （可以理解为Lucene 的索引文件）。增加这个值，例如120s，可以允许更大的segment写入，减后以后的segment合并压力。 discovery.zen.ping.multicast.enabled: false #设置是否打开多播发现节点，默认是true。 建议也禁用组播形式。云主机貌似不支持组播。当禁用multcast广播的时候，可以手动设置集群的节点ip discovery.zen.ping.unicast.hosts: ["192.168.14.60","192.168.14.61","192.168.14.62","192.168.14.63","192.168.14.64"] #设置集群列表因为上面禁用组播了 discovery.zen.minimum_master_nodes: 3 #配置当前集群中最少的主节点数，防止脑裂。下面三个参数的配置是解决集群内部超时。 discovery.zen.fd.ping_timeout: 120s #超时时间设为2分钟。 discovery.zen.fd.ping_retries: 6 #测试次数为6次，超过6次则认为该节点同master已经脱离了默认是3次。 discovery.zen.fd.ping_interval: 30s #节点每隔30s同master发送1次心跳，默认是1秒太频繁了。 index.cache.field.type: soft #默认类型为resident， 字面意思是常驻（居民），一直增加，直到内存 耗尽。改为soft就是当内存不足的时候，先clear掉 占用的，然后再往内存中放。设置为soft后，相当于设置成了相对的内存大小。resident的话，除非内存够大。 indices.memory.index_buffer_size: 30% #接受一个百分比或者一个表示字节大小的值。 默认是10%，意味着分配给节点的总内存的10%用来做索引缓冲的大小。这个数值被分到不同的分片(shards)上。 如果设置的是百分比，还可以设置min_index_buffer_size (默认48mb)和max_index_buffer_size（默认没有上限）。 index.cache.field.max_size: 50000 #每个segment的最大缓存文档数 index.cache.field.expire: 10m #缓存过期时间 #上面的两个设置是为了解决out of memory错误，还有就是上面的index.cache.field.type: soft cluster.routing.allocation.cluster_concurrent_rebalance: 40 #控制集群内同时启动的数据均衡任务个数。默认是2个。 cluster.routing.allocation.node_concurrent_recoveries: 40 #添加删除节点或负载均衡时并发恢复线程的个数，默认为4。 cluster.routing.allocation.node_initial_primaries_recoveries: 40 #初始化数据恢复时，并发恢复线程的个数，默认为4。 #上面三个参数CPU个数多、IO负载好久多设置点，不好就设置小点，设置不当影响ES的索引性能。我线上是24C的CPU，所以设置的高些。 index.translog.interval: 60s index.translog.sync_interval: 60s index.translog.durability: async index.translog.fs.type: buffered index.translog.fs.buffer_size: 256k #为什么要有Translog? 因为Translog顺序写日志比构建索引更高效。我们不可能每加一条记录就Commit一次，这样会有大量的文件和磁盘IO产生。但是我们又想避免程序挂掉或者硬件故障而出现数据丢失，所以有了Translog，通常这种日志我们叫做Write Ahead Log。 #在进行实际应用中，会记录下查询速度慢或者添加索引速度慢的操作记录，为后续性能优化提供依据。其具体配置如下： index.search.slowlog.threshold.query.warn: 10s index.search.slowlog.threshold.query.info: 5s index.search.slowlog.threshold.query.debug: 2s index.search.slowlog.threshold.query.trace: 500ms index.search.slowlog.threshold.fetch.warn: 1s index.search.slowlog.threshold.fetch.info: 800ms index.search.slowlog.threshold.fetch.debug: 500ms index.search.slowlog.threshold.fetch.trace: 200ms #可以用如下的配置来设置索引写入慢日志的阈值： index.indexing.slowlog.threshold.index.warn: 10s index.indexing.slowlog.threshold.index.info: 5s index.indexing.slowlog.threshold.index.debug: 2s index.indexing.slowlog.threshold.index.trace: 500ms index.indexing.slowlog.level: info index.indexing.slowlog.source: 1000
#如果上面定义了慢查询的设置，那么config/logging.yml也要配置一下，下面是部分设置：
index_search_slow_log_file:
type: dailyRollingFile
file: ${path.logs}/${cluster.name}_index_search_slowlog.log
datePattern: "'.'yyyy-MM-dd"
layout:
type: pattern
conversionPattern: "[%d{ISO8601}][%-5p][%-25c] %m%n"
index_indexing_slow_log_file:
type: dailyRollingFile
file: ${path.logs}/${cluster.name}_index_indexing_slowlog.log
datePattern: "'.'yyyy-MM-dd"
layout:
type: pattern
conversionPattern: "[%d{ISO8601}][%-5p][%-25c] %m%n"
#/data/es/log下面就会生成类似于elasticsearch_log_index_indexing_slowlog.log这样的日志然后按照天切割，例如elasticsearch_log_index_indexing_slowlog.log.2018-01-12# vim /home/elk/elasticsearch/config/jvm.options #先不配置保持默认，先看看各参数的意义
#https://www.elastic.co/guide/en/elasticsearch/reference/current/heap-size.html #了解更多信息
-Xms1g #总堆空间的初始大小，主要是该这里和下面的参数，所占大小尽量大。
-Xmx1g #总堆空间的最大大小，，如我们是64G的内存初始就是32G,官网推荐最多是物理内存的一半。
## GC configuration
-XX:+UseConcMarkSweepGC #使用CMS内存收集
-XX:CMSInitiatingOccupancyFraction=75 #使用cms作为垃圾回收使用75％后开始CMS收集
-XX:+UseCMSInitiatingOccupancyOnly #使用手动定义初始化定义开始CMS收集
##优化＃初始化期间JVM使用的预触摸内存页面
-XX:+AlwaysPreTouch #在调用main函数之前，使用所有可用的内存分页。这个选项可以用来测试长时间运行的系统，所有的内存都已被分配。默认这个选项是关闭的，也就是不会使用所有的内存分页。
##基本
-server ＃强制服务器虚拟机
-Xss1m #每个线程的堆栈大小
-Djava.awt.headless=true #设置为headless以防万一
-Dfile.encoding=UTF-8 #确保默认UTF-8编码（例如文件名）
-Djna.nosys=true
-XX:-OmitStackTraceInFastThrow #关闭JDK优化，因为堆栈跟踪对于调试非常重要，因此它会为常见异常抛出堆栈跟踪
#配置Netty的标志
-Dio.netty.noUnsafe=true
-Dio.netty.noKeySetOptimization=true
-Dio.netty.recycler.maxCapacityPerThread=0
# log4j 2
-Dlog4j.shutdownHookEnabled=false
-Dlog4j2.disable.jmx=true
##堆转储
-XX:+HeapDumpOnOutOfMemoryError ＃当Java堆的分配失败堆转储在JVM的工作目录中创建时，将生成一个堆转储
#-XX:HeapDumpPath=/heap/dump/path ＃为堆转储指定一个替代路径，确保该目录存在，并有足够的空间
## GC记录
#-XX:+PrintGCDetails
#-XX:+PrintGCTimeStamps
#-XX:+PrintGCDateStamps
#-XX:+PrintClassHistogram
#-XX:+PrintTenuringDistribution
#-XX:+PrintGCApplicationStoppedTime
#-Xloggc:${loggc} #将GC状态记录到带有时间戳的文件，确保该目录存在
#默认情况下，GC日志文件不会旋转。通过取消注释下面的行，GC日志文件将每128MB旋转至多32次。
#-XX:+UseGCLogFileRotation
#-XX:NumberOfGCLogFiles=32
#-XX:GCLogFileSize=128M# cat /opt/elk/elasticsearch/config/log4j2.properties #部分内容解释不用修改
######## Server JSON ############################
appender.rolling.type = RollingFile #配置RollingFile的appender属性。
appender.rolling.name = rolling
appender.rolling.fileName = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}_server.json #日志信息输出文件
appender.rolling.layout.type = ESJsonLayout #使用JSON格式输出
appender.rolling.layout.type_name = server #type_name是填充ESJsonLayout的类型字段的标志
appender.rolling.filePattern = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}-%d{yyyy-MM-dd}-%i.json.gz #将日志滚动输出到/var/log/elasticsearch/production-yyyy-MM-dd-i.json文件。日志文件会被压缩处理，i呈递增状态。
appender.rolling.policies.type = Policies
appender.rolling.policies.time.type = TimeBasedTriggeringPolicy #使用基于时间戳的新增日志滚动策略。
appender.rolling.policies.time.interval = 1 #按天滚动新增日志
appender.rolling.policies.time.modulate = true #在日期时间上对齐标准，而不是按每24小时来新增一次滚动日志文件。
appender.rolling.policies.size.type = SizeBasedTriggeringPolicy #按日志文件大小的策略来滚动新增日志文件。
appender.rolling.policies.size.size = 256MB #每生成256MB的日志文件，就滚动新增日志一次。
appender.rolling.strategy.type = DefaultRolloverStrategy
appender.rolling.strategy.fileIndex = nomax
appender.rolling.strategy.action.type = Delete #每次新增滚动日志时执行删除日志文件动作
appender.rolling.strategy.action.basepath = ${sys:es.logs.base_path}
appender.rolling.strategy.action.condition.type = IfFileName #仅当文件匹配时才删除日志文件。
appender.rolling.strategy.action.condition.glob = ${sys:es.logs.cluster_name}-* #该配置仅用于删除日志文件。
appender.rolling.strategy.action.condition.nested_condition.type = IfAccumulatedFileSize #只有当日志目录下积累了较多日志时才删除。
appender.rolling.strategy.action.condition.nested_condition.exceeds = 2GB #压缩日志的条件是日志文件大小达到2GB。2.4 分发配置文件，启动服务测试
elasticsearch.yml #把配置好的配置文件分发到其他节点，只更改node.name:和network.host:，都改成自己的IP地址。
#su -elk
$ ./elasticsearch/bin/elasticsearch #先这样启动一下查看一下输出，当启动第一台和第二台的时候
[2017-12-05T17:36:00,840][INFO ][o.e.n.Node ] [192.168.14.61] initializing ...
[2017-12-05T17:36:00,963][INFO ][o.e.e.NodeEnvironment ] [192.168.14.61] using [1] data paths, mounts [[/data (/dev/vdb)]], net usable_space [499.7gb], net total_space [499.7gb], types [xfs]
[2017-12-05T17:36:00,964][INFO ][o.e.e.NodeEnvironment ] [192.168.14.61] heap size [3.9gb], compressed ordinary object pointers [true]
[2017-12-05T17:36:00,965][INFO ][o.e.n.Node ] [192.168.14.61] node name [192.168.14.61], node ID [m2hHFiC_RLKQmkrWdPR9RQ]
[2017-12-05T17:36:00,965][INFO ][o.e.n.Node ] [192.168.14.61] version[6.0.0], pid[1865], build[8f0685b/2017-11-10T18:41:22.859Z], OS[Linux/3.10.0-327.el7.x86_64/amd64], JVM[Oracle Corporation/Java HotSpot(TM) 64-Bit Server VM/1.8.0_74/25.74-b02]
[2017-12-05T17:36:00,966][INFO ][o.e.n.Node ] [192.168.14.61] JVM arguments [-Xms4g, -Xmx4g, -XX:+UseConcMarkSweepGC, -XX:CMSInitiatingOccupancyFraction=75, -XX:+UseCMSInitiatingOccupancyOnly, -XX:+AlwaysPreTouch, -Xss1m, -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true, -XX:-OmitStackTraceInFastThrow, -Dio.netty.noUnsafe=true, -Dio.netty.noKeySetOptimization=true, -Dio.netty.recycler.maxCapacityPerThread=0, -Dlog4j.shutdownHookEnabled=false, -Dlog4j2.disable.jmx=true, -XX:+HeapDumpOnOutOfMemoryError, -Des.path.home=/home/elk/elasticsearch, -Des.path.conf=/home/elk/elasticsearch/config]
[2017-12-05T17:36:02,260][INFO ][o.e.p.PluginsService ] [192.168.14.61] loaded module [aggs-matrix-stats]
[2017-12-05T17:36:02,261][INFO ][o.e.p.PluginsService ] [192.168.14.61] loaded module [analysis-common]
[2017-12-05T17:36:02,261][INFO ][o.e.p.PluginsService ] [192.168.14.61] loaded module [ingest-common]
[2017-12-05T17:36:02,262][INFO ][o.e.p.PluginsService ] [192.168.14.61] loaded module [lang-expression]
[2017-12-05T17:36:02,262][INFO ][o.e.p.PluginsService ] [192.168.14.61] loaded module [lang-mustache]
[2017-12-05T17:36:02,262][INFO ][o.e.p.PluginsService ] [192.168.14.61] loaded module [lang-painless]
[2017-12-05T17:36:02,262][INFO ][o.e.p.PluginsService ] [192.168.14.61] loaded module [parent-join]
[2017-12-05T17:36:02,262][INFO ][o.e.p.PluginsService ] [192.168.14.61] loaded module [percolator]
[2017-12-05T17:36:02,263][INFO ][o.e.p.PluginsService ] [192.168.14.61] loaded module [reindex]
[2017-12-05T17:36:02,263][INFO ][o.e.p.PluginsService ] [192.168.14.61] loaded module [repository-url]
[2017-12-05T17:36:02,263][INFO ][o.e.p.PluginsService ] [192.168.14.61] loaded module [transport-netty4]
[2017-12-05T17:36:02,263][INFO ][o.e.p.PluginsService ] [192.168.14.61] loaded module [tribe]
[2017-12-05T17:36:02,264][INFO ][o.e.p.PluginsService ] [192.168.14.61] no plugins loaded
[2017-12-05T17:36:04,421][INFO ][o.e.d.DiscoveryModule ] [192.168.14.61] using discovery type [zen]
[2017-12-05T17:36:05,088][INFO ][o.e.n.Node ] [192.168.14.61] initialized
[2017-12-05T17:36:05,089][INFO ][o.e.n.Node ] [192.168.14.61] starting ...
[2017-12-05T17:36:05,451][INFO ][o.e.t.TransportService ] [192.168.14.61] publish_address {192.168.14.61:9300}, bound_addresses {192.168.14.61:9300}
[2017-12-05T17:36:05,476][INFO ][o.e.b.BootstrapChecks ] [192.168.14.61] bound or publishing to a non-loopback or non-link-local address, enforcing bootstrap checks
[2017-12-05T17:36:08,537][WARN ][o.e.d.z.ZenDiscovery ] [192.168.14.61] not enough master nodes discovered during pinging (found [[Candidate{node={192.168.14.61}{m2hHFiC_RLKQmkrWdPR9RQ}{kvG6Tp3BSzqSpb4UpMEYlw}{192.168.14.61}{192.168.14.61:9300}, clusterStateVersion=-1}]], but needed [3]), pinging again
[2017-12-05T17:36:11,540][WARN ][o.e.d.z.ZenDiscovery ] [192.168.14.61] not enough master nodes discovered during pinging (found [[Candidate{node={192.168.14.61}{m2hHFiC_RLKQmkrWdPR9RQ}{kvG6Tp3BSzqSpb4UpMEYlw}{192.168.14.61}{192.168.14.61:9300}, clusterStateVersion=-1}]], but needed [3]), pinging again#这是提示找不到足够的节点应该是3个节点。
$ ./elasticsearch/bin/elasticsearch #当启动第三个节点的时候，只粘贴最后了
[2017-12-05T17:38:50,220][INFO ][o.e.t.TransportService ] [192.168.14.63] publish_address {192.168.14.63:9300}, bound_addresses {192.168.14.63:9300}
[2017-12-05T17:38:50,232][INFO ][o.e.b.BootstrapChecks ] [192.168.14.63] bound or publishing to a non-loopback or non-link-local address, enforcing bootstrap checks
[2017-12-05T17:38:53,663][INFO ][o.e.c.s.ClusterApplierService] [192.168.14.63] detected_master {192.168.14.62}{Sfb-mx0ZQRuaVGmyPFYAMw}{ItmxWGuUSOWsQtMf4E-yQQ}{192.168.14.62}{192.168.14.62:9300}, added {{192.168.14.61}{m2hHFiC_RLKQmkrWdPR9RQ}{kvG6Tp3BSzqSpb4UpMEYlw}{192.168.14.61}{192.168.14.61:9300},{192.168.14.62}{Sfb-mx0ZQRuaVGmyPFYAMw}{ItmxWGuUSOWsQtMf4E-yQQ}{192.168.14.62}{192.168.14.62:9300},}, reason: apply cluster state (from master [master {192.168.14.62}{Sfb-mx0ZQRuaVGmyPFYAMw}{ItmxWGuUSOWsQtMf4E-yQQ}{192.168.14.62}{192.168.14.62:9300} committed version [1]])
[2017-12-05T17:38:53,722][INFO ][o.e.h.n.Netty4HttpServerTransport] [192.168.14.63] publish_address {192.168.14.63:9200}, bound_addresses {192.168.14.63:9200}
[2017-12-05T17:38:53,722][INFO ][o.e.n.Node ] [192.168.14.63] started#可以了不会再提示节点不够了。
博文来自：www.51niux.com
#测试完毕，下面我们正常的启动一波：
$/home/elk/elasticsearch/bin/elasticsearch -d #所有节点用elk用户启动服务，后台运行，现在就要看日志看看有什么问题了。root用户启动会报错的得非root用户启动。
$ tail -f /data/es/log/elasticsearch_51niux.log #如我们查看一下日志，下面日志可以看出没有什么报错信息。
[2017-12-05T17:45:35,627][INFO ][o.e.c.s.ClusterApplierService] [192.168.14.60] detected_master {192.168.14.62}{Sfb-mx0ZQRuaVGmyPFYAMw}{hNvxLJucQQCGn7doe42pgQ}{192.168.14.62}{192.168.14.62:9300}, added {{192.168.14.62}{Sfb-mx0ZQRuaVGmyPFYAMw}{hNvxLJucQQCGn7doe42pgQ}{192.168.14.62}{192.168.14.62:9300},{192.168.14.61}{m2hHFiC_RLKQmkrWdPR9RQ}{kyBZF59ESyKbzPKYloPuEw}{192.168.14.61}{192.168.14.61:9300},}, reason: apply cluster state (from master [master {192.168.14.62}{Sfb-mx0ZQRuaVGmyPFYAMw}{hNvxLJucQQCGn7doe42pgQ}{192.168.14.62}{192.168.14.62:9300} committed version [1]])
[2017-12-05T17:45:35,670][INFO ][o.e.h.n.Netty4HttpServerTransport] [192.168.14.60] publish_address {192.168.14.60:9200}, bound_addresses {192.168.14.60:9200}
[2017-12-05T17:45:35,670][INFO ][o.e.n.Node ] [192.168.14.60] started
[2017-12-05T17:45:36,565][INFO ][o.e.c.s.ClusterApplierService] [192.168.14.60] added {{192.168.14.63}{in4VbJUfRa-mcFuzSD3sxA}{zuUBpDZMSbmNtImZDGvNSQ}{192.168.14.63}{192.168.14.63:9300},}, reason: apply cluster state (from master [master {192.168.14.62}{Sfb-mx0ZQRuaVGmyPFYAMw}{hNvxLJucQQCGn7doe42pgQ}{192.168.14.62}{192.168.14.62:9300} committed version [3]])2.5 测试并查看
$ netstat -lntup|grep java
tcp6 0 0 192.168.14.60:9200 :::* LISTEN 992/java #对外服务的http端口，默认就是9200 tcp6 0 0 192.168.14.60:9300 :::* LISTEN 992/java #节点间交互的tcp端口
#每个节点都可以通过：IP：9200端口查看的，如下图：
http://192.168.14.60:9200/_nodes #可以看到所有节点的json信息，信息太多了就不全贴了
# lsof -i :9300 #每个节点都跟其他节点进行着连接
博文来自：www.51niux.com
#Elasticsearch的版本号从2直接升到5是怎么回事呢？之前各组件之间版本不统一,2016年V5.0版本的Elastic Stack面世之前,Kibana版本号已经是4.x了，其下个版本只能是5.0。
三、插件安装
3.1 插件简介
Elasticsearch插件类型包含jar文件、脚本和配置文件，插件必须安装在集群中的每个节点上才能使用。安装插件后，必须重新启动每个节点，才能看到插件。在Elasticsearch官网上，插件被归纳为两大类，分别是核心插件和社区贡献插件。
社区贡献插件属于Elasticsearch项目外部的插件。核心插件属于Elasticsearch项目，插件与Elasticsearch安装包同时提供，插件的版本号始终与Elasticsearch安装包的版本号相同。这些插件是由Elasticsearch团队维护的。核心插件列表：https://github.com/elastic/elasticsearch/tree/master/plugins
#elasticsearch/bin/elasticsearch-plugin -h #此命令用于插件的安装、查看和删除,更新插件的就需要remove插件再安装,因为插件是为特定版本的elasticsearch构建的。remoce插件需要重启节点完成迁移过程,在删除插件的时候希望清楚磁盘上的插件配置文件可以使用-p或--purge命令。
# elasticsearch/bin/elasticsearch-plugin install analysis-icu #比如安装一个核心库
# elasticsearch/bin/elasticsearch-plugin list #可以使用list命令检索当前加载插件的列表
3.2 安装Head插件
ElasticSearch-Head 是一个与Elastic集群（Cluster）相交互的Web前台。
ES-Head的主要作用：
它展现ES集群的拓扑结构，并且可以通过它来进行索引（Index）和节点（Node）级别的操作 它提供一组针对集群的查询API，并将结果以json和表格形式返回 它提供一些快捷菜单，用以展现集群的各种状态
5.x以后的版本安装Head插件比较麻烦，不能像2.x的时候一条#elasticsearch/bin/plugin install mobz/elasticsearch-head #一波搞定
安装Node.js
#由于head插件本质上还是一个nodejs的工程，因此需要安装node，使用npm来安装依赖的包。（npm可以理解为maven），官网nodejs，https://nodejs.org/en/download/
#wget https://nodejs.org/dist/v8.9.1/node-v8.9.1.tar.gz #新版要编译时间太长了用旧版本吧
# tar zxf node-v8.9.1.tar.gz
#cd node-v8.9.1
#./configure --prefix=/usr/local/node-8.9.1 && make -j 8 && make install #安装时间比较长，没办法，Centos7的系统要最新版本的nodejs。
# ln -s /usr/local/node-v6.10.2-linux-x64 /usr/local/node
# vim /etc/profile
############nodejs#################### export NODE_HOME=/usr/local/node export PATH=$PATH:$NODE_HOME/bin
# source /etc/profile
# node -v
v8.9.1
# npm -v
5.5.1
下载插件包
# yum install git -y
# git clone https://github.com/mobz/elasticsearch-head.git #下载head插件文件
# cd elasticsearch-head/
# npm install -g grunt --registry=https://registry.npm.taobao.org
#使用国内淘宝源安装grunt，grunt是基于Node.js的项目构建工具，可以进行打包压缩、测试、执行等等的工作，head插件就是通过grunt启动
npm WARN deprecated coffee-script@1.10.0: CoffeeScript on NPM has moved to "coffeescript" (no hyphen) /usr/local/node-8.9.1/bin/grunt -> /usr/local/node-8.9.1/lib/node_modules/grunt/bin/grunt + grunt@1.0.1 added 92 packages in 10.604s
# ls -d node_modules/grunt
node_modules/grunt #如果没产生此目录需要：#cd elasticsearch-head && npm install grunt --save
安装Head插件
# npm install -g grunt-cli --registry=https://registry.npm.taobao.org
# npm install --registry=https://registry.npm.taobao.org #安装head插件
修改配置文件
# mkdir /home/elk/plugin
# cp -rf /opt/elasticsearch-head /home/elk/plugin/head
# chown -R elk:elk /home/elk
$ vim /home/elk/plugin/head/Gruntfile.js
connect: {
server: {
options: {
port: 9100,
hostname: '*', #增加此行
base: '.',
keepalive: true$ vim /home/elk/plugin/head/_site/app.js
this.base_uri = this.config.base_uri || this.prefs.get("app-base_uri") || "http://192.168.14.60:9200"; #这里改成es的IP和端口
$ cd /home/elk/plugin/head/ #一定要进入此目录下启动命令啊
$ grunt server #服务启动了
>> Local Npm module "grunt-contrib-jasmine" not found. Is it installed? (node:1446) ExperimentalWarning: The http2 module is an experimental API. Running "connect:server" (connect) task Waiting forever... Started connect web server on http://localhost:9100
#访问IP:9100的端口可以看到Web页面出来了，但是还是未连接。
博文来自：www.51niux.com
解决使用 Head 插件连接不上集群：
$ vim elasticsearch/config/elasticsearch.yml #加下面两句话,就是开启支持跨域
http.cors.enabled: true http.cors.allow-origin: "*"
$ /home/elk/elasticsearch/bin/elasticsearch -d #重新启动es服务
$ pwd
/home/elk/plugin/head
$ nohup grunt server & #重新后台运行head插件服务,这个要注意，一定要在插件也就是上方的目录的根目录下，执行此条命令才可以。
#再次访问web浏览器已经可以了。带有星星标记的表示是主节点。
#重点是要使用的电脑要访问上面显示的ES的IP:端口,如果你访问不通head插件那里还是会提示未连接。
3.3 Head插件的简单使用
概览：
右上角有个刷新按钮,用户可以选择手动刷新、快速刷新、每5秒刷新或每1分钟刷新。
右上角刷新的上面有个"信息"按钮，可以看到Elasticsearch相关的信息，包括集群节点信息、节点状态、集群状态、集群信息、集群健康值等内容。单击对应的按钮，即可查看对应的信息。
等有了数据可以在集群概览的下方看到集群信息汇总。可以看到Elasticsearch已经创建的索引，这些索引信息包含了索引的名称、索引的大小和索引的数据量，并且通过“信息”和“动作”两个按钮可以查看索引信息，或者给索引创建别名。"信息"可以看索引状态和索引信息,"动作"有新建别名、网管快照、关闭等功能。
#如果安装可kopf监控插件的话，访问链接就是：http://192.168.14.60:9200/_plugin/kopf/#!/cluster #可以看到java的堆内存节点空间占用等等。
索引：
切换到"索引"标签页,可以查看当前Elasticsearch集群中的索引情况。做左下方也可以基于字段进行数据筛选。
数据浏览：
切换到“数据浏览”标签页，可以查看特定索引下的存储数据。
基本查询：
切换到“基本查询”标签页，用自由拼接条件进行简单的数据查询。term表示的是精确匹配，wildcard表示的是通配符匹配，prefix表示的是前缀匹配，range表示的是区间查询。“+”“-”按钮用于增加查询条件或减少查询条件。"返回格式"有Table、JSON、CSV三种方式。
复合查询：
可以自由拼接条件，进行复杂的数据查询。“复合查询”为用户提供了编写RESTful接口风格的请求，用户可以使用JSON进行复杂的查询，比如发送PUT请求新增及更新索引，使用delete请求删除索引等。总之，在“复合查询”页面，用户可对Elasticsearch中的数据或者索引进行各种增删改查等操作请求。
注意，由于Head插件可以对数据进行增删改查，实际开发过程中尽量不要使用，如果要用的话至少要限制来源IP地址。
博文来自：www.51niux.com
3.4 安装cerebro插件
#https://github.com/lmenezes/elasticsearch-kopf #有安装步骤介绍
#不过kopf已经不维护了，被cerebro所替代了，https://github.com/lmenezes/cerebro/releases #这个链接可以选择要下载的版本。
Cerebro插件是插件工具kopf的升级版本。Cerebro插件中包含了kopf的功能，如监控工具，并包含了Head插件的部分功能，可以图形化地进行新建索引等操作。
# wget https://github.com/lmenezes/cerebro/releases/download/v0.9.4/cerebro-0.9.4.tgz
# tar zxf cerebro-0.9.4.tgz
# cd cerebro-0.9.4
# vim conf/application.conf
hosts = [
{
host = "http://192.168.14.60:9200"
name = "elasticsearch_51niux"
headers-whitelist = [ "x-proxy-user", "x-proxy-roles", "X-Forwarded-For" ]
}#nohup ./bin/cerebro -Dhttp.port=9000 -Dhttp.address=0.0.0.0 &>/dev/null & #默认也是9000端口,其实也不用加这么多参数列下而已
#然后通过IP:端口或者浏览器访问指定域名：
Cerebro首页中有“Overview”、“nodes”、“rest”和“more”四个标签页。默认当前是“Overview”页面。在“Overview”页面中，可以看到Elasticsearch集群的各个Node节点的详细信息。该标签页分为三部分，顶端的线条、Elasticsearch集群内各种信息的统计、各个节点的信息。其中：
（1）顶端的线条：颜色释义与Head插件中的颜色释义相同，共绿色、红色、黄色三种，绿色代表集群工作正常。 （2）Elasticsearch集群内各种信息的统计：包括集群名称、节点数量、索引数量、分片数量、文档数量和索引所占存储空间的大小等信息。 （3）各个节点的信息：在最下方表格中，每行代表一个节点，每列代表一个索引。
如上图单击某个索引，即可查看该索引下的信息。
"Nodes”选项卡，可以看到各节点的资源使用情况.各节点的资源使用情况主要有CPU、堆、磁盘使用、服务运行时间等。
"Rest”选项卡，用户可以向Elasticsearch集群发出RESTful格式的API请求。
关于Elasticsearch第一部分集群的简单搭建就介绍到这里。
https://www.cnblogs.com/kevingrace/p/5919021.html #关于上面提到的这两个插件这个链接写的很详细记录一下
四、设置Elasticsearch(翻译官网部分可忽略)
4.1 安全配置
有些设置是敏感的，依靠文件系统权限来保护它们的值是不够的。 对于这个用例，Elasticsearch提供了一个可以用密码保护的keystore，以及一个用来管理keystore中的设置的elasticsearch-keystore工具。
这里的所有命令都应该以运行Elasticsearch的用户身份运行。只有一些设置被设计为从密钥库中读取。 查看每个设置的文档，看它是否作为密钥库的一部分受支持。所有对密钥库的修改只有在重新启动Elasticsearch之后才会生效。
创建keystore：
bin/elasticsearch-keystore create #elasticsearch.keystore文件将与elasticsearch.yml一起创建。
列出密钥库中的设置：
bin/elasticsearch-keystore list
添加字符串设置：
bin/elasticsearch-keystore add the.setting.name.to.set #可以使用add命令添加敏感的字符串设置
该工具将提示输入设置的值。 要通过stdin传递值，请使用--stdin标志：
cat /file/containing/setting/value | bin/elasticsearch-keystore add --stdin the.setting.name.to.set
删除设置：
bin/elasticsearch-keystore remove the.setting.name.to.remove #要从密钥库中删除设置，请使用remove命令
4.2 日志设置
Elasticsearch使用Log4j 2进行日志记录。 Log4j 2可以使用log4j2.properties文件进行配置。
Elasticsearch公开了三个属性${sys:es.logs.base_path}, ${sys:es.logs.cluster_name}, and ${sys:es.logs.node_name}（如果节点名是通过node.name显式设置的 ）可以在配置文件中引用来确定日志文件的位置。 属性${sys:es.logs.base_path}将解析为日志目录，${sys：es.logs.cluster_name}将解析为集群名称（在默认配置中用作日志文件名的前缀），以及 ${sys:es.logs.node_name}将解析为节点名称（如果节点名称已明确设置）。
例如，如果你的日志目录path.logs是/var/log/elasticsearch，并且你的集群命名为production，则$ {sys:es.logs.base_path}将解为/var/log/elasticsearch和${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}.log将解析为/var/log/elasticsearch/production.log。
appender.rolling.type = RollingFile
#配置RollingFile appender
appender.rolling.name = rolling
appender.rolling.fileName = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}.log
#日志位置
appender.rolling.layout.type = PatternLayout
appender.rolling.layout.pattern = [%d{ISO8601}][%-5p][%-25c{1.}] %marker%.-10000m%n
appender.rolling.filePattern = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}-%d{yyyy-MM-dd}-%i.log.gz
#将日志滚动到/var/log/elasticsearch/production-yyyy-MM-dd-i.log，每次滚动日志都会被压缩，i会增加。
appender.rolling.policies.type = Policies
appender.rolling.policies.time.type = TimeBasedTriggeringPolicy
#使用基于时间的滚动策略
appender.rolling.policies.time.interval = 1
#每天滚动日志
appender.rolling.policies.time.modulate = true
#在日边界上对齐滚动（而不是每24小时滚动一次）
appender.rolling.policies.size.type = SizeBasedTriggeringPolicy
#使用基于size的滚动策略
appender.rolling.policies.size.size = 256MB
#在256 MB之后滚动日志
appender.rolling.strategy.type = DefaultRolloverStrategy
appender.rolling.strategy.fileIndex = nomax
appender.rolling.strategy.action.type = Delete
#滚动日志时使用删除操作
appender.rolling.strategy.action.basepath = ${sys:es.logs.base_path}
appender.rolling.strategy.action.condition.type = IfFileName
#只删除匹配文件模式的日志
appender.rolling.strategy.action.condition.glob = ${sys:es.logs.cluster_name}-*
#模式是只删除主日志
appender.rolling.strategy.action.condition.nested_condition.type = IfAccumulatedFileSize
#只有当我们累积了太多的压缩日志时才删除
appender.rolling.strategy.action.condition.nested_condition.exceeds = 2GB
#压缩日志上的大小条件是2 GB#注：Log4j的配置分析会被任何无关的空白混淆; 如果你在本页面上复制并粘贴任何Log4j设置，或者一般输入任何Log4j配置，请务必修剪任何前导和尾随空格。
#请注意，你可以用appender.rolling.filePattern中的.zip替换.gz以压缩使用zip格式的滚动日志。 如果删除.gz扩展名，则日志在滚动时不会被压缩。
如果要在指定的时间段内保留日志文件，则可以使用带有删除操作的滚动策略：
appender.rolling.strategy.type = DefaultRolloverStrategy
#配置DefaultRolloverStrategy
appender.rolling.strategy.action.type = Delete
#配置用于处理rollover的删除操作
appender.rolling.strategy.action.basepath = ${sys:es.logs.base_path}
#Elasticsearch日志的基本路径
appender.rolling.strategy.action.condition.type = IfFileName
#在处理滚动时应用的条件
appender.rolling.strategy.action.condition.glob = ${sys:es.logs.cluster_name}-*
#从匹配glob ${sys:es.logs.cluster_name}-*; 的基本路径中删除文件 - *; 这是日志文件滚动到的glob; 只需要删除滚动的Elasticsearch日志，而不是删除弃用和慢日志
appender.rolling.strategy.action.condition.nested_condition.type = IfLastModified
#嵌套的条件适用于与glob匹配的文件
appender.rolling.strategy.action.condition.nested_condition.age = 7D
#保留七天的日志只要将多个配置文件命名为log4j2.properties并将Elasticsearch config目录作为父目录，就可以加载多个配置文件（在这种情况下，它们将被合并） 这对于公开额外记录器的插件是有用的。 记录器部分包含java包及其相应的日志级别。 appender部分包含日志的目的地。 有关如何自定义日志记录以及所有支持的appender的详细信息可以在Log4j文档中找到：http://logging.apache.org/log4j/2.x/manual/configuration.html
配置日志级别：
有四种方法来配置日志记录级别，每种方式都适合使用。
1. 通过命令行：-E <日志层次结构的名称> = <level>（例如，-E logger.org.elasticsearch.transport = trace）。 当你临时调试单个节点上的问题（例如启动问题或开发期间）时，这是最合适的。
2. 通过elasticsearch.yml：<记录层次结构的名称>：<level>（例如，logger.org.elasticsearch.transport：trace）。 当你临时调试一个问题，但不是通过命令行（例如，通过服务）启动Elasticsearch，或者你想要一个更加永久的基础上调整日志级别时，这是最合适的。
3. 通过集群设置：
PUT /_cluster/settings
{
"transient": {
"<name of logging hierarchy>": "<level>"
}
}
#例如：
PUT /_cluster/settings
{
"transient": {
"logger.org.elasticsearch.transport": "trace"
}
}
#当你需要动态调整正在运行的群集上的日志记录级别时，这是最合适的。4. 通过log4j2.properties：
logger.<unique_identifier>.name = <name of logging hierarchy> logger.<unique_identifier>.level = <level> #例如 logger.transport.name = org.elasticsearch.transport logger.transport.level = trace
#当你需要对记录器进行细粒度的控制时（例如，要将记录器发送到另一个文件或以不同的方式管理记录器，这是非常罕见的用例）。
4.3 重要的Elasticsearch配置
虽然Elasticsearch只需要很少的配置，但有一些需要手动配置的设置，在投入生产之前一定要进行配置。
path.data and path.logs
如果使用.zip或.tar.gz安装，则数据和日志目录是$ES_HOME的子文件夹。 如果这些重要文件夹保留在其默认位置，则在将Elasticsearch升级到新版本时，这些文件夹被删除的风险很高。在生产使用中，几乎可以肯定地要更改数据和日志文件夹的位置：
path: logs: /var/log/elasticsearch data: /var/data/elasticsearch
path.data设置可以设置为多个路径，在这种情况下，所有路径将用于存储数据（尽管属于单个分片的文件将全部存储在相同的数据路径中）：
path: data: - /mnt/elasticsearch_1 - /mnt/elasticsearch_2 - /mnt/elasticsearch_3
cluster.name
节点只能在与集群中的所有其他节点共享cluster.name时才能加入集群。 默认名称是elasticsearch，但是应该将其更改为描述集群用途的适当名称。
cluster.name: logging-prod
#确保不要在不同的环境中重复使用相同的群集名称，否则可能会导致节点加入错误的群集。
node.name
默认情况下，Elasticsearch将随机生成的uuid的第一个字符作为节点ID。 请注意，节点ID是持久的，并且在节点重新启动时不会更改，因此默认节点名称也不会更改。值得配置一个更有意义的名字，这个名字在重启节点后也会有持久的优势：
node.name: prod-data-2
node.name也可以设置为服务器的HOSTNAME，如下所示：
node.name: ${HOSTNAME}bootstrap.memory_lock
对于你的节点的健康状况来说，没有任何一个JVM被换出到磁盘上，这一点非常重要。 一种实现方法是将bootstrap.memory_lock设置为true。
要使此设置生效，需要首先配置其他系统设置。 有关如何正确设置内存锁定的更多详细信息，请参阅启用bootstrap.memory_lock：https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-configuration-memory.html#mlockall
network.host
默认情况下，Elasticsearch只绑定到回环地址 - 例如 127.0.0.1和[:: 1]。 这足以在服务器上运行单个开发节点。实际上，可以从一个节点上的同一$ES_HOME位置启动多个节点。 这可以用于测试Elasticsearch形成群集的能力，但它不是推荐用于生产的配置。
为了与其他服务器上的节点进行通信并形成群集，你的节点将需要绑定到非环回地址。 虽然有很多的网络设置，通常你只需要配置network.host：
network.host: 192.168.1.10
#network.host设置还可以理解一些特殊的值，如_local_，_site_，_global_和修饰符如：ip4和：ip6，其详细信息可以在network.hostedit的特殊值中找到：https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-network.html#network-interface-values
#只要你为network.host提供自定义设置，Elasticsearch就会假定你正在从开发模式转移到生产模式，并将大量系统启动检查从警告升级到异常。
discovery.zen.ping.unicast.hosts
没有任何网络配置，Elasticsearch将绑定到可用的环回地址，并将扫描端口9300到9305，尝试连接到运行在同一台服务器上的其他节点。 这提供了自动集群体验，而无需进行任何配置。
当需要与其他服务器上的节点组成群集时，你必须提供群集中其他节点的种子列表，这些节点可能是活的和可联系的。 这可以指定如下：
discovery.zen.ping.unicast.hosts: - 192.168.1.10:9300 - 192.168.1.11 #如果未指定，端口将默认为transport.profiles.default.port，并回退到transport.tcp.port。 - seeds.mydomain.com #解析为多个IP地址的主机名将尝试所有解析的地址。
discovery.zen.minimum_master_nodes
为防止数据丢失，配置discovery.zen.minimum_master_nodes设置至关重要，以便每个符合主节点的节点都知道为了形成群集而必须可见的主节点的最小数量。
如果没有这个设置，那么遭受网络故障的集群就有可能将集群分成两个独立的集群 - 分裂的大脑 - 这将导致数据丢失。 在使用minimum_master_nodesedit避免分裂脑中提供了更详细的解释：https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html#split-brain
为了避免脑裂，应将此设置设置为符合主数据节点的法定人数：
(master_eligible_nodes / 2) + 1 #换句话说，如果有三个主节点，那么最小主节点应该设置为（3/2）+ 1或2： discovery.zen.minimum_master_nodes: 2
4.4 重要的系统配置
理想情况下，Elasticsearch应该在服务器上独立运行，并使用所有可用的资源。 为此，你需要配置您的操作系统，以允许运行Elasticsearch的用户访问比默认允许的资源更多的资源。在投入生产环境之前，必须解决以下设置：
配置系统设置
#这个就不记录了搭建的时候已经解决了：https://www.elastic.co/guide/en/elasticsearch/reference/current/setting-system-settings.html
通过jvm.options设置JVM堆大小
#官网链接：https://www.elastic.co/guide/en/elasticsearch/reference/current/heap-size.html
禁用swap分区
官网链接：https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-configuration-memory.html
文件描述符
链接：https://www.elastic.co/guide/en/elasticsearch/reference/current/file-descriptors.html
虚拟内存
链接：https://www.elastic.co/guide/en/elasticsearch/reference/current/vm-max-map-count.html
线程数：
链接：https://www.elastic.co/guide/en/elasticsearch/reference/current/max-number-of-threads.html
DNS缓存设置：
链接：https://www.elastic.co/guide/en/elasticsearch/reference/current/networkaddress-cache-ttl.html
4.5 引导程序检查
官网链接：https://www.elastic.co/guide/en/elasticsearch/reference/current/bootstrap-checks.html
堆大小检查 文件描述符检查 内存锁定检查 最大线程数 虚拟内存最大尺寸检查 最大文件尺寸检查 最大地图计数检查 客户机JVM检查 使用串行收集器检查 系统调用过滤器检查 OnError和OnOutOfMemoryError检查 早期访问检查 G1GC检查
Stopping Elasticsearch:
通过指定启动时写入PID文件的位置（-p <path>）：
$ ./bin/elasticsearch -p /tmp/elasticsearch-pid -d $ cat /tmp/elasticsearch-pid && echo 15516 $ kill -SIGTERM 15516
停止致命的错误编辑
在Elasticsearch虚拟机的生命周期中，可能会出现某些致使虚拟机处于可疑状态的致命错误。 这种致命错误包括内存不足错误，虚拟机中的内部错误以及严重的I/O错误。
当Elasticsearch检测到虚拟机遇到这样的致命错误时，Elasticsearch将尝试记录错误，然后暂停虚拟机。 当Elasticsearch发起这样的关闭时，它不会像上面描述的那样经过有序的关闭。 Elasticsearch进程也将返回一个特殊的状态码，指明错误的性质。
JVM internal error #128 Out of memory error #127 Stack overflow error #126 Unknown virtual machine error #125 Serious I/O error #124 Unknown fatal error #1
