生产环境ES查询延迟排查
最近经常收到业务方配置的ES查询延迟告警，同样的请求手动在Kibana控制台执行只需几十毫秒就返回结果。受影响的整个链路情况如下，php应用程序通过部署在ES集群各节点上的nginx访问ES请求查询数据。
查询延迟原因可能有2个方面的因素：
1、ES集群异常，ES应用故障或者集群节点主机故障。
- 首先通过查看上一篇配置的dashboard检测各节点系统指标以及ES性能指标在告警时段有无明显异常。排查问题时为了方便直接查看，针对搜索和索引请求相关的指标，构建了一个新图，直接对query，index，fetch，merge操作的时间进行rate计算，对query，index，fetch，merge操作次数进行increase计算，两者相除得到单个请求的平均操作耗时。若有异常，可以再查看之前的图表中具体的操作数和请求时间。并查看ES相关时间点的日志。
- 集群节点主机级别的问题主要通过观察node_exporter中的核心指标有无异常，包括CPU，内存，网络，TCP连接，上下问切换，磁盘容量及IO。
2、业务请求异常，业务请求量突增高于正常的水平。
业务上的请求异常主要通过分析ES各节点nginx代理的访问日志错误日志，前端web服务以及php的日志。
- 写入方客户端写ES的请求记录，请求时间，状态码，响应时间。
- 找到ES集群中告警延迟索引的相关文档确切的写入时间。
- 找到查询方客户端的查询记录，请求时间，状态码，响应内容。
分析日志的过程异常痛苦，由于延迟出现在10分钟的时间段， 所以想要分析业务量的波动是否正常，需要统计日志同比环比，进行对比。日志文件大，使用正则，组合grep,awk,sed耗时又消耗性能，效率又低。最终梳理日志，并对关键字段进行解析，接入袋鼠云日志分析系统，终于摆脱登录各服务器命令行统计的惨状，配置应用场景，访问趋势清晰明了。
TIPS：
查看监控图表发现业务访问并无异常，使用sar -B查看内存ES节点内存情况，发现在问题时间点各节点的pgscand/s一列数值较高，说明内核线程kswapd回收内存，由于系统free内存不足，当应用突然需要额外内存。用户进程或线程分配内存或发生缺页中断时，会在用户线程上下文中直接进行回收内存(pgscand)和分配内存。
建议根据机器的规格调大以下两个值，32C64G机器可以调大至2-4G
- vm.min_free_kbytes系统所保留空闲内存的最低限
- vm.extra_free_kbytes系统保留给应用的free内存
