原因:2017年2月6日 星期一 翻译外文blog。
说明:仅供个人学习
用途。
在Episode1的Openstack侦探故事中,我被叫到犯罪现场:我们的基于OpenStack的私有云中心器件。什么人或什么东西造成了我们的虚拟负载均衡可以拍动高度可用的IP地址。tcpdump显示我有个VRRP包具有时间延迟。这些延迟源于第一个平衡器,主负载均衡器。
在发现罪魁祸首可能是藏在里面的虚拟机,我取来我的助理sysdig我们ssh登录到为loadblancer01。与sysdig一起,开始提出问题:非常激烈,不舒服的问题,终于到达深层次。
sysdig是一个相对较新的工具,基本上所有的系统调用的痕迹和使用lua脚本–称为凿子–捕获系统调用序列的结论。总的来说,它就像tcdump一样被系统调用。因为每一个想要做有利事情的进程都需要被系统调用,你的系统的行为非常详细的视图。sysdig发展成锋利的瑞士军刀,你应该尝试一下它;特别是,读这三篇博客了解sysdig的能力,相信我。
sysdig是好的侦探助手,将其立即投入工作,把所有的问题和答案记录在一个文件中。
$ sysdig -w transcript
我对发送指令的系统命令,即实际发送keepalived的网络包问题的指令很感兴趣。
在一个进程被系统调用时,进程暂停直到系统调用已由内核完成,并且只有在执行的过程中恢复。
我感兴趣的是调用,即从用户进程到内核的事件方向。
$ sysdig -r transcript proc.name=keepalived and evt.type=sendmsg and evt.dir='>'
这引发了相当多的证据。但我想找到时间差距大于1秒的。我把我的夹克里的Lua从我隐蔽枪套里面拿出,在两条发送信息系统调用之间快速发射了一个凿子。
$ sysdig -r transcript -c find_time_gap proc.name=keepalived and evt.type=sendmsg and evt.dir='>'
370964 17:01:26.375374738 (5.03543187) keepalived > sendmsg fd=13(192.168.205.8->224.0.0.18) size=40 tuple=0.0.0.0:112->224.0.0.18:0
找到了!一个大于5秒的延迟出现在我眼前,我仔细的观看事件号为370964的事件:
$ sysdig -r transcript proc.name=keepalived and evt.type=sendmsg and evt.dir='>' | grep -C 1 370964
368250 17:01:21.339942868 0 keepalived (10400) > sendmsg fd=13(192.168.205.8->224.0.0.18) size=40 tuple=0.0.0.0:112->224.0.0.18:0
370964 17:01:26.375374738 1 keepalived (10400) > sendmsg fd=13(192.168.205.8->224.0.0.18) size=40 tuple=0.0.0.0:112->224.0.0.18:0
371446 17:01:26.377770247 1 keepalived (10400) > sendmsg fd=13(192.168.205.8->224.0.0.18) size=40 tuple=0.0.0.0:112->224.0.0.18:0
现在清晰了,上文中第一行与第二行,远大于1秒的延迟。引起keepalived发送数据延迟的罪犯就隐藏在虚拟机之中,但是,它是谁?