elasticsearch慢查询监控优化策略，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甚至更小。对于这种类似场景, 建议只需要为索引分配1个分片。
如果使用ES的默认配置(5个分片)，并且使用Logstash按天生成索引, 那么6个月下来，你拥有的分片数将达到890个。这样因为分片数量太多，严重消耗内存资源、CPU的运转，查询的速度也会慢下来。）
单节点是不需要副本数的，而多节点搜索性能取决于最慢的节点的响应时间，
所以也要对所有的节点做负载均衡。比如有三个节点，拥有两个主分片，每个分片有一个副本。这样如果有三个节点，就会造成有两个节点做一倍工作，而另外一个分片做着两倍的工作。这个时候查询的效率就会降下来。可以通过调整副本数量进行平衡，通过调整把副本数量调整为2份，最终拥有6个分片，平衡的分配在三个节点上。（当然副本数量的设定要根据磁盘的大小，副本数的增加，也会加速查询速度）
2. GC堆大小的设置：
堆内存的值取决于服务器上可用的内存大小。Elasticsearch可用的堆越多，可用于缓存的内存就越多。但请注意，太多的堆内存可能会使您长时间垃圾收集暂停。
堆的大小最大推荐为30-32G，标准建议是将可用内存的50％提供Elasticsearch堆（以确保有足够的物理内存留给内核文件系统缓存），剩50%不会被闲置，会交给Lucene使用。
如果不在字符串字段上做聚合操作，则可以考虑进一步降低堆。堆越小，可以从Elasticsearch（更快的GC）和Lucene（更对的内存缓存）中获取更好的性能。
3. 内存和磁盘
内存和磁盘的大小是多多益善。
4. 分词策略
暂时没有太好的方案，待续！
5. 索引段策略
暂时没有太好的方案，待续！
总结：
1：java jdk版本尽量高一点，否则容易出现bug。
2：es集群结点规划好，master，client，data node 分开，关闭data node 的http功能。
3：合理利用内存。
4：根据机器数，磁盘数，索引大小等硬件环境，根据测试结果，设置最优的分片数和备份数，单个分片最好不超过10GB，定期删除不用的索引，做好冷数据的迁移。（在确定分片数之前需要进行单服务单索引单分片的测试。比如创建一个索引，该索引只有一个分片，分别在不同数据量的情况下进行检索速度测试）。索引分片数=数据总量/单分片数
5：保守配置内存限制参数，尽量使用doc value存储以减少内存消耗，查询时限制size、from参数。
6：结合实际场景，做好集群监控。