关于elasticsearch:Elasticsearch-最佳实践

36次阅读

共计 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




正文完
elasticsearch
发表至： elasticsearch
2020-10-08
 0
关于elasticsearch:用于-Elasticsearch-查询的查询-DSL-Builder
关于SegmentFault:ESes761开通安全防护认证流程
关于elasticsearch:ElasticSearch-Query-DSL-Demo
关于elasticsearch:elasticsearch基础5-ES的查询过程