https://www.cnblogs.com/kevingrace/p/10671063.html
https://www.qikegu.com/docs/3058
绿 – 一切正常(集群功能齐全)
黄 – 所有数据可用,但有些副本尚未分配(集群功能完全)
红 – 有些数据不可用(集群部分功能)
之前在IDC机房环境部署了一套ELK日志集中分析系统, 这里简单总结下ELK中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 相关概念
- Elasticsearch集群与节点
节点(node)是你运行的Elasticsearch实例。一个集群(cluster)是一组具有相同cluster.name的节点集合,它们协同工作,共享数据并提供故障转移和扩展功能,当有新的节点加入或者删除节点,集群就会感知到并平衡数据。集群中一个节点会被选举为主节点(master),它用来管理集群中的一些变更,例如新建或删除索引、增加或移除节点等;当然一个节点也可以组成一个集群。
- Elasticsearch节点通信
可以与集群中的任何节点通信,包括主节点。任何一个节点互相知道文档存在于哪个节点上,它们可以转发请求到我们需要数据所在的节点上。我们通信的节点负责收集各节点返回的数据,最后一起返回给客户端。这一切都由Elasticsearch透明的管理。
- Elasticsearch集群生态
-> 同集群中节点之间可以扩容缩容;
-> 主分片的数量会在其索引创建完成后修正,但是副本分片的数量会随时变化;
-> 相同的分片不会放在同一个节点上;
- Elasticsearch分片与副本分片
分片用于Elasticsearch在集群中分配数据, 可以想象把分片当作数据的容器, 文档存储在分片中,然后分片分配给你集群中的节点上。 当集群扩容或缩小,Elasticsearch将会自动在节点间迁移分片,以使集群保持平衡。 一个分片(shard)是一个最小级别的“工作单元(worker unit)”,它只是保存索引中所有数据的一小片.我们的文档存储和被索引在分片中,但是我们的程序不知道如何直接与它们通信。取而代之的是,它们直接与索引通信.Elasticsearch中的分片分为主分片和副本分片,复制分片只是主分片的一个副本,它用于提供数据的冗余副本,在硬件故障之后提供数据保护,同时服务于像搜索和检索等只读请求,主分片的数量和复制分片的数量都可以通过配置文件配置。但是主切片的数量只能在创建索引时定义且不能修改.相同的分片不会放在同一个节点上。
- Elasticsearch分片算法
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参数,它用来自定义文档到分片的映射。自定义路由值可以确保所有相关文档.比如用户的文章,按照用户账号路由,就可以实现属于同一用户的文档被保存在同一分片上。
- Elasticsearch分片与副本交互
新建、索引和删除请求都是写(write)操作,它们必须在主分片上成功完成才能复制到相关的复制分片上,下面我们罗列在主分片和复制分片上成功新建、索引或删除一个文档必要的顺序步骤:
-> 客户端给Node 1发送新建、索引或删除请求。
-> 节点使用文档的_id确定文档属于分片0。它转发请求到Node 3,分片0位于这个节点上。
-> 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
}
如有问题,可以QQ搜索群1028468525加入群聊,欢迎一起研究技术
有疑问联系站长,请联系QQ: