关于 Elasticsearch 429 Too Many Requests 的 排查思考

文章目录

• • 导读
  • 报错分析
  • • • 如何看懂异常日志呢？
      • 报错的猜想
      • 生产情况分析
      • 我个人认为合理的猜想
  • 429报错怎么产生的？
  • • • 查找资料
      • • 百度
        • elastic中文社区
        • 书籍
        • github
  • 关键资料总结
  • • • bulk
      • 高IO (IO密集型)
      • 高CPU(CPU密集型)
      • es接收请求队列
      • es使用场景
  • 我个人分析429产生的原因
  • • • 429问题的进一步排查
      • 更多的思考
  • 最后

导读

• 最近线上有个关键报错：

Wrapped by: java.io.IOException: Request POST https://xxx/_search?search_type=xxx HTTP/1.1 yielded text/plain;charset=ISO-8859-1, should be json: HTTP/1.1 429 Too Many Requests

报错分析

如何看懂异常日志呢？

• 先知道异常日志的输出规则。
• 异常名，细节信息，路径 的概念如下图。（参考：https://www.lmlphp.com/user/58062/article/item/671925/）

• 异常名+细节信息以先进后出（FILO）的顺序打印，即：打印内容最下方的异常最早被抛出，逐渐导致上方异常被抛出。
• 路径以先进先出（FIFO）的顺序打印，即：位于打印内容最上方的位置最早被该异常经过，逐层向外抛出。
• tips：这也是为什么叫异常栈了，栈就是先进后出（FILO）

报错的猜想

• 猜想一：调用es的search api，入参有问题，因为看到关于json的报错。
• 猜想二：429 Too Many Requests 导致。

生产情况分析

1. 偶发产生这个报错
2. 产生这个报错的入参不固定
3. 入参再次请求没有产生报错
4. 报错时 CPU 和 内存 没有告警

我个人认为合理的猜想

• 根据异常日志的输出规则，json异常是在最先输出，再结合生产情况的分析，我更倾向 429 是真实报错原因，json的异常是返回结果时，es返回的不是json串，所以json解析报错。

429报错怎么产生的？

查找资料

百度

• 关键字：es 429

elastic中文社区

• https://elasticsearch.cn/question/8753
• https://elasticsearch.cn/question/2632

书籍

• 书名：Elasticsearch 源码解析与优化实战

github

• https://github.com/elastic/elasticsearch

关键资料总结

bulk

• bulk：es 批量增删改操作（特殊情况：index/delete操作转变成了只包含一条文档的bulk请求）

高IO (IO密集型)

• 频繁写入操作会导致高IO，占内存和磁盘，IO密集型建议使用脚本语言进行编码，比如python，相对编码简单，编码效率快。

高CPU(CPU密集型)

• 频繁查询操作会导致高CPU，占CPU，CPU密集型建议使用编译型语言进行编码，比如C、C++、Java和C#

es接收请求队列

• 每个节点都有一个线程池队列，可以容纳若干个请求，具体取决于您使用的 Elasticsearch 版本。队列已满时，将拒绝新请求。

es使用场景

• “tagline” : “You Know, for Search”

我个人分析429产生的原因

• 当es接到bulk请求后，放入线程池处理请求，线程池满后会放入队列，队列满了，会拒绝新的请求，产生报错 429 Too Many Requests。
• 一味的调用search接口，没有bulk操作，只会把CPU打满，也不会报429，因为search是CPU密集型操作，而且ES本身就是为了查询分析设计的。
• 但是有大量bulk操作，把队列打满，偶尔有个search查询，该查询也会返回429报错。

429问题的进一步排查

• 分析下 产生429报错的时间段，是不是有大量的 bulk操作。

更多的思考

• 金发姑娘原则，对于项目的技术选型时，没有最好的技术，只有最适合的技术。

最后

• 里面有很多我个人的猜测和思考，可能有不正确的地方，希望各位大佬多多指教评论。