ABRTD进程引发ES血案的故事

我是本际云服务器推荐网的小编小本本，今天给大家分享一个有关ABRTD进程引发ES血案的故事，希望可以对大家的运维工作有所启示。

ABRTD进程引发ES血案的故事

故事发生过程

某通信集团割接，数据同步验证日志一致性时，连接ES失败，无法写入和读取，es数据写入不了，影响最新日志入es，应用割接大部分厂商需要查询最新的日志，间接影响到了割接进度。为了保障业务恢复，秉承先抢通后抢修原则，在上级领导及业务厂商沟通下，立即启用应急处理措施，进行切换至灾备ES，切换后索引读写正常，通知厂商恢复业务。

晚上吃完饭，和同事一起赶现场做好支撑准备，我们说，今天割接非常顺利，没什么异常，早点回去休息，正要回去的时候，突然有个业务系统说，查询日志异常，我们马上查询一下手机短信，未发现什么异常短信，是否是业务误报，不管了，以‘飞奔‘的速度跑回现场，所有领导已在现场，下面我们就展开了一系列分析。

我们这套ES是6主机24节点的集群，专门提供业务日志写入，打开kibana看所有集群节点也都正常，看状态也是Green。但是集群写入失败，肯定存在问题，于是看看节点情况，结果节点的索引信息获取失败，ES集群命令已经查不到ES集群节点信息及索引信息，此时需通过日志来分析为什么会如此。分析ES集群日志，发现日志中最早的报错信息发生在5点33分39秒左右，报错信息为连接超时导致无法获取集群和索引信息，并且其它节点也有超时现象存在ES节点超时，就会触发ES集群索引分片重新路由分配，分片移动到其它节点导致磁盘占比上升，引发es集群自动触发提高磁盘水位，过高的IO和负载使整个集群Hang住，此时ES级别分析完成，是185节点与集群通信失败超时，处于假死状态，而为什么185节点会这样，我们进一步对操作系统进行分析，通过自动化运维平台，发现6台主机，有其中一个主机的负载故障前非常高，于是对操作日志进行分析，检查操作系统messages信息，发现185存在系统守护进程abrtd异常导致连接数过多及主机hang现象，息abrtd:Toomanyclients,refusingconnectionsto/var/run/abrt/abrt.socketAug2105:33:37hnes09kernel:INFO:taskjava:21133blockedformorethan120seconds.Aug2105:33:37hnes09kernel:”echo0>/proc/sys/kernel/hung_task_timeout_secs”disablesthismessage。我们通过日志发现引发这台主机的‘罪魁祸首’是abrtd进程引起，而该进程是在操作系统BUG或异常情况会触发，由于是开源的centos未有相应dump生成，只能先重启主机解决。重启主机并重启ES集群，查看es日志显示集群状态正常，集群包含的6台主机共24个节点正常加入集群，集群恢复正常，kibana访问正常。为了防止后续重蹈覆辙，在其它的未发生故障的主机进行梳理，并停止abrtd进程服务，至此整个事件告一段落。