翻笔记翻出来自己曾经在16年那会儿对Cacti流量监控做过的一次数据分析，于是整理整理写个小系列，分上下篇，留着备用（貌似小米在16年那会儿比较火的一个叫做OpenFalcon的监控平台也使用了类似的数据存储方式，嗯，看来这项技术也不是那么偏啊，哈）。文章里面有些图片是前几年做笔记的时候截取的，只是图片里的时间戳看着有点年头罢了（时间过得真快，都是16年那时候的事了啊~），懒得再搭环境了，直接拿来用了。

  本文作为上篇主要介绍Cacti数据存储方式，下篇讨论怎样针对这种数据存取方式进行自定义提取。

什么是Cacti

  Cacti是一款完善的网络流量监控绘图平台，针对网络监控提供了一套可以快速上手的解决方案。虽然最近遇到有一些追求新技术的大牛会嫌弃这款平台的老旧，但实际上官网最近一次的更新版本是2019年3月30号，而且国外Cacti论坛上各个版块的发帖也是非常活跃的。所以，这款监控平台的生命力其实还是相当旺盛的。

  毕竟，Cacti很好地实现了一款网络监控平台的使命，好用而简洁。确实比起重量级的Zabbix在扩展性上有点吃力，但相对的使用Cacti可以节约相当大的精力投入。其实，拿一些很新的监控平台和Cacti去比较是不合适的，毕竟应用场景有差异。Cacti更适合网络设备的监控，Zabbix更适合那些有着丰富的可定制性的监控，比如主机监控。其实，个人用了近感觉，结合这二者，就已经是无所不能了。

  不过正如上面提到的，简洁的同时，也会带来稍许的不便。尤其在定制化进行数据提取的时候，本文通过对Cacti的数据生成方式进行分析，以达到定制化获取数据的目的。

数据生成方式分析

  Cacti网页界面上的数据检索方式和普通的监控平台一样，通过给定起始和结束的时刻，来获得指定时间段的流量值。然而，这里有个问题，那就是数据的精确程度。

  为什么提到数据精确程度呢，长时间使用Cacti的过程中，我们常常会遇到这么一类情况：比如某一天出现了网络故障导致了流量图形显示的异常（如流量突发），过几天回头再分析图形的时候，故障期间本来峰值很高的流量图似乎变的平缓了，而且此时你看到的数值记录和当时的数值相比，也有所变化，是人为的记忆出错了么，还是监控平台发生了故障？不，其实这正是Cacti的数据存储方式带来的一个“特性”，虽然这个特性不是很讨人喜欢。

  说了这么多，这里我们终于引入了RRD的概念。RRD（Round Robin Database）是一种使用了“环形数据存放方式”的非线性数据库。什么意思呢，Round Robin是一个用于实现“固定数据量大小（fixed amount of data）”的技术，简言之，就是在“给定大小的数据库文件里存放数据”的技术。我们可以把这个数据库文件想象成一个环状，每当有新的数据插入到数据库文件的末尾，也就意味着文件开头最古老的数据将被覆盖（突然想到了国外远古神话中的乌洛波洛斯Ouroboros，一条首尾相连的蛇，结尾处就是最初的开头）。这样一来，运维人员不用像普通的数据库一样去操心数据文件的增长，便于维护。

  但是，我们刚刚说到的rrd数据文件会根据设定好的采集时间，不停地更新然后覆盖之前的数据。那我的历史数据岂不是看不到了？这个担心是正常的，但我们实际上却是可以查询历史数据的，只是像一开始提到的，感觉“不那么精确”了。实际上，在监控平台运行过程中，设备的rrd数据记录文件，对于不同时间段的历史数据确实有不同的详细程度。

  在监控平台上过滤出指定时刻的数据后，点击图形右侧的“小钳子”，查看其生成方式：

  我们可以看到，这个界面为我们详细展示了rrd图形生成的过程：

  其中，需要引起注意的是开头处的/usr/local/rrdtool/bin/rrdtool，这说明下面这一大片文本，不过是这个二进制命令的参数而已。其中这个图形调用的数据来源是下方DEF参数这里指定的/var/www/html/rra/211/804.rrd这个文件，好了，我们的rrd数据库文件的主角终于出现了。

  我们这里分析的是某家企业在2016年8月24日16：30的值为例。通过rrdtool工具，对已获得的rrd数据文件执行dump命令后，可以查看提取出的ASCII格式的数据内容（直接读的话是不可读的格式哦~）。

rrdtool dump 804.rrd > tmp

  这里分析rrdtool之前，先根据对dump出的文本文件tmp的内容分析，给出我当时绘制的示意图，如有疏漏欢迎留言或者联系我。

  简单解释一下上面这张示意图（图里画的是AVERAGE的值）：

• 距当前约3天的数据是最详细的记录，每5分钟一个值。对应在监控平台上，可以过滤出最近前3天的数据记录，任取一个时间段，都是每5分钟一个折线段。

• 距当前约15天的数据取值步长变大，每30分钟一个值。对应在监控平台上，可以过滤出前4天至前15天之间的数据记录，任取一个时间段，都是每30分钟一个折线段。

• 距当前约2月的数据取值步长继续变大，每2小时一个值。对应在监控平台上，可以过滤出前15天至前60天之间的数据记录，任取一个时间段，都是每2小时一个折线段。

• 距当前约2年的数据取值步长继续变大，每1天一个值。对应在监控平台上，可以过滤出前2个月至前2年之间的数据记录，任取一个时间段，都是每1天一个折线段。

  数据文件的后半部分数据结构同上，内容为MAX的值。

  这里需要注意一下，我们在分析rrd数据文件的时候，需要严格注意rrd文件的时间戳。如8月24号16：30的数据本来同时会存在于多个数据块中，但每个数据块中该时刻的值并不完全相同，在生成图形时，会取最“新”的值，即接近数据库开头处。当时管理监控平台服务器的同事给我的数据文件时是8月26号，恰好8月24号16：30本来最新的记录能够落入第一个数据块，但我本人分析这个数据文件时已经是8月27号，此时公司监控平台服务器中的数据库认为8月24号已经不属于最近3天内，则前3天的数据块已经不含有这个时间点的数据，故生成图形时应取前15天时间段处的数据进行计算。所以，我们在分析rrd数据的过程中，尽量保证使用当前数据库中的rrd数据文件，否则对于同一时刻，数据很容易不准。

  另外，如果按照上面分析的结论，又会有新的疑问。在我们的步长规定下，8月1号16：30（已经超出前15天的范围落入了前60天的第三档范围，每2小时一个值）这种“看似”已经不存在的数据记录，服务器是怎么提取的？在线查询8月1号16：30的流量，观察结果，发现使用的数据记录并不存在于dump的结果中！但是，本地使用804.rrd文件运行绘制图形的命令后，可以得到和服务器相同的结果！说明，我们结论里dump后的数据只是和真实的数据记录折线图有关系，假如查询了一个不在记录时刻上的值，监控平台取值时会使用的rrd数据文件本身进行分析推算，最终计算得出一个记录上不存在的值。

  了解了数据记录方式后，我们回过头来继续分析rrdtool的数据提取（用于生成图形的参数如第2行imgformat=PNG等这里暂不予讨论，我们只分析与数据的值相关的选项参数）。

  从第1行可以发现，监控平台使用的是rrdtool工具的graph子命令的相关选项生成的图形化查询结果。第3行start与第4行end的值均为1472027400，即rrd数据文件中对应8月24日16：30时的数据条目。理论上此时数据库中只有最近15天数据块内含有此记录，此处分别对三个不同的情况进行说明：

  第一种情况当前值（下图是dump后该时间段的原始数据）

  （接下来我们将要分析的DEF、CDEF均为rrdgraph_data中的子选项，用于处理rrd文件中的原始数据）第20行与第21行的DEF选项，分别指定了两列数据源a（traffic_in）与b（traffic_out），变量a与b将进一步参与接下来的运算。（如上图v标签包含的两列数据，第一列值2.1902537860e+05为traffic in，第二列值3.3778424241e+06为traffic out）第22行CDEF选项，指定所使用的RPN（逆波兰式，即借助数据结构“栈”的PUSH与POP思想存放普通的数学算式，从而省去存储小括号的不便，计算时将“=”右边的元素直接从左往右拿出来计算即可）指令。（CDEF:vname=RPN expression）这里生成的变量cdefa=a,8,*表示将上一步获得的a乘以8（将Byte转换成bit，cdefa=219025.3786×8=1752203.0288）。第23行CEDF选项，则是将b乘以8的结果存入变量cdefe中（cdefe=3377842.4241×8=27022737.928）。接下来的两组GPRINT选项（GPRINT已经不再是建议的选项，新的rrdtool建议使用PRINT选项），分别打印了我们在图形中看到的流入与流出方向的流量值。%8.2lf %s为格式控制，lf表示双精度，即可得到最终结果。

  其他两种情况（平均值和最大值）取值分析同上不再赘述，如有需要，可以查看我附件里的详细步骤（附件密码baiyeliuzhuan）。我是附件(^_−)

  至此，我们分析完了Cacti中的rrd数据存储和生成的基本过程。下一篇中，将根据这个过程讨论怎样自定义提取数据。