有时候会有些惯性,总是重复的去采坑。当一次又一次的因为这些疏忽而影响到自己时,就一定要好好反思下了。
一. 更新配置\代码后,一定记得reload
是的,切记。特别是在做上线时,一定记得reload一下。可以将上线涉及的操作列到一个清单里面,下次上线时,对着清单操作一遍。
我之前写了一个支付模块,为了方便测试做了个区分:测试环境每次支付1分钱,生产环境每次支付实际的金额,两个环境用env的变量来区分。该模块上线后,为了排查一个问题,更改了env,之后问题找到了,并更新了代码。上线时,将env改了回来,但忘记reload supervisor,结果导致一笔费用收取不正确!好在产品还未推广,并未造成影响,但这件事情中可以看出:
1.调试BUG的方式太原始,应避免去线上调试,可引入ELK之类的工具流来处理(其实后端主要调试方式就是打日志-。-)。
2.实际原因也不是supervisor导致配置不正确,而是supvisor所管理的那个进程!该进程是将配置文件load到内存中运行,所以更改配置后,要重启进程,将新的配置加载进来,而我是用supvisor来管理这个进程的,所以最终表现出来的原因是没有reload supervisor。
二. 确保通过supervisor运行的进程只有一个
是的,切记。比如你的操作不是那么的规范:你先通过supervisord -c /etc/supervisor/supervisord.conf
将supervisor启动了,过了几天后你忘记之前的启动操作了,你通过supervisorctl status
去看进程的运行状态时,看到提示unix:///tmp/supervisor.sock no such file
,你想是不是superiord挂掉了,不管那么多了,先启动吧,于是你做了个操作supervisord
。之后看起来服务都正常了,于是干其他事情去了。可能不久你就会收到同事的反馈:数据不正常!你忙了一个小时,各种打日志,各种看代码,最终结果却是:有两个进程在跑同一个执行文件!你会发现一个是当前supervisor管理的进程,另一个进程的PPID和supervisor的PID不一样!于是你明白了:supervisord
的操作没有杀死旧进程,而是又启动了一个新进程,两个进程同时运行,结果导致你的数据异常。最终你先将旧进程的PPID kill掉,再kill掉旧进程,再reload supervisor,之后终于恢复正常。从这一波的操作可以看出:
1.有些经验不要也罢。当看到unix:///tmp/supervisor.sock no such file
时,一定要好好排查,不要着急去启动。即:遇到问题,不要想着重启!
2.可以使用一些更优雅的方式来运行supervisor。比如你的系统是centos,你可以把supervisor做成一个systemctl服务,就能避免这些问题。
3.reload supervisor之后,一定记得检查下,是不是只有一个进程在跑!
三. 关于supervisor
你可能会问了,都快9102年了,python2马上也要被抛弃了(Python核心团队计划在2020年停止支持Python 2),怎么还在用supervisor?其实就如开头说的,对场景工具的使用也会形成惯性,当你看到要跑守护进程场景时,就想到用supervisor。我觉得这个惯性倒是可以,这也是一种小积累,只是如果时间充足的话,可以多去了解尝试其他同类的工具。十年前我用nagios搭建了一套服务器监控平台,大家觉得不错,现在你说我用nagios做一套监控,大家首先会问nagios是什么,然后会觉得你是远古程序员(当然没也那么夸张,我10年前还在学堂里,nagios是什么也不知道,现在也还有很多公司用nagios,它仍然很有活力O(∩_∩)O )