ElasticSearch 服务器随机停止工作

Question

我有 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/”它显示今天由于某种原因正在修改所有索引并且今天的日期有新文件。所以我想我开始追赶我重新启动了两台服务器，但不确定为什么它首先失败了。当我查看 master 上的日志时，我只在 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]次，每个都有最大 [30s] 超时 [2014-03-06 19:56:12,304][INFO][cluster.service] [ElasticSearch Server1] 添加了 {[Pistol][sIAMHNj6TMCmrMJGW7u97A][inet[/10.1.1.10:10] ]]{client=true, data=false},}, reason: zen-disco-receive(join from node[[Pistol][sIAMHNj6TMCmrMJGW7u97A][inet[/10.13.3.46:9301]]{client=true, data=错误的}]）

关于附加日志记录或故障排除的任何想法我可以打开以防止将来发生这种情况？由于碎片没有被赶上，现在我只是看到很多关于解析失败的调试消息。我假设一旦我们赶上，就会得到纠正。

[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], node[W6aEFbimR5G712ddG_G5yQ], [P], s[STARTED]: 无法执行 [org.elasticsearch.action.search.SearchRequest@ 74ecbbc6] lastShard [true] org.elasticsearch.search.SearchParseException: [windows-2014.03.07][3]: from[-1],size[-1]: 解析失败 [无法解析源 [{"facets": {"0":{"date_histogram":{"field":"@timestamp","interval":"10m"},"global":true,"facet_filter":{"fquery":{"query":{ “过滤”：{“查询”：{“查询字符串”：{“查询”：”(ASA AND Deny)"}},"filter":{"bool":{"must":[{"range":{"@timestamp":{"from":1394118412373,"to":"now"} }}]}}}}}}}},"size":0}]]

Answer 1

ES 与 Kibana 的常见嫌疑是：

• *可用于 ES 的内存量太少**（您可以使用任何探测系统（例如 Marvel，或者将向您发送 VM 外部的 JVM 数据进行监控的系统）进行调查）
• GC持续时间长（打开GC日志记录，看看当ES停止响应时它们是否不会发生）

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

您也可以尝试新的 G1 垃圾收集器，（就我而言）它的行为比我的 Kibana ES 中的 CMS 好得多。

GC 持续时间问题通常是当您在其他地方查找时发生的问题，并且通常会导致数据丢失，因为 ES 停止响应。

祝你好运:)