防火墙趣事

最近当了一阵防火墙,期间遇到两个很有意思的问题,分享一下。

注:敏捷开发中设立防火墙主要是为了屏蔽迭代开发过程中的外部干扰,譬如故障定位、环境支持等等。

【问题1】

某日,有业务产品同事反馈,使用我们系统A时,发现与其对接的系统B发生异常,导致无法进行业务操作

排查:

1)浏览器登陆系统B,发现登录异常,无法访问(尝试复现问题现象,确认)

2)于是逐层排查,从网关nginx、uwsgi一层层排查,发现服务端的日志打印异常(理解系统架构,逐层递进)

3)根据异常日志,发现某个配置ini文件大小为0,导致无法正常启动服务

4)于是邮件反馈原因,问其是否有人为或者自己编写的小脚步误删导致

5)反馈未有特殊操作,这时又有同事反馈,之前也有同事遇到过一例类似问题,于是,警觉起来(保持警觉)

6)查阅操作系统日志、history记录等均未发现异常(掌握基本的操作系统知识,全面阅读日志)

7)不得其解,遂起身舒展一下身体,喝口水(当focus太久的时候,适当defocus,放空一下)

8)突然,灵光一现,大半年前,老形态的版本也遇到过类似问题,依稀记得当初操作系统专家给出答复是sed命令导致异常(发散,回想,找到灵感)

9)立马翻阅历史邮件,证实确有可能为sed命令导致(sed操作之后,如果os的内存没及时写入磁盘,此时断电会导致sed过的文件大小为0)(历史经验,保留关键资料很重要)

10)按此思路,查阅异常服务所在容器的启动脚本,果然发现有个初始化的shell脚本中有两行sed命令操作的文件

11)检查两行sed命令操作的文件大小,均变为0

12)原因基本锁定,为进一步确认是问题,进一步查看容器日志和操作系统messages日志

13)发现在容器启动后的不久,立马发生了操作系统重启的日志,并且时间点均能对上,最终锁定此问题(再次确认验证)

【问题2】

某日,有业务产品同事反馈,部署系统A,采用双机方式部署后无法登陆系统,而采用单机部署时正常

排查:

1)登录系统检查,发现异常的原因为业务容器依赖的kafka容器启动异常导致(老套路,先亲自复现确认)

2)于是,检查kafka容器启动日志,发现连接zk失败,报错Host is unreachable

3)为何会连不上呢?zk和kafka都是在同一个虚机内的啊,在虚机内部ping zk的地址一切正常

4)这时仔细一看zk采用的是host模式,容器内部使用的网络跟虚机一样,而kafka容器使用的是bridge模式,对应docker0网桥上分配的172段地址,两者地址不是同一网段(了解系统模式的差异,检查对比,发现差异)

5)于是进入一个同样采用bridge模式的容器,在容器内部尝试ping zk,发现果然不通(进行对比试验)

6)这又是为何呢?就在一个虚机内部,网络比较简单,不应该啊

7)于是,翻阅系统日志,这时,在messages日志中发现一段可疑打印:kernel: IPv4: martian source 172.17.0.1 from 172.17.0.12, on dev docker0(检查日志很重要)

8)恩。。。看来内部linux的路由有问题了

9)那就ifconfig检查一下IP设置

10)果然,发现有个心跳平面的网卡设置成172.16.0.2/24,而docker0的网关地址默认为172.16.0.1/16(注:单机模式是不用设置心跳平面的,双机模式时双机软件需要设置心跳平面)

11)于是将异常心跳平面网卡down掉,重启kafka,此时kafka启动正常,最终锁定此问题(确认问题,进行验证)

总结一下这过程中需要我们get到的一些知识点:

1)不要只听别人说,要自己看

2)要理解系统(这里想到一本书:《调试九法》,推荐一下)

3)要全面观察

4)大胆猜想,小心验证

5)必要的试验对比很重要

6)重视平时的细节经验,关键时刻很有用

7)思考问题时,需要focus聚焦,也需要及时defocus抽离发散获得新思路

我们可以进一步学习到一些知识点,譬如docker最基本的bridge、host、none三种基本的默认网络模式的差异(这个推荐一下CloudMan的每天5分钟系统,有兴趣的同学可以微信公众号或者cnblog或者csdn搜索学习)

珍惜每一次与系统、与人的交互,在交互中学习成长。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181118G12BYM00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券