文章目录
- 导读
- 报错分析
- 如何看懂异常日志呢？
- 报错的猜想
- 生产情况分析
- 我个人认为合理的猜想
- 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 导致。
生产情况分析
- 偶发产生这个报错
- 产生这个报错的入参不固定
- 入参再次请求没有产生报错
- 报错时 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操作。
更多的思考
- 金发姑娘原则，对于项目的技术选型时，没有最好的技术，只有最适合的技术。
最后
- 里面有很多我个人的猜测和思考，可能有不正确的地方，希望各位大佬多多指教评论。
