背景
一天早上突然报警群叮叮叮，响个不停，微信报警群出现请求报错，通过查看日志分析，公共服务阿里云ES服务器访问不通，并初步判断是ES服务器宕机
原因
通过查询ES以往的日志，和宕机时间，查到超过一个2k+的字符查询，而且这个字段查询，又是wildcard查询(模糊查询)的，导致CPU爆满，服务器直接宕机(在测试环境复现)。
解决方案
目前业务查询还是需要这个关键字的模糊查询，所以我们在查询前，进行长度校验； ps:之前我们很多查询都有这个坑，没想到被我踩到了，呜呜呜。
总结
- 会出现这种问题，用户一些不正当的操作导致，我们在编写API时，比如查询ES关键字时，要设置关键字的长度，避免出现这种问题。
- 考虑接受字符串长度问题。
- ES查询长度最大大约为2000个字符 ：http://www.voidcn.com/article/p-hxgzlcac-bvu.html
- 设置告警短信,当cpu达到某个值时，提出告警，提前预防。
- 总结使用经验。
ES其他的使用注意事项
- 时区问题：在项目中，索引下一般都会存在一个时间的字段，这个字段可以用来排序，或者做时间范围查询，或者聚合的场景等都会用到。ES底层默认采用UTC时间格式，而中国的时间(CST)，而
CST=UTC+8,在时区问题上一定要注意；避坑里链接：https://blog.csdn.net/pony_maggie/article/details/104957681 - 使用默认的mapping：ES本身支持我们在写入一个索引的时候，可以不为该索引设置任何的mappings。这种情况下，ES会为索引根据写入的字段值，"推断"该字段的类型。根据我的经验，对于一些int类型，或者不参与查询的字段，可以用默认类型，但是对于参与查询的，特别是模糊查询时，一定要指定mappings
- 没有规划好分片：我们一般都需要为索引设置分片的数量，具体设置成多少需要根据你的项目实际情况来定。一般来说，单个 Shard 的建议最大大小是 20G 左右，最大不要超过 50G。单个shard过大，或者shard过小导致shard数量太多，都会影响查询的效率。
举个例子，比如你预估索引的大小是100G，这个时候分片是3~5比较好。如果你的索引是每天增量比较大的场景，比如日志类，订单类的索引，可能你首先要把根据日期来新建不同的索引，根据时间的数据规模选择按天，周，甚至月来建索引。然后这些索引使用相同的分片设置。
-
分桶聚合查询的内存爆炸：在分桶聚合的场景下，大多数时候对单个字段的聚合查询非常快的，如果是多个字段嵌套聚合。有可能撑爆内存，引发OOM。
- mapping不应有过多的字段：我们给索引建模时，要尽量避免mapping中的包含的字段过多。过多的字段一个是难以维护，当存在成千上百个字段时，很难有人真正明确每个字段的含义。另外一个导致的问题是，当我们需要更新文档的时候，ES会在不同的节点同步这些更新。过多的字段意味着更新变慢。如果我们的业务场景确实需要很多字段，应该充分利用ES的
dynamic templates机制，提前定义好字段映射的规则，这样一些字段就没有必要在mapping里定义好。不过无论如何，都应该尽量保持你的mapping字段足够小。 - should查询：当在ES中想一起使用should (or)与 must(and)的时候，需要先通过filter把他们拼凑在一起，否则should是不生效的。
- 分页查询注意事项：随着分页的越深入，ES从各分片上查询的数据量越大，性能时指数级下降。为什么要设置
index.max_result_window=10000，就是出于这种考虑，防止耗尽ES内存资源，产生OOM。对于深度翻阅查询没要求的需求，可以限制查询的翻页深度和数据量。如果有深度分页查询的需要，可以考虑用scroll的方式，但是它的原理是通过游标，通过记录上一次的id,只能一页一页的翻，不能进行跳转