使用 Google spreadsheets 画图并分析问题

之前也经常使用 Spreadsheets,但是仅仅是一些简单的数据处理外加一些简单的函数,直到我们想分析某个时段具体的 return code 情况,我突然想看看 Spreadsheets 能否直接出图。后来发现是可以的,只要以 add-ones 的形式添加一个叫 "QuickFit" 的插件就可以了。
这是除了 gnuplot 之外的另外一选择,优势是美观漂亮。
比如我们通过 zbx 拿到的 4xx、5xx 分析具体的错误类型。

通过
Spreadsheets,加入各个时段的数据,就能得到下面的图形

再进行下面的分析,看图一目了然,简单多了:-)

关于 ARP 的一些问题(arp cache, lvs arp, arp hijack)

涉及到 ARP 的问题还不少,包括之前 arp proxy 的问题。这里主要总结三个问题。

ARP 缓存(cache)
关于 Linux 上 ARP cache 的 timeout 时间,根据这篇文档的描述,并不是一个简单的 /proc/sys/net/ipv4/neigh/default/base_reachable_time_ms 开关能够决定的,这里面需要考虑很多的因素。
基本上,在 cache 的里面的 entry 有 stale/invalid/failed/reachable/delay 这几个状态:
# ip neighbor show
192.168.1.24 dev em1 lladdr 00:16:36:4e:3a:56 DELAY
192.168.1.10 dev em1 lladdr 84:2b:2b:76:86:6e REACHABLE
192.168.1.247 dev em1 lladdr 00:16:3e:06:01:20 DELAY

对于 ipv4 的路由表来说,里面有一套复杂的垃圾回收机制,总的来说,这个失效的时间通常在 5-10min 之间,并且跟随不同的 kernel 时间不完全一致,可以通过缩小 /proc/sys/net/ipv4/route/gc_timeout 的值来让 cache 里面的条目尽快的失效,但是依然无法保证。这里面涉及到不少 gc 过程,像 rhash_entries, net.ipv4.route.gc_elasticity, net.ipv4.route.max_size 以及 net.ipv4.route.gc_threshold 这类参数是需要结合起来调整的,具体的原理以及使用方法可以看这里。回答该问题的作者同时还写了一个仅仅通过 ARP 协议来侦测操作系统的 Neighbor-Cache-Fingerprint 工具,相关的原理可以看这里
说了这么多其实是想引出个我们线上遇到的一个问题,估计绝大多数的工程师一辈子都不会遇到。
正常情况下,服务器都只配有一个内网 IP,路由表也很简单,只要添加一条默认的通往 default gateway 的路由就好了,现在假设该路由表是下面这样的:
# route  -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 em1
0.0.0.0         192.168.1.24    0.0.0.0         UG    0      0        0 em1

可以看到,默认的网关指向了 192.168.1.24,现在,我们有这么一个需求,需要将绑定在 A 机器上的 192.168.1.24 这个 IP(同时也是充当的整个内网的网关机器的) 迁移到 B 机器上。最初,我们猜想的是,由于迁移了物理机器,虽然对于客户端来说,IP 没有变,但是 MAC 地址变了,因此可能需要手动的刷新下所有客户端的 ARP 表,这样才能及时的获取到正确的 MAC 地址。但是猜想毕竟是猜想,这跟我们实际测试以及最后线上碰到的情况完全不同,实际情况是什么了?在我们切换将 A 机器的 IP 下线,接着绑定到 B 机器之后,几乎是同一时刻,所有的机器就正确的识别到了更新后的 B 机器的 MAC 表。 也就是说,切换了网关之后,并不需要我们手动的干预,客户端就能「自动的」发现情况并主动更新。为什么会这样?我到目前为止并没有一个准确的结论,不过我猜想应该跟上面涉及到的几个链接有很大的关系,具体的我没有深究。

Continue reading

sar 的图形化

用了这么多小巧的监控工具,发现还是 sar 最强大,系统级别的 metric 是应有尽有,不管是实时的秒级监控还是历史数据,对分析近期(比如前一天或者前几天)出现的问题非常有帮助,这比不管是 Zabbix,Nagios 之类的「系统」要强大的多,典型的开相即用的好工具。默认是 10min 一次数据,这个不能完全满足我们的需求,目前我们有部分机器将 interval 缩小到了 1min 一次,并且将默认的 7d 的保存时间延长到了 90d。除此之外,就剩下出图了。
要是闲的蛋疼,可以使用 gnuplot 来把自己关心的所有 metric 全部画出来,但是这个比较麻烦,之前我自己用 gnuplut 玩了几天,对于 mission critical 场景不适用,有时候是等不及你把脚本一个一个写好再运行的。
后来找到了一个叫 Ksar 的工具,非常的方便,导入 sarxx 文件即可自动出图,到目前为止没有找到比他更方便更简单的方式了。唯一的不足是没有把 sar -A 列出来的所有 metric 都画出来,不过对于一般的问题,Ksar 出的图足够用了。Ksar 的启动图是不是很像 CS 中的场景。

对于昨天以及之前的数据,可以直接到 sa/sarxx 去取,但是对于只有 saxx(比如当天的数据或者由于某些原因 sarxxx 文件丢失了) 的文件,首先需要通过 sar 获得 sarxx  文件,然后需要将 12 小时制转换成 24h 制的才可以丢到 ksar 里面出图:
# LC_TIME="POSIX" sar -f sa30 -A  | tee sar30

注意LC_TIME 这个环境变量。另外,阿里在此基础上搞了个 tsar,个人不是很看好,原因见这里

 

ref:
http://honglus.blogspot.com/2011/02/graphing-sar-output.html

http://brablc.com/2011/06/06/how-to-change-sar-output-time-format-to-24/

kindle Fire & kindle PaperWhite

12 年托我司 CTO 从 US 带了台 Kindle Fire 回来。用了两年了,实话说,体验不是很好,首先太重,其次太厚,最后归结起来就是拿在手里不舒服,尽管是一个深度定制过的 Android,我用到的功能寥寥无几,主要就是看书,其他什么照片电影包括各种 app 的安装我基本没碰过。在 Fire 上看过的书应该不超过 10 本,之前也妄想在上面看看专业方面的文档,后来发现完全行不通,连基本的高亮做笔记的功能都没有。
年初公司发了台 PaperWhite,虽然价格只有 Fire 的一半不到,但是使用起来却比 Fire 好的多。当年向 @HDWei 借个 Kindle 3 体验了个把月,除了翻页比较慢,需要配备一个外置的阅读灯之外,整体感觉还觉还是蛮爽的。现在 PaperWhite 修正了以上的缺点,内置的阅读灯晚上熄灯看书非常方便,机身比 3 也轻不少。没理由不喜欢它,推荐。


bonding 跟 IPv6

bonding 跟 ipv6 这两个 module 看上去没任何的关系,但实际上他们前者依赖于后者:
$ lsmod  | egrep 'ipv6|bonding'
bonding               127060  0
8021q                  25058  1 bonding
ipv6                  322541  57 bonding

所以如果在 modprobe 里面通过 "install ipv6 /bin/false" 的方式禁用了 ipv6,在加载 bonding 的时候会出现无法加载的情况。这里给出了一个 workaround
看上去像是个比较脑残的设计,对于我这个有轻微洁癖的工程师来说,看到下面这样的 ss 确实不大舒服。
Recv-Q Send-Q           Local Address:Port               Peer Address:Port   
0      64                          :::28633                        :::*    

不清楚当初写这些 module 的人怎么想的。

通过 execv(snoopy) 来做用户行为 audit

github 有个叫 snoopy 的项目,专门用来做 audit,比系统原生的 auditd 好用的多,思路很好,关键的就是执行任何的命令之前确保第一调用的是 /etc/ld.so/preload 里面的 snoopy.so 这个动态库文件,而他调用的则是 exec()。
* execl
* execlp
* execle
* execv
* execvp
* execve
上面 6 个 sys call 的区别仅仅在于 arg 是 list 还是 array,是否使用了当前的环境变量已经 PATH 的使用。详细的区别请看这里(1, 2)。  
顺便提下 fork 跟 exec 的区别

当然,该服务并不是那么的完全,最少有下面几个问题:
1. 默认只接受 4096 长度的 argv,超过的或直接 trunk,这个不是什么大问题,可以在源码里面直接修改其 MACRO SNOOPY_MAX_ARG_LENGTH,增大到你需要的长度就好了
2. 对于 pipe 的处理,snoopy 会分别记录每一个 pipe 下的命令,然后分别打到 syslog 里面
3. 性能,网上有说会对性能产生一定的影响,目前来看,当然会有影响,毕竟多调用 sys call,但是从我们线上使用的情况来看,微乎其微,不管什么方案,最终都是 tradeoff 的结果

有人想做 audit 就有人想 bypass,结果还真有人想出了一套方案,简单的说就是在加载 snoopy.so 之前通过 dlopen() 加载这段 bypass 的代码。这仅仅是从技术的角度来分析,实际的线上是通过制度保证绝对不允许有任何人突破这道红线的。