近期接手离职同事项目,突然遇到线上事故,Flink
无法正常聚合数据生成指标.
以下是详细的排查过程:
问题复现
清晨,运维报告Flink
数据分析模块无法正常生成指标数据.
赶紧登陆Flink
所在机器,使用如下语句简单查看Job
状态.
./bin/flink list
查看输出,发现故障Job
在Running
状态.
因为数据分析模块运行时间较久,近期没有更新过,因此怀疑是依赖的中间件问题.
问题根源定位
(1) 查看数据源
数据分析模块依赖于Kafka
,因此登陆Kafka
所在机器,查看相应topic
的消费情况.
./bin/kafka-consumer-groups.sh --describe --bootstrap-server 192.*.*.*:9092 --group data_prod_consumer
得到结果如下所示:
TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID HOST CLIENT-ID
qq_data 0 340155122 340155407 285 - - -
多次运行命令(间隔一段时间),发现LOG-END-OFFSET
的增长速度远大于CURRENT-OFFSET
,导致LAG
指标不断上升,最高时达到17000
.
让同事紧急修改日志输出,屏蔽非核心业务的日志,然而作用不大,LAG
仍然在缓慢的持续增长.
LOG-END-OFFSET
意为当前最新数据偏移量,CURRENT-OFFSET
意为当前消费者消费的偏移量,LAG
为LOG-END-OFFSET
与CURRENT-OFFSET
之间的差值.
通过LAG
数值,可以观察到topic
的消费情况,从而确定是否有数据积累.
观察flink
机器负载,发现负载较低,消费瓶颈不应该是Flink
.
(2) 查看数据输出
数据分析模块的Sink
是Elasticsearch
(单节点运行),因此查看ES
的运行状况.
curl 'localhost:9200/_cat/indices?v'
查数据分析模块输出的数据库,发现数据库大小正常,感觉疑惑.
使用top
查看机器的负载信息,大吃一惊:
由上图可知,ES
应用的虚拟内存(VIRY
)占用高达28G,此外,机器的load average
高达4.43.
基本上,可以确定是Elasticsearch
异常引发数据分析模块运行异常.
重新查看ES
索引信息,发现有四个Type
数据量不对(非相关业务数据表),其中一张表的数据量多达2800万条(此业务有过了解).
询问离职同事,经过询问大致可确定这四张表的数据量不对,此表数据未设置TTL
,而是依赖于数据库定时删除脚本完成过期数据删除操作.
(3) 确定问题
查看数据库定期删除脚本执行日志,发现脚本在较长的一段时间内未能正常运行.
原因是脚本在这执行删除操作时,未根据业务的变更而修改脚本,导致在删除已废弃表中数据时出现异常而终止运行.
因为当前故障业务的数据库删除命令在异常前,故当前业务的数据量维持在正常的水平线上.
ps -ef|grep elasticsearch
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-2.b14.el7.x86_64/jre/bin/java -Xms1g -Xmx1g -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+AlwaysPreTouch -server -Xss1m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djna.nosys=true -XX:-OmitStackTraceInFastThrow -Dio.netty.noUnsafe=true -Dio.netty.noKeySetOptimization=true -Dio.netty.recycler.maxCapacityPerThread=0 -Dlog4j.shutdownHookEnabled=false -Dlog4j2.disable.jmx=true -XX:+HeapDumpOnOutOfMemoryError -Des.path.home=/home/app/elasticsearch-6.1.2 -Des.path.conf=/home/app/elasticsearch-6.1.2/config -cp /home/app/elasticsearch-6.1.2/lib/* org.elasticsearch.bootstrap.Elasticsearch -d
此外,查看Elasticsearch
的运行信息时,发现其配置明显存在不足,Xms
分配为1G,Xmx
分配为1G.
然而当前机器仅运行Elasticsearch
,因此暂停依赖于Elasticsearch
的相应业务,调整配置信息,重新启动.
ps -ef|grep elasticsearch
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-2.b14.el7.x86_64/jre/bin/java -Xms8g -Xmx8g -XX:+UseG1GC -XX:MaxGCPauseMillis=50 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+ParallelRefProcEnabled -XX:+AlwaysPreTouch -server -Xss1m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djna.nosys=true -XX:-OmitStackTraceInFastThrow -Dio.netty.noUnsafe=true -Dio.netty.noKeySetOptimization=true -Dio.netty.recycler.maxCapacityPerThread=0 -Dlog4j.shutdownHookEnabled=false -Dlog4j2.disable.jmx=true -XX:+HeapDumpOnOutOfMemoryError -Des.path.home=/home/app/elasticsearch-6.1.2 -Des.path.conf=/home/app/elasticsearch-6.1.2/config -cp /home/app/elasticsearch-6.1.2/lib/* org.elasticsearch.bootstrap.Elasticsearch -d
修改后,Xms
以及Xmx
响应调整为8G,按照Elasticsearch
推荐配置,保留8G内存供系统使用.
此外,临时修改数据库脚本并执行,删除各表中的过期数据.
curl -XPOST "http://localhost:9200/data/_delete_by_query?conflicts=proceed" --header 'Content-Type:application/json' -d @delete_data_condition.txt
使用上述语句删除过期数据,删除条件置于delete_data_condition.txt
文件中.
需要注意,因为Elasticsearch
版本控制的原因,容易导致数据删除失败,因此添加conflicts=proceed
条件解决版本冲突导致的数据删除失败.
问题解决
经过上述操作后,发现Elasticsearch
数据库的负载明显下降,观察Topic
的消费情况,发现LAG
指标在快速回落.
待观察一段时间后,发现数据分析模块能够正常聚合,业务恢复正常.
不过还是留下了问题,就是因为Elasticsearch
导致Flink
消费Kafka
数据过慢,出现了重复读
进一步拖慢聚合速度,这个问题需要后续深入研究解决.
这就是一个删除脚本异常引起的血案,中间件虽然带来了极大的便利,但是也提升了问题排查的难度.
因此,不仅要知道中间件怎样部署,更要学会如何部署更优,为业务的正常运行奠定基础.
PS:
如果您觉得我的文章对您有帮助,可以扫码领取下红包或扫码支持(随意多少,一分钱都是爱),谢谢!
支付宝红包 | 支付宝 | 微信 |
---|---|---|