![2b3a6fcebff5a1de731aa79ccc64a91f.png](https://i-blog.csdnimg.cn/blog_migrate/dc3932dbec336ee126e371a0e7b6119f.jpeg)
在现网环境发现分析模块发送告警时,调用告警函数日志中出现错误提示:urlopen failed,但复测调用缺一切正常。
该模块调用告警函数后,会将参数传给机器上的告警封装脚本alarm_client.py,随后调用http_post将数据发送到事件中心进行告警。路径为:策略模块(调用发告警函数)->告警框架(附加信息调用alarm_client.py)->告警脚本(传输给server端实现告警)。
推测1:字符编码问题
因为在日志中发现乱码,怀疑是内容无法正常传输导致的。但告警失效是偶发的,这会与不同告警的内容编码相关吗?pf表示所有内容是gbk编码的,在utf-8格式日志中显示为乱码是正常现象。
推测2:脚本逻辑异常
因为在不同机器的多个不同脚本都出现问题,推测并非某个脚本存在编码或逻辑问题导致失效。
推测3:告警server端处理不过来
zn表示,在相关时间段没有收到对应请求。
……
这个发工单模块,有异常记录插入到DB,且失败会重试一次,于是怀疑是perl里使用双引号方式调用有问题,建议改成调用execv函数族实现,同时也避免命令注入。
ps:不过这个和异常应该无关…
pss:发现perl调用system、open或者反斜杠都是execv调用的形式,不过exec会在原有进程上执行而不是派生子进程:
![f9c33c4cbc7ccda237bbf9bb1321e1d4.png](https://i-blog.csdnimg.cn/blog_migrate/727ddca54173791d870559d6f9cf8c78.jpeg)
后来,pf在alarm_client.py里找到对应错误。(是的!!之前我一直没注意有这样的日志)
[2019-03-03 06:11:07] alarm_client.py (main)-180-INFO - check_flag: 1
[2019-03-03 06:11:07] alarm_client.py (http_post)-73-INFO - jdata: {"xxxxx"}
[2019-03-03 06:11:07] alarm_client.py (http_post)-82-INFO - Reason: [Errno -2] Name or service not known
[2019-03-03 06:11:07] alarm_client.py (main)-189-INFO - request return: urlopen failed
[2019-03-03 06:11:07] alarm_client.py (main)-180-INFO - check_flag: 1
[2019-03-03 06:11:07] alarm_client.py (http_post)-73-INFO - jdata: {"xxxxx"}
[2019-03-03 06:11:07] alarm_client.py (http_post)-82-INFO - Reason: [Errno -2] Name or service not known
[2019-03-03 06:11:07] alarm_client.py (main)-189-INFO - request return: urlopen failed
连续两次调用都出错了,原因是“Name or service not known”,这时就比较清晰了——这个异常不是必现,而是每天大概出现一次,通过换成更可信的dns服务器解决,使用dnsmasq后异常不再出现。
复盘点
1、没有在第一时间想到是域名问题,其实在发单脚本里已经有相应异常提示
import
早点发现就不会走那么多弯路了。
2、作了很多无依据的猜测,推论站不住脚,比如编码问题。以后要警示自己不要想到什么就认为是什么,要合理化。先入为主实在太危险,还很容易会误导人。