本发明涉及一种数据的存储系统与运算方法，特别是涉及一种大规模IT监控数据的存储运算系统及方法。
背景技术：
监控类软件长时间运行，产生很多数据，大量的数据会拖慢监控软件的运行，最终产生众多故障。
传统监控软件的解决办法如下：十、限定设备个数和限定监控指标，十一、减小采集频率，十二、限定数据保存时间。传统监控软件，如果未采用集群或分布式，单套系统最多大约可以管理1000台设备。
当前数据趋向于集中化，在大规模IT(Information Technology，互联网技术)环境下，如云计算环境，这些限定因素下传统监控软件的已不能满足实际监控需求：十三、云计算下虚拟机的大量应用，设备个数成几何级数增长，十四、为了及时发现故障，将故障扼杀在初级阶段，采集频率不能低于1分钟1采集，十五、对IT运维部门来说，IT的平稳运行与有效规划是保障业务的基本，其监控数据越来越重要。
技术实现要素：
本发明所要解决的技术问题是提供一种大规模IT监控数据的存储运算系统及方法，其能够实时监控数据，存储和管理海量数据，运算简单和速度快，且能够管理5000-50000台设备。
本发明是通过下述技术方案来解决上述技术问题的：一种大规模IT监控数据的存储运算系统，其包括：
Zabbix模块，与TairDB模块相连，用于监视各种网络参数，保证服务器系统的安全运营，并提供灵活的通知机制以让系统管理员快速定位来解决存在的各种问题；
TairDB模块，将数据存放于磁盘中，为了解决磁盘损坏导致数据丢失问题，将其数据进行备份。
优选地，所述Zabbix模块包括：
Zabbix Agent模块，与Zabbix Proxy模块相连，用于发送采集后的数据；
Zabbix Proxy模块，与Zabbix Server模块相连，用于收集数据，并统一发送给Zabbix Server模块；
Zabbix Server模块，与Zabbix Agent模块相连，用于接收Zabbix Agent模块发送的报告信息的核心组件，统计数据及操作数据均由其进行确认，并对历史数据进行数据收敛；
Mysql模块，与Zabbix Server模块相连，用于读取监控数据的信息；
Zabbix Web模块，与Mysql模块相连，用于查看Zabbix页面，并从Mysql模块读取相关数据。
优选地，所述TairDB模块包括：
分布式KV库模块，与第一存储引擎模块相连，与第二存储引擎模块相连，用于读取和改写监控数据；
第一存储引擎模块和第二存储引擎模块都使用Google开源的、高性能的LevelDB作为底层的存储引擎，其用于系统故障时，能够保证数据不丢失。
本发明还提供一种大规模IT监控数据的存储运算方法，其包括以下步骤：
步骤一、Zabbix Server对监控数据进行分析与处理，对于结果数据，大部分发送给TairDB，小部分发送给Mysql；
步骤二、Zabbix Server若有需要，从TairDB读取history监控数据；从Mysql读取trends趋势数据，从哪里写入数据，就从哪里读取数据；
步骤三、用户使用Zabbix Web查看监控结果时，从Mysql读取监控策略和趋势数据，从TairDB读取监控数据。
优选地，所述步骤一中监控数据的类型包括：浮点数、日志、字符串、长字符串、正整数。
优选地，所述步骤一中发送给TairDB的结果数据包括history、history_log、history_str、history_text、history_uint几个历史表，这部分数据非常多，TairDB对存放的数据，全部按字符串处理，因此，需要正确标识原数据格式；发送给Mysql的结果数据包括trends、trends_uint两个趋势表，这部分数据比较少。
优选地，所述步骤二中从TairDB读取的数据，需要转换成原数据格式为：浮点数、日志、字符串、长字符串、正整数。
优选地，所述步骤二中Zabbix Server会缓存并后续使用从Zabbix Proxy发送过来的实时监控数据和从TairDB仅读取少量的未缓存的历史数据。
优选地，所述步骤三中Zabbix Web采用PHP页面，需要添加对TairDB数据的读取的驱动支持；Zabbix Web采用了sql语句命令读取监控数据，将TairDB库的数据，转换成所需的sql语句命令要求的结果。
优选地，所述步骤三中Zabbix Web大部分情况下都是批量读取监控数据，利用TairDB的批量读取命令。
本发明的积极进步效果在于：本发明能够保留了Zabbix模块的监控功能与效果，极大增加了可管理的设备规模，简易方式实现了数据服务的冗余，存储和管理海量数据，实时监控类数据，实现数据的读取与分析，用TairDB模块，解决大规模监控数据的存储与运算问题，且本发明能够管理5000-50000台设备。
附图说明
图1为本发明的结构示意图。
图2为本发明运算方法的流程图。
具体实施方式
下面结合附图给出本发明较佳实施例，以详细说明本发明的技术方案。
如图1所示，本发明大规模IT监控数据的存储运算系统包括Zabbix(网络监控)模块、TairDB(存储数据库)模块，其中：
Zabbix模块，与TairDB模块相连，用于监视各种网络参数，保证服务器系统的安全运营，并提供灵活的通知机制以让系统管理员快速定位来解决存在的各种问题；
TairDB模块，将数据存放于磁盘中，为了解决磁盘损坏导致数据丢失问题，将其数据进行备份。
所述Zabbix模块包括Zabbix Agent(代理)模块、Zabbix Proxy(代理服务器)模块、Zabbix Server(服务器)模块、Mysql(关系型数据库管理系统)模块、Zabbix Web(网站服务器)模块，其中：
Zabbix Agent模块，与Zabbix Proxy模块相连，用于发送采集后的数据；
Zabbix Proxy模块，与Zabbix Server模块相连，用于收集数据，并统一发送给Zabbix Server模块；
Zabbix Server模块，与Zabbix Agent模块相连，用于接收Zabbix Agent模块发送的报告信息的核心组件，统计数据及操作数据均由其进行确认，并对历史数据进行数据收敛；
Mysql模块，与Zabbix Server模块相连，用于读取监控数据的信息；
Zabbix Web模块，与Mysql模块相连，用于查看Zabbix页面，并从Mysql模块读取相关数据。
所述TairDB模块包括分布式KV(Key-Value，存储数据库)库模块、第一存储引擎模块、第二存储引擎模块，其中：
分布式KV库模块，与第一存储引擎模块相连，与第二存储引擎模块相连，用于读取和改写监控数据；
第一存储引擎模块和第二存储引擎模块都使用Google(谷歌公司)开源的、高性能的LevelDB(Google实现的非常高效的kv数据库)作为底层的存储引擎，其用于系统故障时，能够保证数据不丢失。
如图2所示，本发明大规模IT监控数据的存储运算方法包括以下步骤：
步骤一、Zabbix Server对监控数据进行分析与处理，对于结果数据，大部分发送给TairDB，小部分发送给Mysql；
步骤二、Zabbix Server若有需要，从TairDB读取history监控数据；从Mysql读取trends(用于广告设计方面的字体)趋势数据，从哪里写入数据，就从哪里读取数据；
步骤三、用户使用Zabbix Web查看监控结果时，从Mysql读取监控策略和趋势数据，从TairDB读取监控数据。
所述步骤一中监控数据的类型包括：浮点数、日志、字符串、长字符串、正整数。
所述步骤一中发送给TairDB的结果数据包括history(浮点数历史表)、history_log(日志历史表)、history_str(字符串历史表)、history_text(长字符串历史表)、history_uint(正整数历史表)几个历史表，这部分数据非常多，TairDB对存放的数据，全部按字符串处理，因此，需要正确标识原数据格式。
所述步骤一中发送给Mysql的结果数据包括trends(浮点数趋势表)、trends_uint(正整数趋势表)两个趋势表，这部分数据比较少。
所述步骤二中从TairDB读取的数据，需要转换成原数据格式为：浮点数、日志、字符串、长字符串、正整数。
所述步骤二中Zabbix Server会缓存并后续使用从Zabbix Proxy发送过来的实时监控数据和从TairDB仅读取少量的未缓存的历史数据。
所述步骤三中Zabbix Web采用PHP(超文本预处理器)页面，需要添加对TairDB数据的读取的驱动支持。
所述步骤三中Zabbix Web采用了sql(Structured Query Language，结构化查询语言)语句命令读取监控数据，将TairDB库的数据，转换成所需的sql语句命令要求的结果。
所述步骤三中Zabbix Web大部分情况下都是批量读取监控数据，利用TairDB的批量读取命令，提高读取效率。
本发明的工作原理如下：用户在Zabbix Web定义监控策略(监控对象与监控模式)，写入Mysql；Zabbix Server从Mysql读取监控策略(监控对象与监控模式)，下发到Zabbix Agent；大量的Zabbix Agent从监控对象读取监控数据，发送给Zabbix Proxy；Zabbix Proxy作为中转，判断数据合法性后，将监控数据发送给Zabbix Server。
监控数据具有以下特点：
一、格式单一；一个设备包含多个组件包括硬件、操作系统和多个应用软件，每个采集组件，包含有多个采集指标，为便于检索，可定义：采集项＝采集设备+采集组件+采集指标；采集项采集的结果，一般分浮点数，如CPU(Central Processing Unit，中央处理器)利用率，整数，如进程个数，字符串，如syslog(UNIX尤尼斯系统中提供的一种日志记录方法)；
二、数据量大；若5000台机器，每台机器100个指标，1分钟1采集，暂不计算采集指标所产生的额外数据，1天采集指标个数：5000*100*60*24＝720.000.000＝7.2亿；若一个采集指标存储40字节，1天数据存储量：720.000.000*40＝26Gbytes；30天采集指标个数：720.000.000*30＝21.600.000.000＝216亿；30天数据存储量：26Gbytes(字节)*30＝780Gbytes；
三、批量写和读；采集模块，如被管主机上的Agent，进行指标采集时，一般是一次批量采集多个指标，然后，Agent统一送到中心处理模块，如管理系统的Server，为减少数据库访问次数，提高数据存储效率，Server尽量优化成一次批量写入多个采集数据，展现/分析模块对监控数据的读取，需要单个数据读取或批量数据读取，单个数据读取，如对某个采集项，读取某个时间的数据，批量数据读取，如对某个采集项，读取某个时间区间的数据；
四、运算简单；与关系型数据库中的用户表、设备表等管理数据不同，监控数据运算比较简单，一般只需要单个数据读取，批量数据读取，批量数据按时间段收敛等；
五、数据收敛；原始明细的数据，因为量太大有时不方便直观呈现，进行数据收敛，如对1分钟数据，可将每60个数据，进行一次数据收敛，得到60分钟监控结果，数据收敛后可得到：采集项、开始时间，结束时间、最大值、最小值、平均值，其中时间为60分钟。
监控数据的存储与运算具有以下特点：
六、实时性；监控数据采集后，需立即进行模式比对，若满足某种条件，即产生告警事件，有的监控系统先入库，再读取出来分析，这样设计上较简洁；有的监控系统一边入库，一边分析，这样运算效率较高；
七、大容量；通过以上分析，即使是1天的采集数据，数量也是很大的，关系数据库管理这么大的量不是很现实，最好采用Nonsql(非关系型的数据库)数据库；
八、分布式；单个Nonsql数据库也满足不了海量监控数据的要求，需要采用可扩展的分布式数据库，最好把数据能均摊到多个存储节点，而且读写访问也能均摊，整个访问路径上不应该存在性能瓶颈；
九、可冗余；如此大量的数据，数据丢失将是重大的损失，支持冗余也是必要的，最好能支持异地冗余。
以上所述的具体实施例，对本发明的解决的技术问题、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。