共计 19157 个字符，预计需要花费 48 分钟才能阅读完成。
作者：散尽浮华
原文：https://www.cnblogs.com/kevin…
之前在 IDC 机房环境部署了一套 ELK 日志集中剖析零碎, 这里简略总结下 ELK 中 Elasticsearch 衰弱状态相干问题, Elasticsearch 的索引状态和集群状态传播着不同的意思。
一. Elasticsearch 集群衰弱状态
一个 Elasticsearch 集群至多包含一个节点和一个索引。或者它 可能有一百个数据节点、三个独自的主节点，以及一小打客户端节点——这些独特操作一千个索引（以及上万个分片）。然而不论集群扩大到多大规模，你都会想要一个疾速获取集群状态的路径。Cluster Health API 充当的就是这个角色。你能够把它设想成是在一万英尺的高度鸟瞰集群。它能够通知你安心吧所有都好，或者正告你集群某个中央有问题。Elasticsearch 里其余 API 一样，cluster-health 会返回一个 JSON 响应。这对自动化和告警零碎来说，十分便于解析。响应中蕴含了和你集群无关的一些要害信息:
查看 Elasticsearch 衰弱状态 (* 示意 ES 集群的 master 主节点)
[root@elk-node03 ~]# curl -XGET 'http://10.0.8.47:9200/_cat/nodes?v'
host ip heap.percent ram.percent load node.role master name
10.0.8.47 10.0.8.47 53 85 0.16 d * elk-node03.kevin.cn
10.0.8.44 10.0.8.44 26 54 0.09 d m elk-node01.kevin.cn
10.0.8.45 10.0.8.45 71 81 0.02 d m elk-node02.kevin.cn上面两条 shell 命令都能够监控到 Elasticsearch 衰弱状态
[root@elk-node03 ~]# curl 10.0.8.47:9200/_cat/health
1554792912 14:55:12 kevin-elk green 3 3 4478 2239 0 0 0 0 - 100.0%
[root@elk-node03 ~]# curl -X GET 'http://10.0.8.47:9200/_cluster/health?pretty'
{
"cluster_name" : "kevin-elk", #集群名称
"status" : "green", #为 green 则代表衰弱没问题，如果是 yellow 或者 red 则是集群有问题
"timed_out" : false, #是否有超时
"number_of_nodes" : 3, #集群中的节点数量
"number_of_data_nodes" : 3,
"active_primary_shards" : 2234,
"active_shards" : 4468,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 0,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 100.0 #集群分片的可用性百分比，如果为 0 则示意不可用
}失常状况下，Elasticsearch 集群衰弱状态分为三种：
- green: 最衰弱得状态，阐明所有的分片包含备份都可用; 这种状况 Elasticsearch 集群所有的主分片和正本分片都已调配, Elasticsearch 集群是 100% 可用的。
- yellow : 根本的分片可用，然而备份不可用（或者是没有备份）; 这种状况 Elasticsearch 集群所有的主分片曾经分片了，但至多还有一个正本是缺失的。不会有数据失落，所以搜寻后果仍然是残缺的。不过，你的高可用性在某种程度上被弱化。如果 更多的 分片隐没，你就会丢数据了。把 yellow 设想成一个须要及时考察的正告。
- red: 局部的分片可用，表明分片有一部分损坏。此时执行查问局部数据依然能够查到，遇到这种状况，还是赶快解决比拟好; 这种状况 Elasticsearch 集群至多一个主分片（以及它的全副正本）都在缺失中。这意味着你在短少数据：搜寻只能返回局部数据，而调配到这个分片上的写入申请会返回一个异样。
Elasticsearch 集群不衰弱时的排查思路
- 首先确保 es 主节点最先启动，随后启动数据节点;
- 容许 selinux（非必要），敞开 iptables;
- 确保数据节点的 elasticsearch 配置文件正确;
- 零碎最大关上文件描述符数是否够用;
elasticsearch 设置的内存是否够用 (“ES_HEAP_SIZE” 内存设置 和 “indices.fielddata.cache.size” 下限设置);
elasticsearch 的索引数量暴增 , 删除一部分索引(尤其是不须要的索引);
二. Elasticsearch 索引状态
查看 Elasticsearch 索引状态 (* 示意 ES 集群的 master 主节点)
[root@elk-node03 ~]# curl -XGET 'http://10.0.8.47:9200/_cat/indices?v'
health status index pri rep docs.count docs.deleted store.size pri.store.size
green open 10.0.61.24-vfc-intf-ent-deposit.log-2019.03.15 5 1 159 0 324.9kb 162.4kb
green open 10.0.61.24-vfc-intf-ent-login.log-2019.03.04 5 1 3247 0 3.4mb 1.6mb
green open 10.0.61.24-vfc-intf-ent-login.log-2019.03.05 5 1 1663 0 2.6mb 1.3mb
green open 10.0.61.24-vfc-intf-ent-deposit.log-2019.03.19 5 1 14 0 81.1kb 40.5kb
.................
.................Elasticsearch 索引的衰弱状态也有三种，即 yellow、green、red 与集群的衰弱状态解释是一样的!
三. Elasticsearch 相干概念
Elasticsearch 集群与节点
节点 (node) 是你运行的 Elasticsearch 实例。一个集群 (cluster) 是一组具备雷同 cluster.name 的节点汇合，它们协同工作，共享数据并提供故障转移和扩大性能，当有新的节点退出或者删除节点，集群就会感知到并均衡数据。集群中一个节点会被选举为主节点(master), 它用来治理集群中的一些变更，例如新建或删除索引、减少或移除节点等; 当然一个节点也能够组成一个集群。
Elasticsearch 节点通信
能够与集群中的任何节点通信，包含主节点。任何一个节点相互晓得文档存在于哪个节点上，它们能够转发申请到咱们须要数据所在的节点上。咱们通信的节点负责收集各节点返回的数据，最初一起返回给客户端。这所有都由 Elasticsearch 通明的治理。
Elasticsearch 集群生态
1、同集群中节点之间能够扩容缩容;
2、主分片的数量会在其索引创立实现后修改，然而正本分片的数量会随时变动;
3、雷同的分片不会放在同一个节点上;
Elasticsearch 分片与正本分片 分片用于 Elasticsearch 在集群中调配数据, 能够设想把分片当作数据的容器, 文档存储在分片中，而后分片调配给你集群中的节点上。当集群扩容或放大，Elasticsearch 将会主动在节点间迁徙分片，以使集群保持平衡。一个分片 (shard) 是一个最小级别的“工作单元(worker unit)”, 它只是保留索引中所有数据的一小片. 咱们的文档存储和被索引在分片中，然而咱们的程序不晓得如何间接与它们通信。取而代之的是，它们间接与索引通信.Elasticsearch 中的分片分为主分片和正本分片, 复制分片只是主分片的一个正本，它用于提供数据的冗余正本，在硬件故障之后提供数据保护，同时服务于像搜寻和检索等只读申请，主分片的数量和复制分片的数量都能够通过配置文件配置。然而主切片的数量只能在创立索引时定义且不能批改. 雷同的分片不会放在同一个节点上。
Elasticsearch 分片算法
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 参数，它用来自定义文档到分片的映射。自定义路由值能够确保所有相干文档. 比方用户的文章, 依照用户账号路由, 就能够实现属于同一用户的文档被保留在同一分片上。
Elasticsearch 分片与正本交互
新建、索引和删除申请都是写 (write) 操作，它们必须在主分片上胜利实现能力复制到相干的复制分片上, 上面咱们列举在主分片和复制分片上胜利新建、索引或删除一个文档必要的程序步骤:
1、客户端给 Node 1 发送新建、索引或删除申请。
2、节点应用文档的_id 确定文档属于分片 0。它转发申请到 Node 3，分片 0 位于这个节点上。
3、Node 3 在主分片上执行申请，如果胜利，它转发申请到相应的位于 Node 1 和 Node 2 的复制节点上。当所有的复制节点报告胜利，Node 3 报告胜利到申请的节点，申请的节点再报告给客户端。客户端接管到胜利响应的时候，文档的批改曾经被利用于主分片和所有的复制分片。你的批改失效了
查看分片状态
[root@elk-node03 ~]# curl -X GET 'http://10.0.8.47:9200/_cluster/health?pretty'
{
"cluster_name" : "kevin-elk",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 3,
"number_of_data_nodes" : 3,
"active_primary_shards" : 2214,
"active_shards" : 4428,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 0,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 100.0
}这里须要留神: 如下是单点单节点部署 Elasticsearch, 集群状态可能为 yellow, 因为单点部署 Elasticsearch, 默认的分片正本数目配置为 1，而雷同的分片不能在一个节点上，所以就存在正本分片指定不明确的问题，所以显示为 yellow，能够通过在 Elasticsearch 集群上增加一个节点来解决问题，如果不想这么做，能够删除那些指定不明确的正本分片（当然这不是一个好方法）然而作为测试和解决办法还是能够尝试的，下面试一下删除正本分片的方法:
[root@elk-server ~]# curl -X GET 'http://localhost:9200/_cluster/health?pretty'
{
"cluster_name" : "elasticsearch",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"active_primary_shards" : 931,
"active_shards" : 931,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 930,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 50.02686727565825
}
[root@elk-server ~]# curl -XPUT "http://localhost:9200/_settings" -d'{"number_of_replicas": 0}'
{"acknowledged":true}这个时候再次查看集群的状态状态变成了 green
[root@elk-server ~]# curl -X GET 'http://localhost:9200/_cluster/health?pretty'
{
"cluster_name" : "elasticsearch",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"active_primary_shards" : 931,
"active_shards" : 931,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 0,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 100.0
} Elasticsearch 索引的 unssigned 问题
如下, 拜访 http://10.0.8.47:9200/_plugin/head/, 发现有 unssigned 景象:
这里的 unssigned 就是未调配正本分片的问题，接下来执行 settings 中删除正本分片的命令后, 这个问题就解决了:
[root@elk-node03 ~]# curl -XPUT "http://10.0.8.47:9200/_settings" -d'{"number_of_replicas": 0}'
{"acknowledged":true}四. Elasticsearch 集群衰弱状态为 ”red” 景象的排查剖析
通过 Elasticsearch 的 Head 插件拜访, 发现 Elasticsearch 集群的衰弱值为 red, 则阐明至多一个主分片调配失败, 这将导致一些数据以及索引的某些局部不再可用。head 插件会以不同的色彩显示, 绿色示意最衰弱的状态，代表所有的主分片和正本分片都可用；黄色示意所有的主分片可用，然而局部正本分片不可用；红色示意局部主分片不可用. (此时执行查问局部数据依然能够查到，遇到这种状况，还是赶快解决比拟好)
接着查看 Elasticsearch 启动日志会发现集群服务超时连贯的状况:
timeout notification from cluster service. timeout setting [1m], time since start [1m]unassigned 分片问题可能的起因?
- INDEX_CREATED: 因为创立索引的 API 导致未调配。
- CLUSTER_RECOVERED: 因为齐全集群复原导致未调配。
- INDEX_REOPENED: 因为关上 open 或敞开 close 一个索引导致未调配。
- DANGLING_INDEX_IMPORTED: 因为导入 dangling 索引的后果导致未调配。
- NEW_INDEX_RESTORED: 因为复原到新索引导致未调配。
- EXISTING_INDEX_RESTORED: 因为复原到已敞开的索引导致未调配。
- REPLICA_ADDED: 因为显式增加正本分片导致未调配。
- ALLOCATION_FAILED: 因为分片调配失败导致未调配。
- NODE_LEFT: 因为承载该分片的节点来到集群导致未调配。
- REINITIALIZED: 因为当分片从开始挪动到初始化时导致未调配（例如，应用影子 shadow 正本分片）。
- REROUTE_CANCELLED: 作为显式勾销从新路由命令的后果勾销调配。
- REALLOCATED_REPLICA: 确定更好的正本地位被标定应用，导致现有的正本调配被勾销，呈现未调配。
Elasticsearch 集群状态红色如何排查？
- 症状：集群衰弱值红色;
- 日志：集群服务连贯超时；
- 可能起因：集群中局部节点的主分片未调配。
- 接下来的解决方案次要围绕：使主分片 unsigned 分片实现再调配开展。
如何解决 unassigned 分片问题？
计划一：极其状况——这个分片数据曾经不可用，间接删除该分片 (即删除索引) Elasticsearch 中没有间接删除分片的接口，除非整个节点数据已不再应用，删除节点。
删除索引命令 ”curl -XDELETE http://10.0.8.44:9200/ 索引名 ”
计划二：集群中节点数量 >= 集群中所有索引的最大正本数量 +1
N > = R + 1
其中：
N——集群中节点的数目；
R——集群中所有索引的最大正本数目。
注意事项：当节点退出和来到集群时，主节点会主动重新分配分片，以确保分片的多个正本不会调配给同一个节点。换句话说，主节点不会将主分片调配给与其正本雷同的节点，也不会将同一分片的两个正本调配给同一个节点。如果没有足够的节点相应地调配分片，则分片可能会处于未调配状态。
如果 Elasticsearch 集群就一个节点，即N=1；所以R=0，能力满足公式。这样问题就转嫁为：
1) 增加节点解决，即N增大；
2) 删除正本分片，即 R 置为 0。
#R 置为 0 的形式，能够通过如下命令行实现:
[root@elk-node03 ~]# curl -XPUT "http://10.0.8.47:9200/_settings" -d'{"number_of_replicas": 0}'
{"acknowledged":true}计划三：allocate 重新分配分片
如果计划二依然未解决，能够思考重新分配分片。可能的起因：
1) 节点在重新启动时可能遇到问题。失常状况下，当一个节点复原与群集的连贯时，它会将无关其分片的信息转发给主节点，而后主节点将这分片从“未调配”转换为 “ 已调配 / 已启动 ”。
2) 当因为某种原因 (例如节点的存储已被损坏) 导致该过程失败时，分片可能放弃未调配状态。
在这种状况下，必须决定如何持续: 尝试让原始节点复原并重新加入集群(并且不要强制调配主分片); 或者强制应用 Reroute API 调配分片并从新索引短少的数据原始数据源或备份。如果你决定调配未调配的主分片，请确保将 ”allow_primary”：”true” 标记增加到申请中。
Elasticsearch5.X 应用脚本如下:
#!/bin/bash
NODE="YOUR NODE NAME"
IFS=$'\n'
for line in $(curl -s '10.0.8.47:9200/_cat/shards' | fgrep UNASSIGNED); do
INDEX=$(echo $line | (awk '{print $1}'))
SHARD=$(echo $line | (awk '{print $2}'))
curl -XPOST '10.0.8.47:9200/_cluster/reroute' -d '{"commands": [
{
"allocate_replica": {
"index": "'$INDEX'",
"shard": '$SHARD',
"node": "'$NODE'",
"allow_primary": true
}
}
]
}'
done
#Elasticsearch2.X 及晚期版本，只需将下面脚本中的 allocate_replica 改为 allocate，其余不变。五. 案例: ELK 中 ElasticSearch 集群状态异样问题
线上环境部署的 ELK 日志集中剖析零碎, 过了一段时间后, 发现 Kibana 展现里没有日志, 查看 head 插件索引状况, 发现始终打不开! 这是因为如果不对 es 索引定期做解决, 则随着日志收集数据量的一直增大, es 内存耗费一直增量, 索引数量也会随之暴增, 那么 elk 就会呈现问题, 比方 elk 页面展现超时, 拜访 http://10.0.8.47:9200/_plugin/head/ 始终卡顿等; es 集群状态异样 (呈现 red 的 status) 等!
在任意一个 node 节点上执行上面命令查看 es 集群状态 (url 里的 ip 地址能够是三个 node 中的任意一个), 如下可知, es 集群以后 master 节点是 10.0.8.47
[root@elk-node03 ~]# curl -XGET 'http://10.0.8.47:9200/_cat/nodes?v'
host ip heap.percent ram.percent load node.role master name
10.0.8.47 10.0.8.47 31 78 0.92 d * elk-node03.kevin.cn
10.0.8.44 10.0.8.44 16 55 0.27 d m elk-node01.kevin.cn
10.0.8.45 10.0.8.45 61 78 0.11 d m elk-node02.kevin.cn查问集群的衰弱状态（一共三种状态：green、yellow，red；其中 green 示意衰弱）
[root@elk-node03 ~]# curl -XGET 'http://10.0.8.47:9200/_cat/health?v'
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1554689492 10:11:32 kevin-elk red 3 3 3587 3447 0 6 5555 567 11.1m 39.2%解决办法:
1) 调优集群的稳定性
-> 增大零碎最大关上文件描述符数，即 65535;
-> 敞开 swap，锁定过程地址空间，避免内存 swap;
-> JVM 调优, 增大 es 内存设置, 默认是 2g (Heap Size 不超过物理内存的一半，且小于 32G);
2) 定期删除 es 索引或删除不可用的索引, 比方只保留最近一个月的索引数据 (可写脚本定期执行, 具体可参考: https://www.cnblogs.com/kevin…;
3) 如果 es 主节点重启, 则主节点在转移到其余节点过程中, 分片分片也会转移过来; 如果分片比拟多, 数据量比拟大, 则须要消耗肯定的工夫, 在此过程中, elk 集群的状态是 yellow; 查看 elk 集群状态, shards 分片会一直减少, unassign 会一直缩小, 直至 unassign 减到 0 时, 表明分片曾经齐全转移到新的主节点上, 则此时查看 elk 的衰弱状态就是 green 了;
4) 如果所有 es 节点都重启, 则须要先启动一个节点作为 master 主节点, 而后再启动其余节点;
留神, 这里记录下批改 ElasticSearch 的内存配置操作 (“ES_HEAP_SIZE” 内存设置 和 “indices.fielddata.cache.size” 下限设置)
先批改 /etc/sysconfig/elasticsearch 文件里的 ES_HEAP_SIZE 参数值, 默认为 2g
[root@elk-node03 ~]# vim /etc/sysconfig/elasticsearch
.............
ES_HEAP_SIZE=8g 接着批改 elasticsearch 配置文件
[root@elk-node03 ~]# vim /etc/elasticsearch/elasticsearch.yml
.............
bootstrap.mlockall: true #默认为 false. 示意锁住内存. 当 JVM 进行内存转换时,es 性能会升高, 设置此参数值为 true 即可锁住内存.留神: 这个时候最好在 elasticsearch.yml 配置文件里设置下 indices.fielddata.cache.size , 此参数示意 ” 管制有多少堆内存是调配给 fielddata” 因为 elasticsearch 在查问时，fielddata 缓存的数据越来越多造成的（默认是不主动清理的）
[root@elk-node03 ~]# vim /etc/elasticsearch/elasticsearch.yml
..............
indices.fielddata.cache.size: 40%
下面设置了限度 fielddata 下限, 示意让字段数据缓存的内存大小达到 heap 40% (也就是下面设置的 8g 的 40%)的时候就起用主动清理旧的缓存数据而后重启 elasticsearch
[root@elk-node03 ~]# systemctl restart elasticsearch查看启动的 elasticsearch, 发现内存曾经调整到 8g 了
[root@elk-node03 ~]# ps -ef|grep elasticsearch
root 7066 3032 0 16:46 pts/0 00:00:00 grep --color=auto elasticsearch
elastic+ 15586 1 22 10:33 ? 01:22:00 /bin/java -Xms8g -Xmx8g -Djava.awt.headless=true -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+HeapDumpOnOutOfMemoryError -XX:+DisableExplicitGC -Dfile.encoding=UTF-8 -Djna.nosys=true -Des.path.home=/usr/share/elasticsearch -cp /usr/share/elasticsearch/lib/elasticsearch-2.4.6.jar:/usr/share/elasticsearch/lib/* org.elasticsearch.bootstrap.Elasticsearch start -Des.pidfile=/var/run/elasticsearch/elasticsearch.pid -Des.default.path.home=/usr/share/elasticsearch -Des.default.path.logs=/var/log/elasticsearch -Des.default.path.data=/var/lib/elasticsearch -Des.default.path.conf=/etc/elasticsearch 如上, 在进行一系列修复操作 (增大零碎最大关上文件描述符数 65535, 敞开 swap，锁定过程地址空间，避免内存 swap, 增大 ES 内存, 删除不必或异样索引, 重启各节点的 ES 服务) 后, 再次查看 ES 集群状态, 发现此时依然是 ”red” 状态. 这是因为 es 主节点重启, 则主节点在转移到其余节点过程中, 分片分片也会转移过来; 如果分片比拟多, 数据量比拟大, 则须要消耗肯定的工夫. 须要等到 unassign 减到 0 时, 表明分片曾经齐全转移到新的主节点上, 则此时查看 elk 的衰弱状态就是 green 了.
[root@elk-node02 system]# curl -XGET 'http://10.0.8.47:9200/_cat/health?v'
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1554691187 10:39:47 kevin-elk red 3 3 4460 3878 0 8 4660 935 5.7m 48.9%
[root@elk-node02 system]# curl -XGET 'http://10.0.8.47:9200/_cat/health?v'
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1554691187 10:39:47 kevin-elk red 3 3 4466 3882 0 8 4654 944 5.7m 48.9%
................
................
#等到 "unassign" 数值为 0 时, 再次查看 es 状态
[root@elk-node03 ~]# curl -XGET 'http://10.0.8.47:9200/_cat/health?v'
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1554692772 11:06:12 kevin-elk green 3 3 9118 4559 0 0 0 0 - 100.0%如果 es 状态此时还是 red, 则须要找出 red 状态的索引并且删除 (这个时候的 red 状态的索引应该是少部分)
[root@elk-node02 system]# curl -XGET "http://10.0.8.45:9200/_cat/indices?v"|grep -w "red"比方找出的 red 状态的索引名为 ”10.0.61.24-vfc-intf-ent-order.log-2019.03.04″, 删除它即可
[root@elk-node02 system]# curl -XDELETE http://10.0.8.44:9200/10.0.61.24-vfc-intf-ent-order.log-2019.03.04须要特地留神: 如果 elasticSearch 集群节点中 es 数据所在的磁盘使用率超过了肯定比例(比方 85%), 则就会呈现无奈再为副分片分片的状况, 这也会导致 elasticSearch 集群监控状态也会呈现 ”red” 状况!!! 这个时候只须要增大这块磁盘的空间, 磁盘空间够用了, elasticSearch 就会主动复原数据!!!
六. Elasticsearch 常见谬误
谬误 1: Exception in thread “main” SettingsException[Failed to load settings from [elasticsearch.yml]]; nested: ElasticsearchParseException[malformed, expected settings to start with ‘object’, instead was [VALUE_STRING]];
起因：elasticsearch.yml 文件配置谬误导致
解决：参数与参数值 (等号) 间须要空格
[root@elk-node03 ~]# vim /etc/elasticsearch/elasticsearch.yml
...............
#node.name:elk-node03.kevin.cn #谬误
node.name: elk-node03.kevin.cn #正确
#或者如下配置
#node.name ="elk-node03.kevin.cn" #谬误
#node.name = "elk-node03.kevin.cn" #正确
而后重启 elasticsearch 服务谬误 2: org.elasticsearch.bootstrap.StartupException: java.lang.RuntimeException: can not run elasticsearch as root
起因：处于对 root 用户的平安爱护，须要应用其余用户组进行受权启动
解决：用户组进行受权启动
[root@elk-node03 ~]# groupadd elasticsearch
[root@elk-node03 ~]# useradd elasticsearch -g elasticsearch -p elasticsearch
[root@elk-node03 ~]# chown -R elasticsearch.elasticsearch /data/es-data #给 es 的数据目录受权, 否则 es 服务启动报错
[root@elk-node03 ~]# chown -R elasticsearch.elasticsearch/var/log/elasticsearch #给 es 的日志目录受权, 否则 es 服务启动报错
#以上是 yum 装置 elasticsearch 状况, 须要给 elasticsearch 的数据目录和日志目录受权, 如果 elasticsearch 是编译装置, 则须要给它的装置目录也受权接着重启 elasticsearch 服务即可
谬误 3: OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000085330000, 2060255232, 0) failed; error=’Cannot a …'(errno=12);
起因：jvm 要调配最大内存超出零碎内存
解决：适当调整指定 jvm 内存, 编辑 elasticsearch 的 jvm 配置文件
# vim /data/elasticsearch/config/jvm.options
-Xms8g
-Xmx8g
#如果是 yum 装置的 elasticsearch, 则批改如下配置文件
[root@elk-node03 ~]# vim /etc/sysconfig/elasticsearch
# Heap size defaults to 256m min, 1g max #最小为 1g
# Set ES_HEAP_SIZE to 50% of available RAM, but no more than 31g #设置为物理内存的 50%, 但不要操作 31g
ES_HEAP_SIZE=8g而后重启 elasticsearch 服务即可
谬误 4: ERROR: [3] bootstrap checks failed
起因：虚拟机限度用户的执行内存
解决：批改平安限度配置文件 (应用 root 最高权限 批改平安配置 在文件开端退出)
[root@elk-node03 ~]# vim /etc/security/limits.conf
elasticsearch hard nofile 65536
elasticsearch soft nofile 65536
* soft nproc 4096
* hard nproc 4096
#批改零碎配置文件
[3]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
[root@elk-node03 ~]# /etc/sysctl.conf #留神上面的参数值大于谬误提醒值
vm.max_map_count = 655360而后重启 elasticsearch 服务即可
七. Elasticsearch 集群监控状态监控
通过简略 shell 命令监控 elasticsearch 集群状态
原理：应用 curl 命令模仿拜访任意一个 elasticsearch 集群, 就能够反馈出 elasticsearch 集群状态，集群的状态须要为 green。
[root@elk-node03 ~]# curl -XGET 'http://10.0.8.47:9200/_cluster/stats?human&pretty'
{
"timestamp" : 1554792101956,
"cluster_name" : "kevin-elk",
"status" : "green",
"indices" : {
"count" : 451,
"shards" : {
"total" : 4478,
"primaries" : 2239,
"replication" : 1.0,
"index" : {
"shards" : {
"min" : 2,
"max" : 10,
"avg" : 9.929046563192905
},
"primaries" : {
"min" : 1,
"max" : 5,
"avg" : 4.964523281596453
},
"replication" : {
"min" : 1.0,
"max" : 1.0,
"avg" : 1.0
}
}
},
"docs" : {
"count" : 10448854,
"deleted" : 3
},
"store" : {
"size" : "5gb",
"size_in_bytes" : 5467367887,
"throttle_time" : "0s",
"throttle_time_in_millis" : 0
},
"fielddata" : {
"memory_size" : "0b",
"memory_size_in_bytes" : 0,
"evictions" : 0
},
"query_cache" : {
"memory_size" : "0b",
"memory_size_in_bytes" : 0,
"total_count" : 364053,
"hit_count" : 0,
"miss_count" : 364053,
"cache_size" : 0,
"cache_count" : 0,
"evictions" : 0
},
"completion" : {
"size" : "0b",
"size_in_bytes" : 0
},
"segments" : {
"count" : 16635,
"memory" : "83.6mb",
"memory_in_bytes" : 87662804,
"terms_memory" : "64.5mb",
"terms_memory_in_bytes" : 67635408,
"stored_fields_memory" : "6.3mb",
"stored_fields_memory_in_bytes" : 6624464,
"term_vectors_memory" : "0b",
"term_vectors_memory_in_bytes" : 0,
"norms_memory" : "6.1mb",
"norms_memory_in_bytes" : 6478656,
"doc_values_memory" : "6.6mb",
"doc_values_memory_in_bytes" : 6924276,
"index_writer_memory" : "448.1kb",
"index_writer_memory_in_bytes" : 458896,
"index_writer_max_memory" : "4.5gb",
"index_writer_max_memory_in_bytes" : 4914063972,
"version_map_memory" : "338b",
"version_map_memory_in_bytes" : 338,
"fixed_bit_set" : "0b",
"fixed_bit_set_memory_in_bytes" : 0
},
"percolate" : {
"total" : 0,
"time" : "0s",
"time_in_millis" : 0,
"current" : 0,
"memory_size_in_bytes" : -1,
"memory_size" : "-1b",
"queries" : 0
}
},
"nodes" : {
"count" : {
"total" : 3,
"master_only" : 0,
"data_only" : 0,
"master_data" : 3,
"client" : 0
},
"versions" : ["2.4.6"],
"os" : {
"available_processors" : 24,
"allocated_processors" : 24,
"mem" : {
"total" : "13.8gb",
"total_in_bytes" : 14859091968
},
"names" : [ {
"name" : "Linux",
"count" : 3
} ]
},
"process" : {
"cpu" : {"percent" : 1},
"open_file_descriptors" : {
"min" : 9817,
"max" : 9920,
"avg" : 9866
}
},
"jvm" : {
"max_uptime" : "1.1d",
"max_uptime_in_millis" : 101282315,
"versions" : [ {
"version" : "1.8.0_131",
"vm_name" : "Java HotSpot(TM) 64-Bit Server VM",
"vm_version" : "25.131-b11",
"vm_vendor" : "Oracle Corporation",
"count" : 3
} ],
"mem" : {
"heap_used" : "7.2gb",
"heap_used_in_bytes" : 7800334800,
"heap_max" : "23.8gb",
"heap_max_in_bytes" : 25560612864
},
"threads" : 359
},
"fs" : {
"total" : "1.1tb",
"total_in_bytes" : 1241247670272,
"free" : "1tb",
"free_in_bytes" : 1206666141696,
"available" : "1tb",
"available_in_bytes" : 1143543336960
},
"plugins" : [ {
"name" : "bigdesk",
"version" : "master",
"description" : "bigdesk -- Live charts and statistics for Elasticsearch cluster",
"url" : "/_plugin/bigdesk/",
"jvm" : false,
"site" : true
}, {
"name" : "head",
"version" : "master",
"description" : "head - A web front end for an elastic search cluster",
"url" : "/_plugin/head/",
"jvm" : false,
"site" : true
}, {
"name" : "kopf",
"version" : "2.0.1",
"description" : "kopf - simple web administration tool for Elasticsearch",
"url" : "/_plugin/kopf/",
"jvm" : false,
"site" : true
} ]
}
}以上监控命令打印的集群统计信息蕴含: Elasticsearch 集群的分片数，文档数，存储空间，缓存信息，内存作用率，插件内容，文件系统内容，JVM 作用情况，零碎 CPU，OS 信息，段信息。
利用脚本监控 elasticSearch 集群衰弱值 green yellow red 状态
[root@elk-node03 ~]# curl 10.0.8.47:9200/_cat/health
1554864073 10:41:13 qwkg-elk green 3 3 4478 2239 0 0 0 0 - 100.0%编写 python 脚本, 监控 elasticsearch 的衰弱状态
[root@elk-node03 ~]# vim /opt/es_health_monit.py
import commands
command = 'curl 10.0.8.47:9200/_cat/health'
(a, b) = commands.getstatusoutput(command)
status= b.split(' ')[157]
if status=='red':
healthy=0
else:
healthy=1
print healthy手动执行脚本, 打印出 elasticsearch 衰弱状态
[root@elk-node03 ~]# chmod 755 /opt/es_health_monit.py
[root@elk-node03 ~]# python /opt/es_health_monit.py而后在脚本中联合 sendemail 进行邮件报警 或者 增加到 zabbix 监控里.
八. Elasticsearch 配置中避免脑裂的配置
Master 和 DataNode 未分离，导致集群不稳固。
在 ES 集群中，节点分为 Master、DataNode、Client 等几种角色，任何一个节点都能够同时具备以上所有角色，其中比拟重要的角色为 Master 和 DataNode:
Master 次要治理集群信息、primary 分片和 replica 分片信息、保护 index 信息。
DataNode 用来存储数据，保护倒排索引，提供数据检索等。
能够看到元信息都在 Master 下面，如果 Master 挂掉了，该 Master 含有的所有 Index 都无法访问，文档中说，为了保障 Master 稳固，须要将 Master 和 Node 拆散。而构建 master 集群可能会产生一种叫做脑裂的问题，为了避免脑裂，须要设置最小 master 的节点数为 eligible_master_number/2 + 1
脑裂的概念：如果有两个 Master 候选节点，并设置最小 Master 节点数为 1，则当网络抖动或偶尔断开时，两个 Master 都会认为另一个 Master 挂掉了，它们都被选举为主 Master，则此时集群中存在两个主 Master，即物理上一个集群变成了逻辑上的两个集群，而当其中一个 Master 再次挂掉时，即使它复原后回到了原有的集群，在它作为主 Master 期间写入的数据都会失落，因为它下面保护了 Index 信息。
依据以上实践，能够对集群做了如下更改，额定选取三个独立的机器作为 Master 节点，批改 elasticsearch.yml 配置
node.master = true
node.data = false
discovery.zen.minimum_master_nodes = 2批改其余节点配置，将其设置为 DataNode，最初顺次重启
node.master = false
node.data = true