一种基于分布式采集及存储的监控系统的制作方法
【专利摘要】本申请公开了一种基于分布式采集及存储的监控系统，包括：采集装置和存储装置，所述采集装置，用于通过包含的采集端对Mongodb数据源、Redis数据源、Mysql数据源和Nstatus数据源的数据库进行分布式采集，将采集后的数据发送给存储装置；所述存储装置，用于对采集的数据采取分时间段合并取平均的方式，对采集的所述数据存入的队列，后端脚本会从所述队列里弹出数据，并合并所述脚本，按照至少5分钟对应的数据取平均值后存储到分布式数据库中，并输出二维图表展示。本发明设计出一套灵活、易用，扩展性高的监控系统来实时监控并能提取预知整个系统的运营状况及走势。
【专利说明】 —种基于分布式采集及存储的监控系统
【技术领域】
[0001]本申请涉及分布式的数据采集端领域，更具体地，涉及一种基于分布式采集及存储的监控系统。
【背景技术】
[0002]现有技术中，Cacti是一套基于PHP、My SQL、SNMP及RRDtool开发的监测图形分析工具。
[0003]Cacti是通过SNMPget来获取数据，使用RRDtool绘画图形。它的数据和用户管理功能，可以指定每一个用户能查看树状结构、host以及任何一张图，还可以与LDAP结合进行用户验证，同时也能自己增加模板。
[0004]Cacti的主要功能是用SNMP服务获取数据，然后用RRDtool储存和更新数据，当用户需要查看数据的时候用RRDtool生成图表呈现给用户。因此，SNMP和RRDtool是Cacti的关键。SNMP关系着数据的收集，RRDtool关系着数据存储和图表的生成。
[0005]Mysql配合PHP程序存储一些变量数据并对变量数据进行调用，如:主机名、主机IP> SNMP团体名、端口号、模板信息等变量。
[0006]抓到数据不是存储在数据库中，而是存在RRDtool生成的rrd文件中。RRDtool对数据的更新和存储就是对rrd文件的处理，rrd文件是大小固定的档案文件(Round RobinArchive)，它能够存储的数据笔数在创建时就已经定义。
[0007]目前的采集方式只依赖于单台服务器，存在性能瓶颈。当搭建Cacti监控几十台甚至上百台服务器时，Cacti的采集脚本可以正常工作，不存在延时或者性能问题，但当监控的服务器达到几百上千台时，Cacti的缺点就会暴露出来，采集量过大，采集脚本并不能在设定的时间内完成大量的采集，并且会对采集服务器造成过大的负载，导致监控系统的图表绘图及展示也会变慢。
[0008]Cacti的数据存储是以rrd文件的形式存在于服务器硬盘，采集的内容大小取决于硬盘大小，并且存在数据安全风险，当一段时间内数据抓取失败，由于文件时顺序写入，无法在文件中补全丢失的数据。
[0009]同时，Cacti所有服务器都部署到一台服务器，不能有效进行横向扩展，二次开发成本过高，监控配置过于繁琐。
[0010]还有，Cacti图表与字段不可扩展，用户根据自己的业务二次开发难度较大。
[0011]目前的监控系统，大部分都是偏向与监控服务器硬件，CPU内存，系统负载等指标，但对于业务监控很少有成熟的方案。很多人认为当服务器正常，自己的服务也是正常的。但在实际的运营维护中，对于正常运行的服务会遇到以下问题。
[0012]1、本服务的上、下游服务究竟有哪些？分别有多少量？
2、服务各接口的请求量分别有多少？成功率如何？
3、服务对外提供的接口处理速度有多快？高峰时的慢请求情况怎么样？
4、服务高峰期接口很慢，是否能查看一下是A接口或者B接口导致的 5、随着网站流量的提升，最近我们服务的请求上升了多少？能不能有趋势图指引我们是否该加新机器了？
6、服务上线后，缓存容量一直在增加，是因为超时没加，还是程序逻辑漏洞导致。
[0013]可见以上出现这些问题，单纯依靠监控服务的物理硬件指标是很难发现这些问题，实际过程中，基本上都是要登陆服务器，被动的通过系统命令及工具查看相应的问题，有些问题还需要线上调试，给开发及运维人员都带来比较大的痛苦。因此迫切需要一套灵活、易用，扩展性高的监控系统来实时监控并能提取预知整个系统的运营状况及走势。因此，如何解决上述不足，成为亟待解决的技术问题。
【发明内容】
[0014]有鉴于此，本申请提供一种基于分布式采集及存储的监控系统，以解决如何设计出一套灵活、易用，扩展性高的监控系统来实时监控并能提取预知整个系统的运营状况及走势问题。
[0015]本申请公开了一种基于分布式采集及存储的监控系统，其特征在于，包括:采集装置和存储装置，其中，
所述采集装置，与所述存储装置相耦接，用于通过包含的采集端对Mongodb数据源、Redis数据源、Mysql数据源和Nstatus数据源的数据库进行分布式采集，将采集后的数据发送给存储装置；
所述存储装置，与所述采集装置相耦接，用于对采集的数据采取分时间段合并取平均的方式，对采集的所述数据存入的队列，后端脚本会从所述队列里弹出数据，并合并所述脚本，按照至少5分钟对应的数据取平均值后存储到分布式数据库中，并输出二维图表展示。
[0016]优选地，其中，所述分布式采集，进一步为:通过RediS的list表，其中每个子元素都是string类型的双向链表,通过push、pop操作从所述链表的头部或者尾部添加删除元素，并通过分布于各个服务器端中的采集端对Mongodb数据源、Redis数据源、Mysql数据源和Nstatus数据源的数据库进行分布式采集形成采集后的数据队列。
[0017]优选地，其中，按照至少5分钟对应的数据取平均值后存储到分布式数据库中，进一步为:按照5分钟、10分钟或30分钟对应的数据取平均值后存储到分布式数据库中。
[0018]优选地，其中，所述采集装置，进一步还用于通过包含的采集端对Mongodb数据源、Redis数据源、Mysql数据源和Nstatus数据源的数据库，以及对CPU、内存、网络流量、硬盘数据进行分布式采集，将采集后的数据发送给存储装置。
[0019]与现有技术相比，本申请所述的基于分布式采集及存储的监控系统，达到了如下效果:
I)本发明解决了现有的系统不管是基于snmp协议的远程采集，还是基于脚步的远程抓取，都是基于单节点的问题，存在与性能瓶颈，当单节点出现性能瓶颈时，现有技术是通过提升节点的硬件性能，来满足监控系统的容量，但这不是最终的解决方法，当单节点的硬件性能到达顶端，不能再升级，而监控的业务还在海量增加，这样的监控系统就会崩溃，本发明基于分布式系统的好处就是，不存在单节点的问题，系统中的服务器可以平滑横向扩展，扩展过程中不用停止服务。
[0020]2)本发明还实现了对于传统的监控系统，可以查看一年(具体时间可以根据实际情况随机设置)的监控数据，每个数据以分钟为单位，现有技术需要一个海量的存储单元，一次全部取出并绘图，需要花费很多资源，而在实际应用中，本发明对于监控者如果想要查看一年的数据，基本只需要查看这段时间内的平均值，看一下数据趋势即可，本系统由于采取了分时间段合并取平均的方式，时间区间可以灵活设定，数据通过设定的区间存储，避免直接存储在文件里，发生丢失和数据篡改的风险。
[0021]3)本发明同时还可以对过期数据定期清理，数据字段及图表可扩展性更高。
[0022]当然，实施本申请的任一产品必不一定需要同时达到以上所述的所有技术效果。
[0023]
【专利附图】
【附图说明】
[0024]此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中:
图1为依据本发明实施例一所述的基于分布式采集及存储的监控系统结构图；
图2为依据本发明实施例一所述监控系统中采集装置101具体操作步骤流程图；
图3为依据本发明实施例一所述监控系统中存储装置102具体操作步骤流程图。
[0025]
【具体实施方式】
[0026]如在说明书及权利要求当中使用了某些词汇来指称特定组件。本领域技术人员应可理解，硬件制造商可能会用不同名词来称呼同一个组件。本说明书及权利要求并不以名称的差异来作为区分组件的方式，而是以组件在功能上的差异来作为区分的准则。如在通篇说明书及权利要求当中所提及的“包含”为一开放式用语，故应解释成“包含但不限定于”。“大致”是指在可接收的误差范围内，本领域技术人员能够在一定误差范围内解决所述技术问题，基本达到所述技术效果。此外，“耦接”一词在此包含任何直接及间接的电性耦接手段。因此，若文中描述一第一装置耦接于一第二装置，则代表所述第一装置可直接电性耦接于所述第二装置，或通过其他装置或耦接手段间接地电性耦接至所述第二装置。说明书后续描述为实施本申请的较佳实施方式，然所述描述乃以说明本申请的一般原则为目的，并非用以限定本申请的范围。本申请的保护范围当视所附权利要求所界定者为准。
[0027]如图1所示，为依据本发明实施例一所述的基于分布式采集及存储的监控系统，该系统包括:采集装置101和存储装置102，其中，
所述采集装置101，与所述存储装置102相耦接，用于通过包含的采集端对Mongodb数据源、Redis数据源、Mysql数据源和Nstatus数据源的数据库进行分布式采集，将采集后的数据发送给存储装置102 ;具体内容，如图2所示。
[0028]另外，还可以采集CPU、内存、网络流量、硬盘数据等的数据内容。
[0029]所述存储装置102，与所述采集装置101相耦接，用于对采集的数据采取分时间段合并取平均的方式，对采集的所述数据存入的队列，后端脚本会从所述队列里弹出数据，并合并所述脚本，按照至少5分钟对应的数据取平均值后存储到分布式数据库中，并输出二维图表展示。具体内容，如图3所示。
[0030]其中，如图3所示，所述至少5分钟还可以设置成10分钟、30分钟，这里对于本领域技术人员来说，可以根据实际情况进行相应的调整，并不做具体限定。
[0031]其中，如图2所示，所述分布式采集，进一步为:通过Redis (Redis为一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的 API (应用程序接口，Applicat1n Programming Interface))的 list 表，其中每个子元素都是string类型的双向链表,可以通过push, pop操作从链表的头部或者尾部添加删除元素；所述采集装置101中的各个采集端分布于各个服务器端(逻辑上完全独立，无启动先后顺序)，对Mongodb数据源、Redis数据源、Mysql数据源和Nstatus数据源的数据库进行分布式采集，将采集后的数据发送给存储装置102，每次从Redis弹出一个监控源数据，完成采集数据队列操作。
[0032]后续再根据采集数据队列通过import相应的接口，由接口完成数据汇总，并通过所述存储装置102存储到分布式数据库中；具体可以为对采集的数据采取分时间段合并取平均的方式，对采集的所述数据存入的队列，后端脚本会从所述队列里弹出数据，并合并所述脚本，按照至少5分钟对应的数据取平均值后存储到分布式数据库中，并输出二维图表展示。此过程中任何一个采集端进程意外退出或者所在服务器宕机都不会影响整个监控系统的采集，所以安全性较高。
[0033]与现有技术相比，本申请所述的基于分布式采集及存储的监控系统，达到了如下效果:
I)本发明解决了现有的系统不管是基于snmp协议的远程采集，还是基于脚步的远程抓取，都是基于单节点的问题，存在与性能瓶颈，当单节点出现性能瓶颈时，现有技术是通过提升节点的硬件性能，来满足监控系统的容量，但这不是最终的解决方法，当单节点的硬件性能到达顶端，不能再升级，而监控的业务还在海量增加，这样的监控系统就会崩溃，本发明基于分布式系统的好处就是，不存在单节点的问题，系统中的服务器可以平滑横向扩展，扩展过程中不用停止服务。
[0034]2)本发明还实现了对于传统的监控系统，可以查看一年(具体时间可以根据实际情况随机设置)的监控数据，每个数据以分钟为单位，现有技术需要一个海量的存储单元，一次全部取出并绘图，需要花费很多资源，而在实际应用中，本发明对于监控者如果想要查看一年的数据，基本只需要查看这段时间内的平均值，看一下数据趋势即可，本系统由于采取了分时间段合并取平均的方式，时间区间可以灵活设定，数据通过设定的区间存储，避免直接存储在文件里，发生丢失和数据篡改的风险。
[0035]3)本发明同时还可以对过期数据定期清理，数据字段及图表可扩展性更高。
[0036]还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者系统中还存在另外的相同要素。
[0037]本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
[0038]以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。
【权利要求】
1.一种基于分布式采集及存储的监控系统，其特征在于，包括:采集装置和存储装置，其中，所述采集装置，与所述存储装置相耦接，用于通过包含的采集端对Mongodb数据源、Redis数据源、Mysql数据源和Nstatus数据源的数据库进行分布式采集，将采集后的数据发送给存储装置； 所述存储装置，与所述采集装置相耦接，用于对采集的数据采取分时间段合并取平均的方式，对采集的所述数据存入的队列，后端脚本会从所述队列里弹出数据，并合并所述脚本，按照至少5分钟对应的数据取平均值后存储到分布式数据库中，并输出二维图表展示。
2.如权利要求1所述的基于分布式采集及存储的监控系统，其特征在于，所述分布式采集，进一步为:通过Redis的list表,其中每个子元素都是string类型的双向链表,通过push.pop操作从所述链表的头部或者尾部添加删除元素，并通过分布于各个服务器端中的采集端对Mongodb数据源、Redis数据源、Mysql数据源和Nstatus数据源的数据库进行分布式采集形成采集后的数据队列。
3.如权利要求1所述的基于分布式采集及存储的监控系统，其特征在于，按照至少5分钟对应的数据取平均值后存储到分布式数据库中，进一步为:按照5分钟、10分钟或30分钟对应的数据取平均值后存储到分布式数据库中。
4.如权利要求1所述的基于分布式采集及存储的监控系统，其特征在于，所述采集装置，进一步还用于通过包含的采集端对Mongodb数据源、Redis数据源、Mysql数据源和Nstatus数据源的数据库，以及对CPU、内存、网络流量、硬盘数据进行分布式采集，将采集后的数据发送给存储装置。
【文档编号】G06F17/30GK104331505SQ201410667386
【公开日】2015年2月4日 申请日期:2014年11月20日 优先权日:2014年11月20日
【发明者】黄林, 彭锦臻, 张宇峰, 姚键, 潘柏宇, 卢述奇 申请人:合一网络技术(北京)有限公司