elk日志分析系统，在生产环境中一般搭建集群，来满足大数据量的查询分析
下面就说说集群的搭建：
集群的搭建主要还是配置文件的修改：
主要配置文件修改项：
cluster.name: baichebao-cluster
这个是配置集群的名字，为了能进行自动查找
node.name: "baichebao-node-1"
这个是配置当前节点的名字，当然每个节点的名字都应该是唯一的
node.master: false
node.data: true
这两个配置有4种配置方法，表示这个节点是否可以充当主节点，这个节点是否充当数据节点。
如果你的节点数目只有两个的话，为了防止脑裂的情况，需要手动设置主节点和数据节点。其他情况建议直接不设置，默认两个都为true.
network.host: "0.0.0.0"
绑定host，0.0.0.0代表所有IP，为了安全考虑，建议设置为内网IP
transport.tcp.port: 10800
节点到节点之间的交互是使用tcp的，这个设置设置启用的端口
http.port: 9700
这个是对外提供http服务的端口，安全考虑，建议修改，不用默认的9200
discovery.zen.ping.multicast.enabled: false
discovery.zen.fd.ping_timeout: 100s
discovery.zen.ping.timeout: 100s
discovery.zen.minimum_master_nodes: 2
discovery.zen.ping.unicast.hosts: ["12.12.12.12:10801"]
这几个是集群自动发现机制
discovery.zen.ping.multicast.enabled 这个设置把组播的自动发现给关闭了，为了防止其他机器上的节点自动连入。
discovery.zen.fd.ping_timeout和discovery.zen.ping.timeout是设置了节点与节点之间的连接ping时长
discovery.zen.minimum_master_nodes 这个设置为了避免脑裂。比如3个节点的集群，如果设置为2，那么当一台节点脱离后，不会自动成为master。
discovery.zen.ping.unicast.hosts 这个设置了自动发现的节点。
action.auto_create_index: false
这个关闭了自动创建索引。为的也是安全考虑，否则即使是内网，也有很多扫描程序，一旦开启，扫描程序会自动给你创建很多索引。
在bin/elasticsearch里面增加两行：
ES_HEAP_SIZE=4g
MAX_OPEN_FILES=65535
这两行设置了节点可以使用的内存数和最大打开的文件描述符数。
集群自动选举：
elasticsearch集群一旦建立起来以后，会选举出一个master，其他都为slave节点。
但是具体操作的时候，每个节点都提供写和读的操作。就是说，你不论往哪个节点中做写操作，这个数据也会分配到集群上的所有节点中。
这里有某个节点挂掉的情况，如果是slave节点挂掉了，那么首先关心，数据会不会丢呢？不会。如果你开启了replicate，那么这个数据一定在别的机器上是有备份的。
别的节点上的备份分片会自动升格为这份分片数据的主分片。这里要注意的是这里会有一小段时间的yellow状态时间。
如果是主节点挂掉怎么办呢？当从节点们发现和主节点连接不上了，那么他们会自己决定再选举出一个节点为主节点。
但是这里有个脑裂的问题，假设有5台机器，3台在一个机房，2台在另一个机房，当两个机房之间的联系断了之后，每个机房的节点会自己聚会，推举出一个主节点。
这个时候就有两个主节点存在了，当机房之间的联系恢复了之后，这个时候就会出现数据冲突了。
解决的办法就是设置参数：
discovery.zen.minimum_master_nodes
为3(超过一半的节点数)，那么当两个机房的连接断了之后，就会以大于等于3的机房的master为主，另外一个机房的节点就停止服务了。
自动发现：
elasticsearch的集群是内嵌自动发现功能的。
意思就是说，你只需要在每个节点配置好了集群名称，节点名称，互相通信的节点会根据es自定义的服务发现协议去按照多播的方式来寻找网络上配置在同样集群内的节点。
和其他的服务发现功能一样，es是支持多播和单播的。多播和单播的配置分别根据这几个参数：
discovery.zen.ping.multicast.enabled: false
discovery.zen.fd.ping_timeout: 100s
discovery.zen.ping.timeout: 100s
discovery.zen.minimum_master_nodes: 2
discovery.zen.ping.unicast.hosts: ["12.12.12.12:10801"]
多播是需要看服务器是否支持的，由于其安全性，其实现在基本的云服务（比如阿里云）是不支持多播的，所以即使你开启了多播模式，你也仅仅只能找到本机上的节点。
单播模式安全，也高效，但是缺点就是如果增加了一个新的机器的话，就需要每个节点上进行配置才生效了。
索引分片：
实例中我们创建一个索引dobbyindex.一个索引默认指派5个主分片,实例中我们设定4个主分片和2个复制分片（每个主分片有2个复制分片对应）：
PUT /dobbyindex
{
"settings": {
"number_of_shards": 4,
"number_of_replicas": 2
}
}
索引是一个逻辑命名空间，分片是实际存放数据的容器，一个分片(shard)是一个最小级别的“工作单元(worker unit)”,它只是保存索引中所有数据的一小片.我们的文档存储和被索引在分片中，但是我们的程序不知道如何直接与它们通信。取而代之的是，他们直接与索引通信.Elasticsearch中的分片分为主分片和副本分片,复制分片只是主分片的一个副本，它用于提供数据的冗余副本，在硬件故障之后提供数据保护，同时服务于像搜索和检索等只读请求，主分片的数量和复制分片的数量都可以通过配置文件配置。但是主切片的数量只能在创建索引时定义且不能修改.相同的分片不会放在同一个节点上。
副本分片复制时的相关的参数说明:
replication:
复制默认的值是sync。这将导致主分片得到复制分片的成功响应后才返回，如果你设置replication为async，请求在主分片上被执行后就会返回给客户端。它依旧会转发请求给复制节点，但你将不知道复制节点成功与否。
默认的sync复制允许Elasticsearch强制反馈传输。async复制可能会因为在不等待其它分片就绪的情况下发送过多的请求而使Elasticsearch过载。
consistency:
默认主分片在尝试写入时需要**规定数量(quorum)**或过半的分片（可以是主节点或复制节点）可用。这是防止数据被写入到错的网络分区。规定的数量计算公式如下：
int( (primary + number_of_replicas) / 2 ) + 1
consistency允许的值为one（只有一个主分片），all（所有主分片和复制分片）或者默认的quorum或过半分片。
注意number_of_replicas是在索引中的的设置，用来定义复制分片的数量，而不是现在活动的复制节点的数量。如果你定义了索引有3个复制节点，那规定数量是：int( (primary + 3 replicas) / 2 ) + 1 = 3
但如果你只有2个节点，那你的活动分片不够规定数量，也就不能索引或删除任何文档。
注意: 新索引默认有1个复制分片，这意味着为了满足quorum的要求**需要**两个活动的分片。当然，这个默认设置将阻止我们在单一节点集群中进行操作。为了避开这个问题，规定数量只有在number_of_replicas大于一时才生效。
timeout：
当分片副本不足时Elasticsearch会等待更多的分片出现。默认等待一分钟。如果需要，你可以设置timeout参数让它终止的更早：100表示100毫秒，30s表示30秒。
1)分片算法:
shard = hash(routing) % number_of_primary_shards
routing值是一个任意字符串，它默认是_id但也可以自定义，这个routing字符串通过哈希函数生成一个数字，然后除以主切片的数量得到一个余数(remainder)，余数的范围永远是0到number_of_primary_shards - 1，这个数字就是特定文档所在的分片。
这也解释了为什么主切片的数量只能在创建索引时定义且不能修改：如果主切片的数量在未来改变了，所有先前的路由值就失效了，文档也就永远找不到了。
所有的文档API（get、index、delete、bulk、update、mget）都接收一个routing参数，它用来自定义文档到分片的映射。自定义路由值可以确保所有相关文档.比如用户的文章,按照用户账号路由,就可以实现属于同一用户的文档被保存在同一分片上。
2)分片和副本交互：
新建、索引和删除请求都是写(write)操作，它们必须在主分片上成功完成才能复制到相关的复制分片上,下面我们罗列在主分片和复制分片上成功新建、索引或删除一个文档必要的顺序步骤：
1、客户端给Node 1发送新建、索引或删除请求。
2、节点使用文档的_id确定文档属于分片0。它转发请求到Node 3，分片0位于这个节点上。
3、Node 3在主分片上执行请求，如果成功，它转发请求到相应的位于Node 1和Node 2的复制节点上。当所有的复制节点报告成功，Node 3报告成功到请求的节点，请求的节点再报告给客户端。
客户端接收到成功响应的时候，文档的修改已经被应用于主分片和所有的复制分片。你的修改生效了。
术语解释：
cluster：代表一个集群，集群中有多个节点，其中有一个master节点，master通过选举自动产生；
shards：代表索引分片，ES可以把一个完整的索引分成多个分片，并将它们分布到不同的节点上，从而构成分布式索引；
replicas：代表索引副本，副本可以保证系统的高可用性，当某个节点的某个分片损坏时可以从副本中恢复，此外，多个分片副本还可以起到负载均衡的作用；
recovery：代表数据恢复，ES在有节点加入或退出时会根据机器的负载对索引分片进行重新分配；
river：代表ES的一个数据源，它是以插件方式存在的一个ES服务，通过读取river中的数据并把它索引到ES中，官方的river有couchDB、RabbitMQ、Kafka、 Wikipedia等；
geteway：代表ES索引快照的存储方式，ES默认是把索引存放到内存中，当内存满了再持久化到磁盘。geteway对索引快照进行存储，当这个集群关闭再重新启动时就会从geteway中读取索引备份数据。ES支持多种类型的gateway，如本地文件系统（默认），分布式文件系统（HDFS）；
discovery.zen，ES自动发现节点的机制，ES是一个基于P2P协议的系统，它先通过广播寻找存在的节点，再通过多播协议来进行节点之间的通信，同时也支持点对点的交互；
transport，代表ES内部节点之间或集群与客户端的交互方式，默认使用TCP协议，同时支持HTTP协议（json格式）、thrift、servlet、zeroMQ、memcached等传输协议（通过插件方式集成）；
关于是否锁定内存的问题：
其次elasticsearch还有一个重要的参数bootstrap.mlockall，这个参数的目的是当你无法关闭系统的swap的时候，建议把这个参数设为true。防止在内存不够用的时候，elasticsearch的内存被交换至交换区，导致性能骤降。
建议即便你关闭了系统的swap，也把bootstrap.mlockall设为true
bootstrap.mlockall的作用就是在程序启动的时候先去获取足够大的内存，再加入集群接收请求。没有bootstrap.mlockall的话，elasticsearch一启动就会发现集群接入集群，接收请求，然后JVM一点点的获取系统内存，直到指定值。
如果你有足够大的内存还好，如果没有足够大的内存，因为了elasticsearch引用文件会，系统内存会大量用于系统cache（linux的内存管理机制）。
从程序启动直到JVM获取到指定大小的内存，可能由于系统cache释放缓慢，而导致这个过程非常长，这有可能使你的节点GC非常频繁，从而导致集群不稳定。
所以强烈建议把bootstrap.mlockall设为true，这个值设为true，可能会让节点启动的时候比较慢，但是保证了节点加入集群后的稳定性。
当设置bootstrap.mlockall: true时，启动es报警告Unknown mlockall error 0，因为linux系统默认能让进程锁住的内存为45k。
解决方法：设置为无限制，linux命令：ulimit -l unlimited
3.无法创建本地线程问题
es恢复时报错： RecoverFilesRecoveryException[[index][3] Failed to transfer [215] files with total size of [9.4gb]]; nested: OutOfMemoryError[unable to create new native thread]; ]]
刚开始以为是文件句柄数限制，但想到之前报的是too many open file这个错误，并且也把数据改大了。查资料得知一个进程的jvm进程的最大线程数为：虚拟内存/（堆栈大小*1024*1024），也就是说虚拟内存越大或堆栈越小，能创建的线程越多。重新设置后还是会报那这错，按理说可创建线程数完全够用了的，就想是不是系统的一些限制。后来在网上找到说是max user processes的问题，这个值默认是1024，这个参数单看名字是用户最大打开的进程数，但看官方说明，就是用户最多可创建线程数，因为一个进程最少有一个线程，所以间接影响到最大进程数。调大这个参数后就没有报这个错了。
解决方法：
（1）增大jvm的heap内存或降低xss堆栈大小（默认的是512K）。
（2）打开/etc/security/limits.conf ，把soft nproc 1024这行的1024改大就行了。
2.out of memory错误
因为默认情况下es对字段数据缓存（Field Data Cache）大小是无限制的，查询时会把字段值放到内存，特别是facet查询，对内存要求非常高，它会把结果都放在内存，然后进行排序等操作，一直使用内存，直到内存用完，当内存不够用时就有可能出现out of memory错误。
解决方法：
（1）设置es的缓存类型为Soft Reference，它的主要特点是据有较强的引用功能。只有当内存不够的时候，才进行回收这类内存，因此在内存足够的时候，它们通常不被回收。另外，这些引 用对象还能保证在Java抛出OutOfMemory 异常之前，被设置为null。它可以用于实现一些常用图片的缓存，实现Cache的功能，保证最大限度的使用内存而不引起OutOfMemory。在es的配置文件加上index.cache.field.type: soft即可。
（2）设置es最大缓存数据条数和缓存失效时间，通过设置index.cache.field.max_size: 50000来把缓存field的最大值设置为50000，设置index.cache.field.expire: 10m把过期时间设置成10分钟。
1.由gc引起节点脱离集群
因为gc时会使jvm停止工作，如果某个节点gc时间过长，master ping3次（zen discovery默认ping失败重试3次）不通后就会把该节点剔除出集群，从而导致索引进行重新分配。
解决方法：
（1）优化gc，减少gc时间。（2）调大zen discovery的重试次数（es参数：ping_retries）和超时时间（es参数：ping_timeout）。后来发现根本原因是有个节点的系统所在硬盘满了。导致系统性能下降。