ElasticSearch服务器随机停止工作

我有2个ES服务器,由1个logstash服务器提供并在Kibana中查看日志。 这是一个POC在投入生产之前解决任何问题。 系统运行了1个月左右,每隔几天Kibana就会在半夜的某个随机时间停止显示日志。 昨天晚上,我在Kibana收到的最后一个日志是在18:30左右。 当我检查ES服务器时,它显示主服务器正在运行,而辅助服务器没有运行(从/ sbin / service elasticsearch状态),但是我能够在本地主机上执行一个curl并返回信息。 所以不知道这是怎么回事 无论如何,当我在主节点上做一个状态,我得到这个:

curl -XGET 'http://localhost:9200/_cluster/health?pretty=true' { "cluster_name" : "gis-elasticsearch", "status" : "red", "timed_out" : false, "number_of_nodes" : 6, "number_of_data_nodes" : 2, "active_primary_shards" : 186, "active_shards" : 194, "relocating_shards" : 0, "initializing_shards" : 7, "unassigned_shards" : 249 } 

当我查看索引时,通过“ls … nodes / 0 / indeces /”,它显示了所有由于某种原因被修改的索引,并且今天的date还有新的文件。所以我想我已经开始追溯我重新启动了两台服务器,但不知道为什么它失败了。 当我看到主人的日志时,我只在18:57看到4个警告错误,然后离开集群。 我没有看到辅助(手枪)上的任何日志,为什么停止工作或真正发生了什么。

 [2014-03-06 18:57:04,121][WARN ][transport ] [ElasticSearch Server1] Transport response handler not found of id [64147630] [2014-03-06 18:57:04,124][WARN ][transport ] [ElasticSearch Server1] Transport response handler not found of id [64147717] [2014-03-06 18:57:04,124][WARN ][transport ] [ElasticSearch Server1] Transport response handler not found of id [64147718] [2014-03-06 18:57:04,124][WARN ][transport ] [ElasticSearch Server1] Transport response handler not found of id [64147721] 

[2014-03-06 19:56:08,467] [INFO] [cluster.service] [ElasticSearch Server1]已移除{[Pistol] [sIMHNj6TMCmrMJGW7u97A] [inet [/ 10.1.1.10:9301]] {client = true,data =假的},},原因:zen-disco-node_failed([Pistol] [inet [/ 10.13.3.46:9301]] {client = true,data = false}),ping失败,尝试[3]次,每次最大[30s]超时[2014-03-06 19:56:12,304] [INFO] [cluster.service] [ElasticSearch Server1]添加了{[手枪] [sIAMHNj6TMCmrMJGW7u97A] [inet [/ 10.1.1.10:9301 ]] {client = true,data = false},},原因:zen-disco-receive(从节点[[Pistol] [sIMHNj6TMCmrMJGW7u97A] [inet [/10.13.3.46:9301]] {client = true,data =假}])

任何想法在额外的日志logging或故障排除我可以打开,以防止这种情况发生在未来? 由于碎片没有被抓住,现在我只是看到很多关于debugging信息的parsing失败,我认为一旦我们赶上来就会纠正。

[2014-03-07 10:06:52] [] [DEBUG] [action.search.type] [ElasticSearch Server1]阶段的所有碎片失败:[查询] [2014-03-07 10:06:52,223] [DEBUG] [action.search.type] [ElasticSearch Server1] [windows-2014.03.07] [3],节点[W6aEFbimR5G712ddG_G5yQ],[P],s [开始]:无法执行[org.elasticsearch.action.search.SearchRequest @ 74ecbbc6] lastShard [true] org.elasticsearch.search.SearchParseException:[windows-2014.03.07] [3]:from [-1],size [-1]:parsing失败[Failed to parse source [{“facets” { “0”:{ “date_histogram”:{ “场”: “@时间戳”, “间隔”: “10M”}, “全局”:真 “facet_filter”:{ “fquery”:{ “查询”:{ “filtered”:{“query”:{“query_string”:{“query”:“(ASA AND Deny)”}},“filter”:{“bool”:{“range”:{ “@timestamp”:{ “从”:1394118412373 “以”: “现在”}}}]}}}}}}}}, “尺寸”:0}]]

ES与Kibana的常见嫌犯有:

  • *可用于ES **的内存太less(您可以使用任何探测系统进行调查,例如Marvel,或将VM发送给VM以外的JVM数据以进行监视)
  • 长的GC持续时间 (打开GC日志logging,查看ES停止响应时是否没有发生)

另外ES的“常规”设置是3台服务器 ,以便在一台服务器停机时提供更好的冗余。 但是YMMV。

你也可以尝试新的G1垃圾收集器 ,在我的Kibana ES中,它比我的情况下有更好的行为。

GC持续时间问题通常是在您寻找其他位置时发生的问题,并且通常会导致数据丢失,因为ES停止响应。

祝你好运:)