为什么 elasticsearch 集群获取节点信息失败

来源：蜘蛛抓取(WebSpider) 时间：2017-03-18 03:19 标签： 获取节点信息失败

之前在IDC机房环境部署了一套ELK日志集中分析系统, 这里简单总结下ELK中Elasticsearch健康状态相关问题, Elasticsearch的索引状态和集群状态传达着不同的意思

一个 elasticsearch 集群集群至少包括一个节点和一个索引。或者它 可能有一百个数据节点、三个单独的主节点以及一小打客户端节点——这些共同操作一千个索引（以及上万个分片）。但是不管集群扩展到多大规模你都会想要一个快速获取集群状态的途径。Cluster Health API 充当的就是这个角色你可以把它想象成是在一万英尺的高度鸟瞰集群。它可以告诉你安心吧一切都好或者警告你集群某个地方有问题。elasticsearch 集群里其他 API 一样cluster-health 会返回一个 JSON 响应。这对自动化和告警系统来说非常便于解析。响应中包含了和你集群有关的一些关键信息:

查询集群的健康状态（一共三种状态：green、yellowred；其中green表示健康）

通过以上排查大概知道是历史索引数据处于 open 状态过多，从而导致ES的CPU内存占用过高导致的不可用。 关闭不需要的索引减少内存占用 如果发现在关闭非热點索引数据后，elasticSearch集群的健康值依然是"red"状态这时候要想到: 可能索引的"red"状态可能会影响ES的状态. 接着查看elasticSearch索引健康状态, 发现果不其然 解决方法，删除上面命令中查看的有问题的那条索引数据（这条数据是排查问题期间产生的脏数据索引直接删除） 注意: 应注意elasticSearch的索引状态以及服務器的监控，及时清理或者关闭不必要的索引数据避免这种情况发生。

以上监控命令打印的集群统计信息包含: Elasticsearch集群的分片数文档数，存储空间缓存信息，内存作用率插件内容，文件系统内容JVM 作用状况，系统 CPUOS 信息，段信息
然后在脚本中结合sendemail进行邮件报警 或者 添加到zabbix监控里.

在ES集群中，节点分为Master、DataNode、Client等几种角色任何一个节点都可以同时具备以上所有角色，其中比较重要的角色为Master和DataNode:
2. 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配置

修改其他节点配置，将其设置为DataNode最后依次重启

出错的原因为复制时也把data目录丅的数据复制了一份。删除复制过来的data目录下的数据再次启动时启动成功。

我要回帖

更多关于 获取节点信息失败 的文章

 

随机推荐