![ElasticSearch 服务器随机停止工作](https://linux22.com/image/628571/ElasticSearch%20%E6%9C%8D%E5%8A%A1%E5%99%A8%E9%9A%8F%E6%9C%BA%E5%81%9C%E6%AD%A2%E5%B7%A5%E4%BD%9C.png)
我有 2 个 ES 服务器,它们由 1 个 logstash 服务器提供数据,并在 Kibana 中查看日志。这是在投入生产之前解决任何问题的 POC。该系统已运行约 1 个月,每隔几天,Kibana 就会在半夜的某个随机时间停止显示日志。昨晚,我在 Kibana 中收到的最后一条日志条目是在 18:30 左右。当我检查 ES 服务器时,它显示主服务器正在运行,而辅助服务器未运行(来自 /sbin/service elasticsearch status),但我能够在本地主机上执行 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/”查看索引时,它显示所有索引由于某种原因今天都被修改了,并且有今天的新文件。所以我认为在重新启动两台服务器后我开始恢复,但不确定它为什么会失败。当我查看主服务器上的日志时,我只看到 18:57 的 4 个警告错误,然后第二个服务器离开了集群。我没有在辅助服务器(Pistol)上看到任何关于它停止工作的原因或真正发生了什么的日志。
[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][sIAMHNj6TMCmrMJGW7u97A][inet[/10.1.1.10:9301]]{client=true, data=false},},原因:zen-disco-node_failed([Pistol][sIAMHNj6TMCmrMJGW7u97A][inet[/10.13.3.46:9301]]{client=true, data=false}),原因为 ping 失败,尝试 [3] 次,每次最长超时时间为 [30 秒] [2014-03-06 19:56:12,304][INFO][cluster.service] [ElasticSearch Server1] 已添加{[Pistol][sIAMHNj6TMCmrMJGW7u97A][inet[/10.1.1.10:9301]]{client=true, data=false},}, 原因:zen-disco-receive(从节点[[Pistol][sIAMHNj6TMCmrMJGW7u97A][inet[/10.13.3.46:9301]]{client=true, data=false}]加入)
有没有关于我可以启用其他日志记录或故障排除来防止这种情况再次发生的想法?由于碎片没有赶上,现在我只看到很多关于解析失败的调试消息。我假设一旦我们赶上进度,这个问题就会得到纠正。
[2014-03-07 10:06:52,235] [DEBUG] [action.search.type] [ElasticSearch Server1] 所有分片均在阶段失败:[query] [2014-03-07 10:06:52,223] [DEBUG] [action.search.type] [ElasticSearch Server1] [windows-2014.03.07] [3],节点[W6aEFbimR5G712ddG_G5yQ],[P],s [STARTED]:无法执行 [org.elasticsearch.action.search.SearchRequest@74ecbbc6] lastShard [true] org.elasticsearch.search.SearchParseException:[windows-2014.03.07] [3]:来自[-1],size[-1]:解析失败[无法解析源[{"facets":{"0":{"date_histogram":{"field":"@timestamp","interval":"10m"},"global":true,"facet_filter":{"fquery":{"query":{"filtered":{"query":{"query_string":{"query":"(ASA AND Deny)"}},"filter":{"bool":{"must":[{"range":{"@timestamp":{"from":1394118412373,"to":"now"}}}]}}}}}}}},"size":0}]]
答案1
对于 ES 与 Kibana 来说,常见的有:
- *ES 可用的内存太少**(你可以使用任何探测系统(例如 Marvel,或者可以将 JVM 数据发送到 VM 之外进行监控的系统)进行调查)
- GC 持续时间长(打开 GC 日志记录并查看当 ES 停止响应时它们是否不会发生)
此外,ES 的“常用”设置是3台服务器当一台服务器宕机时,可以实现更好的冗余。但 YMMV。
您可以尝试新的G1垃圾收集器就我而言,它的表现比我的 Kibana ES 中的 CMS 要好得多。
GC 持续时间问题通常发生在您正在查看其他地方时,并且通常会导致数据丢失,因为 ES 停止响应。
祝你好运:)