猜测在学习新工具中的作用,一个实例

keys

1.

当年我参加李YL老师组织的Linux内核源码讨论班,大家坐教室里,人手一本厚厚的《Linux内核源代码情景分析》。多厚呢,上下册,单册800页左右。我们都把书摊在桌面上,举起来太累了,听轮值的某个人讲,说我看到哪哪儿了,这一段的意思是啥啥,这段代码引用了某个数据结构,在哪哪页呢,那个人讲,我们就哗哗翻书。

用翻书的办法讨论,因为那是2002年前后,教室里没有计算机,没有笔记本,没有投影仪,也没有平板。

轮到我讲了。我讲了两页,然后提到某某处我猜是怎么怎么回事,假设如此,那么我们继续往下看,某某段的说法就容易解释。在我结束的时候,康凯同学点评,他说: 杨老师你不能这么整啊,咋能”假设”呢,你应该找*到底*是什么回事。我问,在哪找,咱们没机器代码查起来慢啊。他说:在书上找啊。

我拒绝了他的读书方法建议,答复如下。我本科是学电子的,是物理系出身,我所受到的教育就是,先假设,然后用实验事实证实或推翻假设,从我假设以后书上后面的那些段落,都是用来证实或推翻我的假设的依据。

2.

这让我想起书上讲的妈妈给孩子讲睡前故事。妈妈每当讲到关键时刻,就对孩子说,你猜后面会发生什么呢。然后孩子就自发地产生了编故事的能力。书上是这么讲的,我妈没给我讲过睡前故事,所以我也不知道是不是真的。不过,听说过一千零一夜故事,我担心那孩子被悬念勾着更睡不着了吧。

当听到真正的故事时,还会和自己头脑中的对比,”这不合理,杜丘怎么就会忘了装子弹”,”这个设定太取巧了,谁能想到杀人犯还有个双胞胎”。

我们在听故事的时候,对情节和人物确实是有预设 (猜测) 的。知识不仅来自书本 (!),而且来自猜测。然后我们需要根据猜测设计实验,检验我们的猜测正确与否。如果猜测对了,我们就快捷地得到了新的知识,虽然书上可能没写--书上并未写全你要用到的所有的知识,所以也不要预期可以依照书本生活和工作。

猜测-设计实验验证-使用知识,这是成熟的工程师区别于初学者的一个重要标志,因为工程的一部分正是实验科学。我很多年以后才知道,从培根的实证主义到波普尔的证伪主义,到罗素的对一致性的追求,设计实验的朴素观点背后还有哲学理论的支撑。

不知道这么年过去了,康凯同学对当年的讨论作何感想。他们毕业的时候聚餐叫我去喝酒,刚好没有成行,所以没有来得及问他那时的看法。不过计算机系的同学可能因为缺乏充分的实验,所以一直以来给我这样的印象,重课本而轻实验设计。谷同学和孙同学曾经非常惊讶地对我说:鞠同学怎么可以这么做呢,她根本不知道书上确切地是怎么写的 (当然也不知道知识是不是就是那样) ,就说,那咱们试试吧;一试,行,就说咱们就这么整吧。我当时的评论,这正是鞠同学厉害的地方。

猜测是建模/谓词判断/命题,设计实验是根据逻辑推论--如果猜测正确,那么这样设定实验,结果该当如此,如果结果不如此,那么猜测是错误的。这样,猜测-设计实验验证,以后我们就得到了新的模型/定理,作为工具可以应用于符合条件的场合,用于预测结果,用于改变环境。

老师有的时候提到”学活了”或者”学死了”,区别大体指的就应该是这个吧。

3. 一个实例,用rrdtool提取cacti数据

以下的故事,用以展示猜测在整个学习使用新工具流程中的位置。

3.1. 要显示流量,读cacti,是图片,不能 XML parse

需求是这样,要在程序中显示校园网各汇聚层交换机的流量 (上行和下行)。你可以想像客户站在大屏幕前,指着天气图说,你看就是这条线上的数据,要显示在这里这里和这里。

%e5%a4%a9%e6%b0%94%e5%9b%be2

天气图是cacti展示出来的,cacti是网络流量监控的图形化工具,配置以后通过cacti已经可以查看各汇取层交换机的流量数据了,点击线路,就可以看到。

%e6%b5%81%e9%87%8f%e5%9b%be

凡能看到的,就能抽取。所以主力研发郑同学就说,那我先研究一下 java httpclient 吧。我否定了这个计划。我否定的并非使用 httpclient,而是投入时间去尝试学习研究,而是先假设这一部分不会有问题。httpclient是著名的apache的项目,而且濮同学早就用过,所以是确定地技术路线,没有风险。反倒是另一件事情有高风险,并非”凡能看到的,就能抽取”。httpclient能模仿浏览器的各种行为 (js解释呢?),但是 xml parser 部分 图片是不可以”抽取”成文字的。只要没有变成文字,那么就不能放心,客户可能打算换字体字型字号呢。万一天气图里的数据是图片,httpclient这条技术路线整体需要放弃。

天气图里的数据是图片。

而且从图片的 caption 和 URL 里得不到文字。

故事的第一幕就此结束。英雄遇到灾难,离开故乡,开始历险。

3.2 cacti数据可以用rrdtool读取,UNIX时间戳,zhumao同学说

我和向龙同学分别对着自己的显示器,显示器后面很多公里线路以后是郑同学,我们都愁眉苦脸。zhumao同学催,啥时候能去吃午饭呐。我敲键盘,”要完了啊。”

zhumao同学远程说,cacti的数据都在数据库里,可以抽出来。

峰回路转,午饭可以下咽了。

下午,我和向龙同学研究从哪个”数据库”里抽数据。向龙介绍cacti的数据库配置的是mysql,然后我俩把mysql数据库翻个遍,各个表,各个字段。从尺寸上看就不会容纳那么多日志。

但是zhumao同学技术上很可靠,应该不是虚言。所以我们判定,”数据库”一词不是指关系型数据库,而是泛指能存信息的容器。

zhumao同学远程说,抽取的工具是rrdtool。过了一会又说,时间节点用的是UNXI的1970年时间戳。

希望重新燃起,我看到大半夜的微信上向龙同学和郑同学进行各种尝试。

3.3 猜不到数据在哪里

我以为故事快结束了,但是向龙同学和郑同学说,”猜不到数据在哪里”。

“不是说用rrdtool么,zhumao用过啊。”

“zhumao只是说可以用rrdtool,他并没有声称自己用过。”

郑同学已经把rrdtool的语法研究得八九不离十了,就是抽出来的数据和天气图上显示的对不上号。

故事一般都是这个路线,一到关键时刻--钥匙就丢了,计算机刚好没电,掌握密码的人被打死了,主角的最主要助手突然叛变,”其实我是卧底”。为什么到关键时刻才会这样,之前一点也不。因为关键时刻是这么定义的,出现了困难的时候,如果不能克服,那就是完蛋。而在实验和工程中,每一个困难如果不能克服或者绕过去,那么就会完蛋,所以有N多关键时刻。比看警匪片和侦探故事还刺激。

4. graph properties 可以查看源代码 rrdtool graph

向龙同学提供我授权登录cacti (天气图及设置) 和 ssh到rrdtool工具所在操作系统,更关键地,他随时提供给我现场的部署、状态,比如天气图上的线路和rrdtool数据库的对应关系,他和郑同学尝试过的指令和结果。

长弓已经架好,重装步兵阵列在前,巨龙就在前方洞穴之中,只差最后一击。当然,这一击以后发现还要再出击N次也是常有的事,不过如果这次失手了,那就是最后一击,然后我们全军覆没。

4.1. 猜测及实验验证

zoom_graph
向龙给我展示的是这张图。整张chart以及图例和注释全都是一整张图片,PNG格式。我确认了我看到的和战友们所看到的相同。天气图是一张图片,我在郑同学这样声称以后也确认过一次。

猜测: 这张图是此刻实时生成的,是从”数据库”里读出来的,不是原来在磁盘中的。

否定: 向龙指出,zhumao在磁盘确实找到过这张图片。 (赞叹zhumao的反向工程能力)

再猜测: 磁盘里的这张图片也应该是生成的,用rrdtool工具从”数据库”里读出来,然后生成的。

猜测的依据: rrdtool 是 round robin database,文本或压缩文本的存储效率要比图片高很多。理智的设计不会存储图片。

鼠标在图示右上角的小扳手上悬停,显示tips为 properties,左键单击,是这个界面。

graph
长得真是如我期待,上面是代码,下面是代码生成的图。

那段代码是:

—-代码开始—-
/usr/bin/rrdtool graph – \
–imgformat=PNG \
–start=’1474880074′ \
–end=’1474880360′ \
–title=’H3C12508 – Traffic – Ten-GigabitEthe’ \
–rigid \
–base=’1000′ \
–height=’120′ \
–width=’500′ \
–alt-autoscale-max \
–lower-limit=’0′ \
COMMENT:”From 2016/09/26 16\:54\:34 To 2016/09/26 16\:59\:20\c” \
COMMENT:”  \n” \
–vertical-label=’bits per second’ \
–slope-mode \
–font TITLE:10: \
–font AXIS:7: \
–font LEGEND:8: \
–font UNIT:7: \
DEF:a=’/var/www/html/cacti/rra/h3c12508_traffic_in_190.rrd’:’traffic_in’:AVERAGE \
DEF:b=’/var/www/html/cacti/rra/h3c12508_traffic_in_190.rrd’:’traffic_out’:AVERAGE \
CDEF:cdefa=’a,8,*’ \
CDEF:cdefe=’b,8,*’ \
AREA:cdefa#00CF00FF:’Inbound’  \
GPRINT:cdefa:LAST:’ Current\:%8.2lf%s’  \
GPRINT:cdefa:AVERAGE:’Average\:%8.2lf%s’  \
GPRINT:cdefa:MAX:’Maximum\:%8.2lf%s\n’  \
LINE1:cdefe#002A97FF:’Outbound’  \
GPRINT:cdefe:LAST:’Current\:%8.2lf%s’  \
GPRINT:cdefe:AVERAGE:’Average\:%8.2lf%s’  \
GPRINT:cdefe:MAX:’Maximum\:%8.2lf%s’
—-代码结束—-

“/usr/bin/rrdtool”,这是一段命令行。

ssh到服务器,向龙告诉我去哪里可以找到 rrdtool 和 数据库文件。我跑了一遍上述代码,输出一个png文件到文件系统中,正是我想期待的。

故事发展到这里,我们知道,”/usr/bin/rrdtool graph”及正确的参数可以从数据库中抽取数据。只是抽取得到的形式还不尽人意,我们想要文本,得到的是图片。

就此验证zhumao的猜测都是正确的。

事实上,在另一条分支上,向龙和郑同学走得更远。他们已经得到了纯文本的结果,用的指令是”rrdtool fetch”,只是抽得的结果还没有与天气图对应上。”rrdtool graph”直接证实了zhumao的猜测是正确的,抽取数据可行。

4.2 手册

运维和编程的著名格言: RTFM — Read The Fxxking Manual.

我找到官方站点,[https://oss.oetiker.ch/rrdtool/doc/index.en.html],去读手册。此前郑同学也已经独立到过这里。

然后我根据 rrdtool graph 手册解释了刚刚那段代码里的这一小段

CDEF:cdefa=’a,8,*

其含义中的重点是: 乘以8. 因为数据库里以字节为单位的,输出的图形是比特为单位的。

我执行了下面这段
—-代码开始—-
$ rrdtool fetch h3c12508_traffic_in_190.rrd \
> –start=’1474880074′ \
> –end=’1474880360′ \
> AVERAGE
traffic_in         traffic_out

1474880100: 1.9393791780e+08 4.9525977422e+08
1474880400: 1.9499877230e+08 4.8637343825e+08
—-代码结束—-

然后手动 (用 windows calc)计算

traffic_in :
1.9393791780e+08 * 8/1000000000 = 1.5515033424
1.9499877230e+08 * 8/1000000000 = 1.5599901784
平均值为 (1.5515033424+1.5599901784)/2 = 1.5557467604
作为对比,图示中的数据 Inbound 为 1.56G.

traffic_out :
4.9525977422e+08*8/1000000000 = 3.96207819376
4.8637343825e+08*8/1000000000 = 3.890987506
平均值为(3.96207819376+3.890987506)/2 = 3.92653284988
作为对比,图示中的数据 Outbound 为 3.93G.

抽取出的数据与图示吻合了。

4.3 放大图示,对比数据,向龙同学说

我展示方法,向龙同学说,我乘以8了啊。我问你从哪边往哪边乘的。他说,因为不确定到底如何,做了不少猜测,从两边分别都乘过。这是本故事的另一个寓意了,猜测的时候如果知道那样一定正确,尽可能减少其他可能,就更好。不就此展开。

事实上,这个实验的最后一击并不那么简单。向龙同学提供了对比数据的spec说明: 放大图示到某个具体的分钟,抽取的数据与这个具体的分钟的数据对比,避免在时间段内平均等造成的误差 (和复杂性)。同时,向龙同学提供了放大图示的手段,郑同学此前不知道放大的方法,我没有想到选取具体的时间节点。

4.4 时间转换,双向;新的关键环节:时区

有的同学可能已经注意到我上面引用的代码中的时间是UNIX时间戳,这是zhumao提示的。具体使用的时候,我的时间戳来自两个来源,(1) 从 rrdtool graph 的代码中抄,(2) 利用在线工具 [http://www.epochconverter.com/] 双向转换。

epoch

我这样找到在线工具的, bing: unix time stamp convert,然后右上角”Switch to Bing in English”。第一页前几个就很好使。

(3)命令行工具,Linux内置

—-代码开始—-
$ date –date=’2016-09-26 17:02 CST’ +%s
1474880520

$ date –date @1474880520
Mon Sep 26 17:02:00 CST 2016
—-代码结束—-

(4) 等实验完成了我才注意到,rrdtool fetch 接受一般的时间格式,还有倒退几分钟这样的功能。可以不用UNIX时间戳的。

在转换时间格式时我注意到有时区,所以为了避免可能的问题,确认了一下操作系统本地时区是东八区,北京时间。

—-代码开始—-
$ date -R
Mon, 26 Sep 2016 17:36:37
+0800

$ date +%z
+0800
$ date +%Z
CST
—-代码结束—-

5. 加强、改进,玩

大局已定,我们对手册里的其他工具做了些尝试。与其说是加强和改进实验结果,不如说像猫抓到老鼠以后行为,”总算抓到了,快让我玩会。”我在程序跑对了以后,也总喜欢再多跑两次,好像生怕它会跑出不同的结果,或者多享受几次正确地运行。

5.1 用命令行过滤数据

为了后续开发方便,我用命令行去除了数据中无用的部分。

—-代码开始—-
$ rrdtool fetch h3c12508_traffic_in_190.rrd -s -5min AVERAGE | tail -2 | head -1
1474879500: 1.9791172526e+08 5.0410319243e+08
—-代码结束—-

其中的 -s -5min 指数据截取的开始时间为从此刻回退5分钟,结束时间为此刻。

5.2. 查手册,得到解释及更丰富的语法

还有导出为xml格式

—-代码开始—-
$ rrdtool xport \
> –start=’1474595681′ \
> –end=’1474595683′ \
> DEF:a=h3c12508_traffic_in_190.rrd:traffic_in:AVERAGE \
> CDEF:cdefa=’a,8,*’ \
> XPORT:cdefa:”IN”
<?xml version=”1.0″ encoding=”ISO-8859-1″?>

<xport>
<meta>
<start>1474596000</start>
<step>1800</step>
<end>1474596000</end>
<rows>1</rows>
<columns>1</columns>
<legend>
<entry>IN</entry>
</legend>
</meta>
<data>
<row><t>1474596000</t><v>9.0713941203e+08</v></row>
</data>
</xport>
—-代码结束—-

导出为json格式

—-代码开始—-
$ rrdtool xport \
> –start=’1474595681′ \
> –end=’1474595683′ \
> –json \
> DEF:a=h3c12508_traffic_in_190.rrd:traffic_in:AVERAGE \
> CDEF:cdefa=’a,8,*’ \
> XPORT:cdefa:”IN”
{ about: ‘RRDtool xport JSON output’,
meta: {
start: 1474596000,
step: 1800,
end: 1474596000,
legend: [
‘IN’
]
},
data: [
[ 9.0713941203e+08  ]
]
}
—-代码结束—-

5.3. 后备方法 rrdcgi, librrd, rrddump

我们还知道些后备的方法,在当前项目中不会用到。

估计可以用于http输出的rrdcgi, 估计可以与其他语言 (C?)联合开发用的librrd,估计可以把数据库倒出来的工具rrddump。

6. 总结

猜测在学习新工具中的作用如此重要,以至于如果你没有猜测的话,就不要按下回车。哪怕你有很多种猜测也好,只要列出一张表来,一个个试过去,留下看起来最正确的那个。但是如果你没有猜测,就失去了主动性,而是被动地观察实验现象,却对支配实验现象背后的物理图景毫无察觉。

据说,李靖与李世民讨论兵法,他说: 千章万句,不出乎”致人而不致于人”而已。
hole
————————————————————

博客会手工同步到以下地址:

[http://zhuanlan.zhihu.com/younggift]

[https://younggift.net/] 悄然支持http2,再次感谢高博先生

[http://blog.csdn.net/younggift]

[http://giftdotyoung.blogspot.com]