大数据运维问题记录(九)

问题描述:部门承接的某运营商的CRM项目日志查询出现延迟，最高延迟达半小时，严重影响业务运行。
问题解决:首先对他们的数据流向进行了解后得知，数据是从Flume采集到Kafka再由Sparkstreaming到Elasticsearch, Elasticsearch做为数据存储，版本为2.3.2，CRM系统就是在前端对Elasticsearch进行查询，在此之前Elasticsearch集群出现过一次瘫痪，然后启动不起来，他们对Elasticsearch集群做过一次优化，听他们反应之前是没有延迟的，是集群优化后出现了此问题。首先确定一下到底是哪个环节出现的问题，查看原始文件生成时间到Flume日志打印出来的时间，没有出现延迟，kafka这块采用了一个小工具叫KafkaOffsetMonitor，监控进入kafka的速率和从kafka出的速率确认kafka这块的问题不大（顺便说一下，给KafkaOffsetMonitor分配的java heap要大点，要不然数据太大的话界面会显示不出来），查看elasticsearch的入库时间发现这块有延迟，那么问题就基本确定了，要不是sparkstreaming这块处理的慢了，要不就是elasticsearch这块入库慢了。查看sparkstreaming任务发现还算稳定因为每批次任务是一分钟执行一次，任务基本都在一分钟之内能够完成，对spark执行命令和sparkstreaming程序做了些优化，sparkstreaming这边没有太大改变，高峰期延迟依然存在，那么问题就定位到elasticsearch上了，对elasticsearch的cpu,io,内存和gc的情况进行检查没发现什么问题,查看配置文件发现常用的优化点基本都涉及到了，问现场要优化前的配置说没有备份，只能一个一个配置项看，询问现场每小时的数据量，高峰期的话能达到2200多万，现在延迟基本就在高峰期的两个时间点，一个是早上10点，一个是下午4点，其余时间没有延迟，经过一个一个配置项排查，发现有个配置是index.translog.flush_threshold，值设置的是100000，查看官方文档2.3.2版本配置说明， translog flush相关的配置项有index.translog.flush_threshold_size，默认值为512mb，index.translog.flush_threshold_ops，默认值为unlimited（也就是INT.MAX），index.translog.flush_threshold_period，默认值为30m，index.translog.interval，默认值为5s。没有发现index.translog.flush_threshold这个配置项，后来看日志才知道这么设置的话代表index.translog.flush_threshold_ops这个配置项，在这说明一下es 在每次进行index或者delete操作后都会记录到translog中，默认是同步的，也就是每个request都会记录到translog中并flush到磁盘，通过修改index.translog.durability这个参数可以改为异步的，这个配置他们也改成了async，这个异步的执行机制是先将每次的translog放到内存buffer中，每5s（index.translog.interval）进行一次检查看是否满足index.translog.flush_threshold_size，index.translog.flush_threshold_ops，index.translog.flush_threshold_period，这三个条件中的一个，只要满足就进行一次flush操作将translog flush到磁盘,那么结合场景计算高峰期2200万每小时，平均1秒就有6000多次操作，达到index.translog.flush_threshold_ops的100000也就十几秒钟，这个flush频率有些快，影响效率，所以这块用默认值就可以，然后我将index.translog.flush_threshold_size的值设置为1g，可能这块重启集群后测试，在高峰期没有再出现延迟的情况。
总结：首先现场实施人员要对每次配置做备份，其次对每个优化点进行优化时要针对自己实际业务的场景进行优化配置，不要盲目拷贝，还要对每个优化配置项的含义进行较深入的了解，这样才能更好的利用好这些优化点