Elasticsearch慢查询背后，CPU闲得发慌，真相竟如此离谱？

哎呀，最近真是被这个 Elasticsearch 折腾得够呛！明明 CPU 看着空空荡荡的，像个没事人一样，后来啊接口响应时间却慢得让人抓狂。我简直要怀疑人生了！一开始我还以为是服务器硬件问题，各种升级硬件，后来啊呢？效果微乎其微！简直就是浪费钱啊！后来经过一番折腾和深入排查… 事情的真相简直让人哭笑不得。这就像你辛辛苦苦准备了一桌好菜，后来啊发现筷子不见了… 气不气，来一波...？

监控与告警：一开始的迷惑

先说说做的当然是监控。监控目标嘛，无非就是想知道 ES 到底发生了什么。配置文件上加了慢查询日志和慢索引配置。用 Kibana 盯着那些日志看啊看， 一堆信息跳出来… 然后用 Logstash 把这些日志抽出来想搞个邮件告警。后来啊呢？告警倒是来了很多，可都是些“无用信息”！告诉我哪个查询慢了是好事儿，但告诉我“某个节点磁盘空间不足”或者“某个进程挂掉了”我早就知道了啊！

产品	功能	价格
Logstash	日志收集、 处理和转发	免费开源
Kibana	数据可视化和探索	免费开源
Zabbix	IT基础设施监控	免费开源

段的秘密

后来在一位老哥的指点下我开始关注 ES 的内部机制——segment! ES依赖一个重要的组件Lucene,关于数据结构的优化通常来说是对Lucene的优化,它是集群的一个存储于检索工作单元,结构如下图: 在Lucene中,分为索引与检索两部分,索引部分包含分词器、 一阵见血。 过滤器、字符映射器等,检索部分包含查询解析器等。

弄一下... 一个Lucene索引包含多个segments。