本发明涉及计算机高性能领域，具体来说，涉及一种基于web的集中式大规模集群监控预警系统。
背景技术：
在编写应用程序的时候，通常会记录日志以便事后分析，在很多情况下是产生了问题之后，再去查看日志，是一种事后的静态分析。在很多时候，我们可能需要了解整个系统在当前，或者某一时刻运行的情况，比如当前系统中对外提供了多少次服务，这些服务的响应时间是多少，随时间变化的情况是什么样的，系统出错的频率是多少。这些动态的准实时信息对于监控整个系统的运行健康状况来说很重要。
一些应用程序，比如对外提供接口或者服务的webservice，对整个系统的实时运行情况进行监控显得尤为重要，就像操作系统里面的资源管理器一样，如果能够实时或者准实时的看到整个系统耗费的cpu，内存等资源，对于我们快速对系统做出响应，以及优化很重要。并且，这些实时的性能参数信息，对于一些高级应用场景，比如服务的熔断机制（需要实时统计系统出错比例和响应时间），只有做到了实时监控才能提供这些数据，才能实现这种提高系统稳健性的功能。
现有技术方案是：通过客户端命令的形式进行相关操作。但存在许多缺陷：1.这种技术对实际开发人员的要求很高。2.任务排查比较复杂。3.不能及时发现系统、硬件问题等。4.发现问题周期长。
以下为本发明中可能涉及的专业术语:
gauges：最简单的度量指标，只有一个简单的返回值，例如，我们想衡量的一个待处理队列中任务个数。
counters：计数器。
meters：meter度量一系列事件发生的速率。meters会统计最近1分钟，5分钟，15分钟，还有全部时间的速率。
histograms：histogram统计数据的分布情况。比如最小值，最大值，中间值，还有中位数，75百分位,90百分位,95百分位,98百分位,99百分位,和99.9百分位的值。
timers：timer是histogram和meter的结合，histogram某部分代码/调用的耗时，meter统计tps。
针对相关技术中的问题，目前尚未提出有效的解决方案。
技术实现要素：
针对相关技术中的上述技术问题，本发明提出一种基于web的集中式大规模集群监控预警系统，能够实时监控集群的硬件资源。
为实现上述技术目的，本发明的技术方案是这样实现的：
一种基于web的集中式大规模集群监控预警系统，包括：master模块和slave模块；
所述master模块包括数据收集器，用于接收来自所述slave模块收集的信息；
所述slave模块包括数据采集器和hadoop数据采集器，所述数据采集器用于收集机器本身相关指标，所述hadoop数据采集器用于收集hadoop相关服务模块的性能数据。
进一步的，所述数据收集器在接收数据后，由所述数据采集器中的时间轴服务通过phoenix保存到列式数据库中。
进一步的，所述列式数据库以本地文件系统作为存储层。
进一步的，所述列式数据库以分布式文件系统作为存储层。
进一步的，所述机器本身相关指标包括但不限于：cpu、内存和硬盘。
进一步的，所述hadoop相关服务模块的性能指标包括但不限于：模块的占用内存和模块的cpu占用率。
本发明的有益效果：1、监控集群的硬件资源；2、减少排查的复杂度；3、实时展现系统运行参数；4、极大缩短发现问题的周期。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是根据本发明实施例所述的一种基于web的集中式大规模集群监控预警系统的结构示意图；
图2是根据本发明实施例所述的服务器端的结构示意图；
图3是根据本发明实施例所述的hadoop分布式文件系统的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本发明保护的范围。
如图1所示，根据本发明实施例所述的一种基于web的集中式大规模集群监控预警系统，包括：master模块和slave模块；
所述master模块包括数据收集器，用于接收来自所述slave模块收集的信息；
所述slave模块包括数据采集器和hadoop数据采集器，所述数据采集器用于收集机器本身相关指标，所述hadoop数据采集器用于收集hadoop相关服务模块的性能数据。
进一步的，所述数据收集器在接收数据后，由所述数据采集器中的时间轴服务通过phoenix保存到列式数据库中。
进一步的，所述列式数据库以本地文件系统作为存储层。
进一步的，所述列式数据库以分布式文件系统作为存储层。
进一步的，所述机器本身相关指标包括但不限于：cpu、内存和硬盘。
进一步的，所述hadoop相关服务模块的性能指标包括但不限于：模块的占用内存和模块的cpu占用率。
为了方便理解本发明的上述技术方案，以下通过具体使用方式上对本发明的上述技术方案进行详细说明。
在具体使用时，根据本发明所述的一种基于web的集中式大规模集群监控预警系统，主要为系统管理员提供了集群性能的监察功能。监控预警系统一般分为集群、主机以及服务三个层级，其中，集群和主机级主要负责监察集群机器相关的性能，而服务级别则负责主机上服务组件的性能。
如图1至3所示，对于监控预警系统本身来说，涉及的主要模块有数据采集器、hadoop数据采集器以及数据收集器。监控预警系统也是一个master-slave结构的框架，master模块便是数据收集器，slave则是数据采集器和hadoop数据采集器。salve模块负责收集信息，并发送给数据收集器。当然数据采集器和hadoop数据采集器也有不同的职责，前者主要负责收集机器本身相关的指标，例如cpu、内存、硬盘等；后者则负责收集hadoop相关服务模块的性能数据，例如该模块占用了多少内存，以及该模块的cpu占用率等。
监控预警系统会不断的收集集群相关的性能数据，并最终由数据采集器中的时间轴服务保存到列式数据库中（通过phoenix）。随着时间的推移，采集的数据会变得非常庞大，因此数据采集器支持两种存储模式，embeddedmode（嵌入模式）和distributedmode（分布式模式）。简单来说，对于在嵌入模式中，hbase会以本地文件系统作为存储层，而在分布式模式中，hbase则以hdfs作为存储层。这样就可以充分利用整个集群的物理存储了。需要注意的是，如果监控预警系统要以分布式模式运行，那么监控预警系统所在的机器必须部署一个hdfs的datanode模块。
此外，监控预警系统还支持配置化widget的功能，widget也就是web界面中呈现图的控件，它会根据数值，做出聚合运算，最终呈现在图控件中。数据平台的widget主要分为四类：graph、gauge、number以及template，其中前三者较为常用。graph是一种线性或矩形图，它用于显示在某时间内service的某个（可以是多个）metrics属性值。gauge一般用于显示百分比，其数值来源于一个（可以是多个）metrics经过计算后的值（小于1）。number则用于直接的显示一个数值，并可以为其配置一个单位，例如mb等，其所显示的数值也是来源于一个或多个metrics属性。widget进一步提升了数据采集器的易用性，以及可配置化。
数据平台为widget组件提供了4种聚合方式，分别是max、min、avg、sum。简单来说：max就是主机中服务组件收集的同个度量指标属性的最大值；min是最小值；avg是平均值；sum则是求和。widget组件会以avg为默认的聚合方式，同时用户可以在widget的配置文件中重新指定方式。
监控预警系统非常复杂，与其集成的核心便在数据收集器。如果遇到相关的问题，首先我们可以查看数据收集器和数据平台的日志；在配置完metrics.json以及widget.json之后，成功部署数据平台之前，如果出现问题则大多只需要查看数据平台的log即可，大多问题都是两个json的格式问题引起的。成功部署之后，则大多只需查看数据收集器的日志。这里最好打开数据收集器的debug级别log。这个需要在监控预警系统的config页面找到ams-log4j段，并更改其中的log4j.rootlogger为debug即可。
另外，我们可以通过数据收集器的restapi测试其是否正常，其api支持post和get两种请求。
综上所述，借助于本发明的上述技术方案，可达到以下有益效果：1、监控集群的硬件资源；2、减少排查的复杂度；3、实时展现系统运行参数；4、极大缩短发现问题的周期。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。