近期做了一个项目，今天就mysql以及rrdtool在运维开发中的应用简单总结下，一是为了今后更好地学习和应用，
同时也让大家评判下，让个人以后少走弯路，共同提高。
关系数据库，数据操作依靠的是数据之间的关系，关系是其核心，当然，如果在应用中不用关系也是可以的，
提起这类数据库，大家都能列举一二，本人对oracle以及sqlserver的应用和学习只停留在本机安装和学习阶段，
不甚了解，db2很厉害，用过2年，一般企业也不用它，接触mysql当然是最多的了，提到mysql，大家对它都很熟悉了，近几年非常火的一款开放源码关系型数据库，各大技术论坛都有开辟它的专栏，具备了流行商业数据库大多功能，十分小巧却又不失威力，其他的好多优点google一下，很多。
对于rrdtool，其官方解释为一种开放源码的行业标准的高性能的日志以及图形系统，可以和多数语言集成。
看其官方定义，就能知道其主要用途在于日记以及图形，rrdtool特殊在它将数据保存的环上，可以想象数据沿着环一个一个保存，过一圈后，老的数据会被新的数据覆盖，保存在环上的数据量是固定的，因此rrdtool也经常被称为环状数据库。
在使用感觉上，从几个维度出发，对他们做个简单对比，对比惹争论，呵呵
这些对比维度都是个人突然想到的，合理与否不清楚，大家也可以提提建议。
在我们的运维系统中，这2种数据库都有用到，根据现有的业务，mysql用的是1主1从，同步用二进制日志方式。
rrdtool多用在对系统负载，应用性能以及网络流量监控上。下面从一个小项目（简称项目A）上来分享下rrdtool的应用。
在使用cacti的过程中，感到诸多不便，最大问题在于不适合我们现有的系统，不能根据需要定制。网络组提出需求，要求对现有网络设备的流量做监控定制，操作上要求尽量简单，预留定制最大化，相当于给他们做好积木，至于怎么搭，他们根据需求定制。
在开发过程中最具挑战的地方在于，假设了机房的分布性，根据监控量的大小，需要设计N台采集器角色的机器，负责根据提交的任务从各个机房完成数据采集，要能完成采集器健康检查，故障后的转移，任务的转移，如何实现采集器与汇集器的数据交换，数据交换格式等。在实际开发过程中，采取了维护尽量最小化，服务最少化的思想，所有交互都是主动。例如，在实现对采集器健康检查的过程中，最低假设是必须有一台采集器是活的，因此每台采集器至少1分钟报告一次状态，汇集器在每次有数据提交的时候，会对所有采集器的状态做检查，如果发现有采集器5分钟没报告状态，任务它已经异常，然后标志它已经“死亡”，根据它所处的组，转移器任务到同组兄弟采集器。本想在汇集器跑一cron任务来实现这个功能，发现维护起来不方便，采用这种方式在一定程度上影响了程序的效率，可也换取了维护上的简单性。
在交互过程中，没有纯c/s角色的结构，用的都是接口，接口，还是接口，数据传输的格式本想用xml，后来因为传输的数据类型比较单一，用snmp协议获取的性能以及流量数据，就用纯文本，采集器用python,汇集器用php，这2中语言操作纯文本，还是比较方便的。
在汇集器端接收数据后，rrdtool开始登场，围绕它的就是数据入/出/简单数据聚合/绘图，说起来简单，用起来也
比较方便快捷，在实际中，我们将要监控的设备元数据信息”动态“保存在mysql中，保存的元数据粒度很小，方便多个数据
操作，如果多个数据入单个文件也可以，总觉得用的时候太复杂，单个文件根据其名称就可以知道其中的
变量名称以及监控的元素，在一定程度上简单体现约定优于配置的思想，粒度小也导致了生成的文件个数随着需求的增长而增加，如果这种方式在以后遇到麻烦，也会考虑修改。
说了那么多，感觉是个标题党来，用到mysql的地方说的很少，实际上除了rrd，我们用的就是mysql了，跑题了没？表述能力差，还请谅解。
稍后会附上项目A的结构图。
附图，见笑了。
再附上几张在线系统图片
===end===
阅读(1286) | 评论(0) | 转发(0) |
