本发明涉及分布式集群的IT运维管理的技术领域，尤其涉及了一种分布式集群的客户端监视节点的方法。
背景技术：
目前传统集群各模块应用状态监控，是需要当前集群的所有节点都使用同一个模块拓扑配置，此方式分三种，第一种是每个节点都在自身本地存储一套静态应用模块拓扑配置信息；另一种是使用动态存储配置服务，读取服务获取应用节点拓扑信息；第三种是遍历集群所有节点来确定某应用的状态。
而对于相对独立的分布式集群监控系统，以上提及的前两种方式在不同情况下，带来实际集群监视的不确定性。比如静态配置的不适应某些应用的动态部署，或者动态存储配置服务处于异常等情况导致的集群监视的不确定性。第三种，在集群拥有大量节点时，服务主动扫描无用节点，势必是一种时间的浪费。
技术实现要素：
本发明所要解决的技术问题是：目前传统集群各模块应用状态监控对于相对独立的分布式集群监控系统并不适用，采用传统集群各模块会带来集群监视的不确定性，同时在集群拥有大量节点时，服务端会主动扫描无用节点，造成浪费。
为解决上面的技术问题，本发明提供了一种分布式集群的客户端监视节点的方法，该方法包括如下步骤：
S1，在分布式集群的所有节点处均部署具有监视模块的客户端；
S2，开启客户端内部的监视模块的守护进程，客户端读取所有的监视模块配置，客户端根据这些配置加载所有监视模块的功能；
S3，通过客户端内的监视模块对当前节点存在的监视点进行数据扫描收集；
S4，客户端将扫描收集的数据自动推送到服务端。
进一步地，所述步骤S2中还包括：客户端扫描当前节点信息，并将扫描的信息稽核，在一定时间段内推送给服务端。
进一步地，所述S3中包括：根据扫描收集的数据信息，客户端进行监视触发级别的调整，或更新当前监视配置信息。
上述进一步的有益效果：客户端本身均具有已知监视点的监视功能，再启动后，自动扫描所有的监视点，并根据当前节点信息，自适应调整各监视点的采集频率，减少了集群各节点的针对性功能模块的部署及监视调整
进一步地，监视触发级别按照降频依次包括：第一监视触发级别、第二监视触发级别、第三监视触发级别、第四监视触发级别。
上述进一步的有益效果：一个介于高频级别与低频级别的中间态，当一个处于高频级别的应用监视点所监视的信息在一定高频扫描次数均捕获不到时，则将此监视点级别置为中频级别，若在中频级别扫描期间，监视点捕获恢复后，则恢复高频级别，若在中频级别扫描期间，一直没有监视信息，则置为低频级别。
进一步地，所述S1中部署客户端的节点具有如下信息：IP、用户、口令、安装目录、端口。
进一步地，S1中还包括：所有节点处均部署与客户端对应的部分服务端，所述的部署服务端的节点具有如下信息：IP、用户、口令、安装目录、端口。
进一步地，该方法还包括：S5中，查看监视信息，查看监视信息方式包括：登陆到服务端，使用网络监视工具监视当前服务端节点的端口，从而查看监视信息。
进一步地，查看监视信息方式还包括：S5,若是集成可视化界面，打开监视页面，查看监视信息。
进一步地，所述客户端配置有监视模块名称和与监视模块有关的配置信息两部分。
进一步地，所述S4中客户端通过UDP协议将扫描收集的数据推送到服务端。
本法发明的有益效果：客户端采集所在节点主机的监视数据，客户端将监视的数据通过UDP协议推送到服务端，从而服务端不用主动扫描集群各节点的信息，所以降低服务端对集群节点的遍历无用扫描，节省了时间成本。
附图说明
图1为本发明的一种分布式集群的客户端监视节点的方法流程图。
具体实施方式
以下结合附图对本发明的原理和特征进行描述，所举实例只用于解释本发明，并非用于限定本发明的范围。
如附图1所示，一种分布式集群的客户端监视节点的方法，该方法包括如下步骤：
S1，在分布式集群的所有节点处都部署具有监视模块的客户端；在客户端上配置有监视模块名称和与监视模块有关的配置信息两部分；其中，部署客户端的节点信息包括：IP、用户、口令、安装目录、端口；与客户端对应的部分部署服务端，其服务端的节点信息包括：IP、用户、口令、安装目录、端口；
S2，客户端开启内部的监视模块的守护进程，客户端读取所有的监视模块配置，客户端根据这些配置加载所有监视模块的功能；其中，客户端扫描当前节点主机数据，并将扫描的数据稽核，在一定时间段内(比如在一分钟内的前20秒内的数据信息)推送给服务端；一个例子场景：
假如：一个集群有A、B、C三种服务，这个集群有三台主机；
第一台主机，有A服务；
第二台主机，有B服务；
第三台主机，有A、B、C服务；
对于B服务，其中有用节点是第二、三台，第一台就属于无用节点。若采用服务端远程扫描所有节点，则就扫了第一台，这样既造成了服务端扫描浪费的原因。
而各节点安置有客户端，则客户端采集监视信息，并将信息稽核推送给服务端，则服务端仅做的是搜索某个时间段(比如在第一分钟内10秒的时间段)的B服务监视信息，而监视信息含带节点信息，所以，服务端就知道某时间段内，B服务在第二、三台主机的运行情况。
S3，客户端内的监视模块会对当前节点存在的监视点进行数据扫描收集；根据扫描收集的数据信息，客户端进行监视触发级别的调整，或更新当前监视配置信息；监视触发级别按照降频依次包括：第一监视触发级别、第二监视触发级别、第三监视触发级别、第四监视触发级别。其中，第一监视触发级别(高频级别)包含必要的常态监视点、已捕获的应用监视点；第二监视触发级别(中频级别)：一个介于高频级别与低频级别的中间态。当一个处于高频级别的应用监视点所监视的信息在一定高频扫描次数均捕获不到时，则将此监视点级别置为中频级别，若在中频级别扫描期间，监视点捕获恢复后，则恢复高频级别，若在中频级别扫描期间，一直没有监视信息，则置为低频级别；第三监视触发级别(低频级别)：未捕获的应用监视点；第四监视触发级别(沉睡级别)：不进行主动扫描的应用监视点；监视点具有自我修复功能，当初次启动、重启、或监视功能配置异常等情况，会生成基础监视模块列表
S4，客户端将扫描收集的数据通过UDP协议自动推送到服务端。
在执行完上述4个步骤后，会进行查看监视信息，其中查看监视信息方式包括：1，登陆到服务端，使用网络监视工具监视当前服务端节点的端口查看监视信息；2，查看监视信息方式还包括：若是集成可视化界面，打开监视页面，配置定制化监视信息，查看监视信息。
守护进程是程序运行的一种方式，永远都在后台运行。
不刻意的手动停止或关闭的话，它都会一直运行。
只要主机在运行着，则这个程序就一直在运行。
守护进程(Daemon)是一种运行在后台的一种特殊的进程，它独立于控制终端并且周期性的执行某种任务或等待处理某些发生的事件。由于在linux中，每个系统与用户进行交流的界面成为终端，每一个从此终端开始运行的进程都会依附于这个终端，这个终端被称为这些进程的控制终端，当控制终端被关闭的时候，相应的进程都会自动关闭。但是守护进程却能突破这种限制，它脱离于终端并且在后台运行，并且它脱离终端的目的是为了避免进程在运行的过程中的信息在任何终端中显示并且进程也不会被任何终端所产生的终端信息所打断。
集群的各节点(主机)信息收集
两种方式，1.从监视服务端远程扫描所有节点的各监视信息，2.各节点采集收集信息，发送给监视服务端。
本发明采用第二种，就避免了服务端去扫描各节点，也就没有了“主动扫描无用节点”。
对于“不确定性”：
因为分布式集群的缘故，有一类服务比较特殊，仅在一个集群中运行一个，且是抢占式的运行。
这里假设C服务属于这种比较特殊的服务，那么，一开始C服务在第三台运行，运行一段时间后，第三台异常或者其他情况，第三台的C服务停止运行了，那么这个服务在集群会尝试重启C服务，这个时候，有可能第二台抢占运行了C服务，这个C服务在哪台运行的情况，就是我说的不确定性。
部署在所有节点的客户端，拥有监视ABC等的监视插件，所以第二台也能发现C服务，并能收集其监视信息。
对于查看方式的原因：一，因为数据都是从客户端主动发送到服务端的，采用这种方式，避免或者减少服务端主动去访问客户端节点；二，收集的数据，客户端中有一个配置，即本地数据存储的配置打开的话，则会在当前节点主机进行数据存储，不打开此配置的话，客户端的当前节点应用主机不存储所收集的数据，而所有的数据都会在采集后，暂存内存，然后通过客户端开启的守护进程，定时发送到服务端，将数据存储的决定权交付给服务端(服务端可以将数据存储到分布式数据库里或者其他的存储器，若是落服务端上，则是服务端的就具备选择的自由权利)。
在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。