elasticsearch: monitor fielddata -警报阈值应该是多少？和监控ES的一般情况

Question

CentOS上的Elasticsearch 1.7.2

我们知道elasticsearch建议的配置是操作系统的RAM为%50，elasticsearch为%50。

因此，在一个16 8GB的系统上，elastic有8 8GB。

到目前为止一切还好。

我们还了解到，通过在我们的映射中使用doc_values标记，可以大大减少ES工作集。我们正在做这件事。

我们还知道，我们应该从elasticsearch监控fielddata元素的大小(因为当我们的系统内存耗尽时，我们遭受了灾难性的数据丢失)。

也很好。

但是我们在寻找什么呢？

1) fielddata是我们唯一需要监控的东西(除了集群健康)吗？

2)我们应该监控什么，以确保不会耗尽硬件主控室？

3)和RE fielddata:我们是否在寻找fielddata =7.5 RE(例如，我们即将最大限度地使用可用的RAM)？

或者是____？

Answer 1

你为什么不考虑使用doc_values呢？ES 2.0又向前迈进了一步，将现场数据转换为doc_values as default for not_analyzed string fields, dates, numbers。

关于你的具体问题，我想先从字段数据的限制开始。默认情况下，Fielddata是无界的。这意味着它可以增长，直到fielddata断路器将阻止任何使用超过限制的查询运行。这意味着，一旦您的节点达到断路器限制，就不会在内存中放置任何其他字段数据，并且需要新字段数据的查询将被拒绝。为防止出现这种情况，您需要设置indices.fielddata.cache.size，该值应为小于断路器限制的的值。

设置此选项将允许逐出字段数据。这不是理想的情况，因为字段数据的加载成本很高。理想情况下，需要足够的内存来保存必要的字段数据，而不会被逐出。

The circuit breaker limit has a value of 60% of the heap as the default value。例如，将indices.fielddata.cache.size设置为50%，查看集群的行为，并根据需要重新调整。但是，如果您正确设置了使用doc_values，我认为您目前不应该过多地担心字段数据。

要监控的其他内容：

应显示旧缓存

• CPU
• disk saw-tooth pattern
• fielddata evictions
• filter evictions
• JVM

GC

的旧空间加载系统加载JVM堆使用情况

此外，关于要监视的内容的很好的阅读可以找到here。