elasticsearch慢查询监控优化策略

监控目标
1． 在elasticsearch配置文件上添加慢查询日志和慢索引配置
2． 使用kibana监测elasticsearch慢查询日志的生成，使用logstash抽取日志的方式，有慢查询日志生成，就以邮件告警的方式提醒。
3． 使用zabbix分别监控集群的状态、CPU、进程数、磁盘读写性能、JVM使用。同时还要监控elasticsearch中分片的状态。达到某个临界值，就以邮件告警的方式提醒。
4． 通过zabbix对es进行监控，当es挂掉后，以邮件告警的方式提醒。
通过kibana对慢查询日志的监控和zabbix对集群参数的监控。两个邮件告警方式在相差不大的时间发送邮件告警。可以快速找到问题所在。
优化方案
优化的主要目标是通过对分片和副本的设定、GC大小的设置、内存的分配进而加快查询的速度。
1. 分片和副本的分配
每个分片本质上就是一个Lucene索引，因此会消耗相应的文件权柄、内存和CPU资源。每个搜索请求会调度到索引的每个分片中，如何分片分散在不同的节点上问题还不大，但当分片竞争相同的硬件资源时，性能会逐步下降。
ES使用词频统计来计算相关性. 当然这些统计也会分配到各个分片上. 如果在大量分片上只维护了很少的数据, 则将导致最终的文档相关性较差。
通常认为随着业务的增长,他们的数据量也会相应的增加,所以很有必要为此做长期规划。很多人相信他们将会遇到暴发性增长(尽管大多数甚至都没有遇到过峰值)，当然也希望避免重新分片并减少可能的停机时间。
Elastic官方建议一个node最好不要多于3个shards。
担心数据量增长，可以对elasticsearchJVM堆空间进行限制：最大推荐的是30-32G，所以每个分片的最大容量限制为30G，然后在对分片数量进行合理的估算。例如，数据量达到200G，这个时候分片分配7-8个最好。分片的大小要跟堆的大小作比较。分片太少，太多都会影响索引的性能。
（如果有基于日期的索引需求,并且对索引数据的搜索场景非常少。也许这些索引量将达到成百上千,但每个索引的数据量只有1GB甚至更小。对于这种类似场景, 建