生产环境下容器化的EMQX持续重启问题非接触排查实战

前言

在最近的一个项目中首次将某个分系统全部容器化,其中不乏red5,redis,emqx等组件,并支持以docker-compose的形式启动。结果在部署的过程中遇到了两个关于EMQX的问题,特别将排查过程和一些经验记录一下、特别的是,这次也是一次非接触排查哦,即本人无法直接接触到系统,只能经由别人中转才能了解到系统的行为。

背景故事

这个项目是一个典型的定制型软件开发项目,用户属于特定行业领域,网络条件特殊,无法连接互联网,只能线下运维。项目基于原有系统开发而成,其中有一个分系统比较复杂,每次技术人员部署和联调都是十分费力和耗时。趁着这个项目,将这个分系统做了容器化改造,同时支持docker-compose一键式启动。以此希望能够降低现场工作人员的工作量和难度。
这个分系统中包含了一个叫EMQX的组件,它的前身叫EMQTTD。由于整个分系统全部都容器化了,也就采用了它的容器化的版本,用的是V3.1.0版本。本次排故的主角就是它。本次遇到的问题一共有两个:1)EMQX启动失败不断的重启。2)刚刚启动时一切正常,但过了10多分钟就出现连接EMQX中断的问题,重启客户端即可恢复服务但一会又会出现连接中断的问题。我们这次着重排查第一个问题,第二个问题留着下期来处理。

排查过程

周五临近下班时间,现场人员反馈说部署完了,但是有一点很奇怪,就是EMQX总是自动重启,我这心一下就凉了,这个问题听起来可不小。赶紧让现场人员试用docker-compose logs -f --tail=200 emqx 获取一下emqx的日志看看怎么回事。核心内容如下图所示。
生产环境下容器化的EMQX持续重启问题非接触排查实战_第1张图片
我大概一看是权限问题,就让现场人员到主机的/opt/emqx/etc这个路径下寻找有没有emqx.conf这个文件,现场人员翻了翻连这个文件件夹都没有。于是直接把emqx这个文件夹建立起来,再通过chmod赋权限,再重启服务。本以为可以高枕无忧的睡觉了,但10分钟后反馈仍然重启。

隐隐感觉有些头疼,于是去翻了翻emqx的github的issue并没有发现类似的现象。只能依然按照这个权限这条路线排查。既然是权限问题,那么给最大权限就没有问题了吧,依稀记得容器是可以以特权运行的,但十分危险,这时管不了了,先试试再说。于是调整启动参数以特权权限启动,如下图所示。
生产环境下容器化的EMQX持续重启问题非接触排查实战_第2张图片
于是将参数转告现场人员,这次等了半天,因为现场人员搞别的去了,以致于我都以为问题彻底解决了。但无情的消息传来,仍然在自动重启,权限没有效果。由于已经周日下午,业主值班人员都回家了,现场人员也要休息一下,只能暂时作罢,周一再处理问题。
这一次没了头绪,于是静下心来好好想想。转眼到了周一上班时间,赶紧进入公司的仿真环境,启动了测试系统,并没有出现用户那的持续重启的问题。这么明显的阻塞性问题应该不可能忽略的。由于仿真环境的OS与用户的保持一致,各种软件也全部一致,因此估计是系统设置方面的问题。
再翻出错误日志看看,日志里显示那个配置文件没有访问权限,但那个路径在主机上并不存在啊。忽然想到这个是在虚拟机里的,在没有mount的情况下,容器是没有办法访问普通的主机物理存储路径。赶紧让现场人员执行一下docker inspect 容器id,发现volume并没有在默认的var中,这才回想起来由于部署的服务器是用户指定的机器,虽然都是redhat系统,但磁盘划分很奇怪只给了/var路径20G的空间。再部署过程中出现了空间不足的问题,于是调整了docker的daemon.json文件的graph配置,当时也没有在意,现场人员设置到了/home/docker文件夹,但这个路径并不在用户主路径下。


于是怀疑由于docker的volume路径的变更到了非root也非本用户的路径下,导致emqx在写入配置文件出错,于是产生了这个错误。


于是想去翻emqx的源码,但是网络实在是太low了,一直卡在274kb不动。。。,只能退而求其次了,这样问题基本定位成功,解决起来也很简单,就是将docker的volume配置复原。

错误定位后,联系现场作业人员操作服务器。

  1. 往/var又分配了100G的空间
  2. 清空镜像,再重启服务器
  3. 再将所有镜像都重新导入一遍,
  4. 执行docker-compose up -d

经过漫长的半天时间的等待(改变挂载点要经过用户确认),终于镜像顺利导入完毕。docker-compose up -d执行完毕后,漫长的2分钟过去了,全部服务启动,emqx并没有出现自动重启的迹象,至此自动重启问题解决完毕。

总结

  1. 平时项目中总是无意之间避免的东西可能隐藏着很大的隐患
  2. 越是困难的地方越是要经常做(CI同理)
  3. 对于任何项目而且建立尽量真实的模拟环境是非常必要的,特别是对于一些企业级用户
  4. 在一个问题一直都解决不了的时候,也许暂时的放一放清空一下大脑再回来就能找到些新的思路。

你可能感兴趣的:(生产环境下容器化的EMQX持续重启问题非接触排查实战)