具体实施方式
下面,参考附图详细说明本发明的优选实施方式。在附图中,虽然示于不同的附图中,但相同的附图标记用于表示相同的或相似的组件。为了清楚和简明,包含在这里的已知的功能和结构的详细描述将被省略,以避免使本发明的主题不清楚。
图1示出了根据本发明的实施例的数据获取方法。在图1所示的方法中,主控模块确定与当前进程相关的目标网络设备列表(步骤S110);主控模块根据预设配置向一个或多个数据抓取模块定期通知目标网络设备列表中的目标网络设备(步骤S120);一个或多个数据抓取模块根据目标网络设备的地址向目标网络设备发送数据抓取请求(步骤S130);一个或多个数据抓取模块接收目标网络设备发回的数据抓取响应(步骤S140),其中,数据抓取响应包括所要获取的原始数据;以及一个或多个数据抓取模块向一个或多个数据处理模块发送所获取的原始数据(步骤S150),以由所述一个或多个数据处理模块进行处理(步骤S160)。
该方法还可包括一个或多个数据处理模块根据接收到的原始数据,计算本次抓取时间周期内的数据增量,并向数据库代理发送从一个或多个数据抓取模块获取的原始数据、一个或多个数据处理模块计算出的数据增量、以及抓取状态信息。
然后,数据库代理可将原始数据存储在热数据库中。数据压缩模块可从热数据库复制表结构,清除索引后建立到冷数据库中,且数据压缩模块还可从热数据库复制表数据,进行业务压缩后写入到冷数据库中。
在一些示例中,热数据库基于分表机制实现对原始数据执行分布式存储,其中,对于时序性强的数据,执行基于时间线分表的分布式存储。
在一些示例中,由于运维人员一般只关心最近一段时间内的网络状况,热数据库中存储的数据可仅以滚表的形式仅保留预定时间段。
在一些示例中,热数据库可分为主库和从库,主库可仅进行写入操作,且从库可进行查询操作,由此保证读写分离。
在一些示例中,该方法还可包括主控模块根据预设配置选择并初始化一个或多个数据抓取模块和一个或多个数据处理模块,并在主控模块与一个或多个数据抓取模块之间以及一个或多个数据抓取模块与一个或多个数据处理模块之间建立用于数据传输的数据传输管道。
在一些示例中,为保证一个抓取周期内所有的数据抓取模块都是满负荷抓取,一个或多个数据抓取模块可以以共享任务池的方式工作,每个数据抓取模块在完成其当前任务之后,可立即从共享任务池中获取下一任务。
图2示出了用于实现图1所示方法的数据获取设备。如图2所示,该数据获取设备包括主控模块210、一个或多个数据抓取模块220以及一个或多个数据处理模块230。主控模块210可用于确定与当前进程相关的目标网络设备列表,以及根据预设配置向一个或多个数据抓取模块220定期通知目标网络设备列表中的目标网络设备。一个或多个数据抓取模块220可用于根据目标网络设备的地址向目标网络设备发送数据抓取请求,并接收目标网络设备发回的数据抓取响应,数据抓取响应包括所要获取的原始数据。该一个或多个数据抓取模块220还可用于向一个或多个数据处理模块230发送所获取的原始数据。一个或多个数据处理模块230可用于对从一个或多个数据抓取模块接收到的数据进行处理。
在一些示例中,数据获取设备还包括数据库240。数据库240可包括数据库代理242、数据压缩模块244、热数据库246和冷数据库248。
一个或多个数据处理模块230还可用于根据接收到的原始数据,计算本次抓取时间周期内的数据增量,并向数据库代理242发送从一个或多个数据抓取模块220获取的原始数据、一个或多个数据处理模块230计算出的数据增量、以及抓取状态信息。
数据库代理242可用于将原始数据存储在热数据库246中。
数据压缩模块244可从热数据库246复制表结构,清除索引后建立到冷数据库248中,且数据压缩模块244还可从热数据库246复制表数据,进行业务压缩后写入到冷数据库248中。
在一些示例中,热数据库246还可用于基于分表机制实现对原始数据执行分布式存储,其中,对于时序性强的数据,执行基于时间线分表的分布式存储。
在一些示例中,热数据库246中存储的数据仅以滚表的形式仅保留预定时间段。
在一些示例中,热数据库246可分为主库和从库(未示出),主库可仅进行写入操作,且从库可进行查询操作。
在一些示例中,主控模块210还可用于根据预设配置选择并初始化该一个或多个数据抓取模块220和该一个或多个数据处理模块230,并在主控模块210与一个或多个数据抓取模块220以及一个或多个数据抓取230与一个或多个数据处理模块240之间建立用于数据传输的数据传输管道。
在一些示例中,一个或多个数据抓取模块220以共享任务池的方式工作,每个数据抓取模块220在完成其当前任务之后,立即从共享任务池中获取下一任务。
需要说明的是,图1和图2所示的方法步骤和结构框图仅是为了更清楚地说明本发明而做出的简化视图。在具体的实现中,还可存在更多或更少的步骤/模块。例如在图1的方法步骤中,还可添加读取配置文件的步骤,在图2所示的框图中还可添加输入/输出设备、显示设备、存储设备等。这些变型和修改同样在本发明的范围之内。
为了更清楚地说明图1和图2所示的方法和设备,下面将结合图3所示的数据获取系统的系统逻辑构成示意图来对本发明的技术方案进行进一步阐述。
需要说明的是,在图3所示的逻辑结构中,主控模块(Master),数据抓取模块、数据处理模块、数据压缩模块可由Go语言(美国Google公司开发的一种轻量级高并发语言)提供的goroutine机制实现。然而根据本发明的技术启示,本领域技术人员也可以使用本领域公知的其他开发语言来实现本发明的实施例,本发明不受具体开发语言实现的具体机制所限制。
在图3所示的逻辑结构中,采用MySQL数据库的形式实现本发明的数据存储。同样地,也可采用本领域公知或常用的其他数据库形式来实现本发明的数据存储,只要其也能实现本发明所述的数据存储方式。本发明不受具体的数据库形式的限制。
同样地,在下面的描述中,使用SNMP协议作为示例来执行本说明书中对各个网络设备的每个端口的状态数据的抓取。然而需要注意的是,本发明的技术方案也可以使用本领域周知或常用的其他网络管理协议。本发明不受具体协议形式的限制。
在图3所示的图中以及以下的描述中,数据抓取模块、数据处理模块、数据压缩模块有时也被分别称为数据抓取Worker(工作者线程或协程)、数据处理Worker以及冷数据压缩Worker等,这两组术语在本说明书中可互换使用。此外,也可以使用本领域技术人员可以想到或经常使用的表示相同含义的术语来进行替换。
在图3所示的结构中,主控模块Master可具有以下功能:
·读取本地配置文件,确定当前进程的抓取任务列表。
·启动指定数量的数据抓取Worker和数据处理Worker,并加以初始化。
·根据配置周期,向任务管道中定期注入任务目标设备。
数据抓取Worker可具有以下功能:
·不断获取最新的任务目标,并向目标设备发送SNMP抓取请求。
·将抓取到的原始SNMP流量数据写入抓取结果管道。
·记录各任务目标设备的抓取状态。
数据处理Worker可具有以下功能:
·获取目标设备的流量数据,并加以修正和处理。这里的修正和处理可包括单位转换、带宽百分比计算、异常值剔除等,也可以包括本领域技术人员可采用的其他任何数据处理。
·将处理后数据写入热数据MySQL服务器。
数据库代理层可具有以下功能:
·根据数据入库的时间戳,实现数据的自动滚表处理。
·根据数据所属时间表,实现数据的分布式存储。
冷数据压缩Worker可具有以下功能:
·从MySQL热数据库复制表结构,并清除索引后建立到MySQL冷数据库中。
·从MySQL热数据库复制表数据,并进行业务压缩后写入MySQL冷数据库中。此处的业务压缩可指按时间间隔压缩和位图压缩,也可包括本领域技术人员可采用的其他任何形式的数据压缩。
以上以示例的方式阐述了图3中各功能/处理模块的功能,然而需要理解的是,以上所述功能仅是为了使本领域技术人员理解本发明而阐述的功能的示例,上述功能/处理模块也可包括其他与本发明有关或无关的功能。
根据图3所示的系统,本发明技术方案的具体实现步骤如下:
主控模块中的goroutine启动,读取本地配置文件,根据配置初始化指定数量的数据抓取Worker和数据处理Worker,并在各Worker间建立数据传输管道。该本地配置文件可包括但不限于数据抓取Worker和数据处理Worker的数量。数据传输管道可由Go语言的channel机制实现。
主控模块从数据库拉取与当前进程相关的目标网络设备列表,并可根据配置定期将任务目标设备注入任务管道,从而驱动数据抓取Worker的工作。在一些示例中,术语“定期”可指示10分钟,然而在其他一些示例中,该时间间隔可以更大或更小。此外,该时间间隔也可根据需要动态调整。
数据抓取Worker根据任务目标设备的IP来发送SNMP抓取请求包,需要抓取的维度包括每个端口的出入字节流量、出入包数量、错误包数量、被忽略的包数量等。同时抓取Worker要记录本次抓取任务的起始时间、返回状态等信息。当任务目标设备返回SNMP数据响应后,当前抓取Worker将SNMP数据简单封装为结构体形式,并放入抓取结果管道。
由于数据抓取Worker主要通过网络访问任务目标设备,并且不同的设备访问延时也不同,因此可能会导致各Worker的抓取效率也不一样,特别是当某一目标网络设备不可达时,将会严重拖累其关联Worker的抓取速度。为了避免这种延时导致的Worker负载不均,数据抓取Worker被设计为以共享任务池的方式工作。图4示出了采用和不采用共享任务池的两种不同任务分配方式。当使用共享任务池时,在一个Worker抓取完当前任务后,可立刻去获取下一抓取任务,从而保证一个抓取周期内所有的Worker都是满负荷抓取,提高了任务分配效率。
数据处理Worker从抓取结果管道获取原始的SNMP结果数据。由于网络设备返回的端口数据都是自设备启动以来的累计数据,可通过数据处理Worker计算出本次抓取时间周期内的数据增量。
数据处理Worker调用数据库代理层将抓取状态信息、SNMP原始数据以及处理后的周期增量写入MySQL热数据库。由于大型机房的网络设备数量众多,并且每台设备都具有若干数量的端口,因此每个周期抓取的数据都会非常庞大,这种情况下必须要基于分表机制实现数据的分布式存储。在一些实施例中,对于时序性比较强的监控数据,采取基于时间线分表的处理方式。
另外,为了避免写入MySQL成为瓶颈,可对数据库操作进行足够的优化,实际主要优化项目可包括:
·采用合适的MySQL存储引擎,例如在MySQL5.6下,InnoDB可以是插入和查询效率最好的数据引擎。
·避免更新操作,保持都是写入操作,从而避免事务性处理。
·采用多goroutine并发方式提升写入速度。
·采用单goroutine批量插入提交的方式提升写入效率。
·MySQL主库只做写入操作,查询全部通过从库操作,保证读写分离。
对于网络监控数据,运维人员一般只关心最近一段时间内的网络状况,对于时间长远的数据一般只留作备份即可。基于此,本发明的一些实施例可采用冷热分级的形式对数据进行存储,数据处理Worker将数据写入热数据库后,通过数据压缩Worker同步将数据压缩后存入冷数据库,而热数据库则以滚表的形式只保留一段时间内的数据。以下示出冷热数据库设计的一个示例:
热数据库:
·数据不做任何形式的压缩。
·只保留最近一段时间内的时效数据(例如,一周、15天或其他适合的时间段)。
·为每张表建立适当的索引,以保证查询速度。
·向服务器配置大内存或SSD磁盘,保证写入和查询速度。
冷数据库:
·只保留原始SNMP数据作为待查副本。
·所有表都不建立索引,以节省磁盘存储空间。
·采用MySQL Archive存储引擎压缩数据占用空间。
·关闭MySQL服务器的通用日志和二进制日志选项,减少磁盘空间占用。
·服务器只需要保证磁盘容量,对CPU和内存没有过高要求。
需要说明的是,以上示出的仅是热数据库和冷数据库设计的一个示例。在根据本发明的其他一些实施例中,对热数据库和冷数据库的设计可以包括比以上所述更多或更少的内容。基于本发明设计思想的热数据库和冷数据库设计不限于以上形式。
图5示出了根据本发明实施例的数据抓取流程的一个具体示例的流程图。
如图5所示,主控模块210首先读取配置文件,并根据配置文件启动预定数据的数据抓取模块220和数据处理模块230,并为主控模块210与数据抓取模块220以及数据抓取模块220与数据处理模块230之间的数据传输设置任务管道,然后为任务管道周期性地发放数据抓取任务。
各个数据抓取模块220以阻塞方式从任务管道获取抓取任务,并向目标设备发送SNMP抓取请求。如果在超过预定时间阈值之后仍未接收到目标设备返回的结果数据,则认为抓取超时,记录出错状态。如果在预定时间阈值之前接收到目标设备返回的SNMP结果数据,则可将该结果数据简单封装为结构体形式,并放在与数据处理模块230之间的抓取结果管道中。
这里所述的阻塞方式可基于Go的Channel管道或其他语言中的阻塞队列实现,各数据抓取模块可都从管道中获取抓取任务。如果管道中存在任务数据,则可立即向相应数据抓取模块返回任务数据,否则数据抓取模块就会被阻塞在任务获取方法上,直到主控模块(Master)再次向管道中注入任务数据。
数据处理模块230同样以阻塞方式从抓取结果管道获取抓取结果,并查找是否存在针对相同网络设备的上一次的抓取结果。如果没有找到,缓存本次抓取结果,结束本次抓取。如果找到上一次针对该网络设备的抓取结果,则可计算本次结果与上一次的结果之间的增量,并将处理后的数据(计算出的增量)提交给数据库代理(层)242。
数据库代理模块(层)242可缓存待持久化的数据。当所缓存的数据满足某个条件,例如数据到达1000条或预定时间超时1秒或其他本领域周知或常用的条件时(即,确实需要持久化时),确定当前时间表是否存在,如果不存在,则根据脚本创建当前时间表,并将缓存的数据如上结合图1至图3所述地写入数据库230中。如果存在当前时间表,直接将缓存的数据如上结合图1至图3所述地写入数据库230中。
图6示出了根据本发明实施例的数据压缩的一个具体示例。如上所述,该数据压缩由数据压缩模块244执行。首先,数据压缩模块244读取配置文件,根据配置文件启动表同步Worker,并将热数据库与冷数据库进行对比。如果发现热数据库中存在新的热表,则抽取并将该新的热表的表结构复制到冷数据库中,删除旧的冷表索引,并创建新的冷表索引。此外,数据压缩模块244还启动数据同步Worker,寻找上次执行复制时的复制时间戳。如果找到,基于该复制时间戳监控热数据,如果没有找到上次的复制时间戳,则重置复制时间戳,使其指向当前时间,并基于重置后的复制时间戳监控热数据。之后,若发现有新的热数据插入热数据库,则从复制时间戳开始获取热数据,并对热数据进行业务压缩,批量并发地将压缩后的热数据插入到冷数据库中。最后,数据压缩模块244可更新复制时间戳,根据更新后的复制时间戳继续监控热数据。
需要注意的是,图5和图6仅是根据本发明实施例的具体示例,根据具体所使用的开发语言和协议的不同,上述具体示例也会发生一些改变,然而不管具体细节上发生哪些改变,这种数据抓取和数据冷热分级的技术方案都在本发明的范围之内。
本发明的上述技术方案通过轻量级并发方式大大提升服务器的抓取效率。以单台x86服务器(32核CPU、64G内存、1000M网卡)为例,每分钟可以抓取和处理超过20万端口的数据,由此可利用数量较少的服务器资源,实现最大化数量网络设备的监控数据抓取和存储。
此外,需要注意的是,本发明实施例所记载的技术方案在不冲突的情况下可以任意组合。
在本发明所提供的几个实施例中,应该理解到,所揭露的方法和设备,可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的,例如,所述单元/模块的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,如:多个单元或组件可以结合,或可以集成到另一个系统,或一些特征可以忽略,或不执行。另外,所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口,设备或单元的间接耦合或通信连接,可以是电性的、机械的或其它形式的。
上述作为分离部件说明的单元可以是、或也可以不是物理上分开的,作为单元显示的部件可以是、或也可以不是物理单元,即可以位于一个地方,也可以分布到多个网络单元上;可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。
另外,在本发明各实施例中的各功能单元可以全部集成在一个第二处理单元中,也可以是各单元分别单独作为一个单元,也可以两个或两个以上单元集成在一个单元中;上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。
上面的描述仅用于实现本发明的实施方式,本领域的技术人员应该理解,在不脱离本发明的范围的任何修改或局部替换,均应该属于本发明的权利要求来限定的范围,因此,本发明的保护范围应该以权利要求书的保护范围为准。