三人行必有我师

怎样获取协调节点环节的查询用时?

Elasticsearch | 作者 wangxinrong | 发布于2022年11月28日 | 阅读数:965

ES慢查日志只记录分片层面的查询用时。
如果从客户端看到一个查询的用时,假设是100ms,但是慢查日志显示分片层面只用了10ms,那么剩余的90ms消耗在哪里了,有办法追踪到吗。
有没有办法记录查询在协调节点层面的用时,也就是协调节点用于分发请求和汇总结果的用时。
 
最近出现过一个奇怪的现象: 
某一时间开始,ES有一小部分比例的请求突然响应时间变长,持续了两三个小时后又突然恢复正常。
1.我这边用到了nginx做负载均衡接收应用的请求,从nginx日志可以看到部分请求的upstream_response_time变长了,说明是ES响应时间变长。
2.查nginx日志,在用时长的请求里,upstream_addr分布是均衡的,说明不是某个ES协调节点的问题。
3.这个时间点没有做过任何变动,看ES慢查日志,也没有明显增长,说明此时查询语句和参数无问题,没有耗时长的查询。
4.在问题出现时间点的前后,查看ES层面的各监控项,例如读写qps、段合并操作、线程繁忙情况、jvm内存使用等,均无变化。查看节点的cpu、内存、磁盘io、网络等,也都无变化。
5.该ES上的所有索引都存在上述情况,各索引分布的数据节点是各不相同的,互相独立的。只有协调节点是共用的。
6.在一切正常的情况下,目前我知道可能影响的因素,一个是gc用时变长,一个是网络问题。但我查了节点gc日志一切正常,网络也正常(也不可能所有节点都有网络问题)。
 
上述情况下,我实在想不出什么可能性导致了上面那个突然出现又突然消失的问题。而且也没什么好的观察手段。
不知道有没有办法记录下协调节点层面的用时,确认是不是协调节点的问题。
已邀请:

Charele - Cisco4321

赞同来自:

"profile":true
不知道用这个能不能让你找到原因
 

要回复问题请先登录注册