基于Zookeeper的监控方法、监控装置、设备及存储介质

摘要

本申请涉及云监控技术领域，具体公开了一种基于Zookeeper的监控方法、装置、设备及存储介质，所述方法包括：通过监听程序监听Zookeeper以获取Zookeeper的状态变更事件；对状态变更事件进行处理，得到对应的服务信息，服务信息包括服务端的服务名和客户端的实例信息；获取监听程序的配置文件的配置信息，配置信息至少包括已被监控的客户端的实例信息；根据服务信息中的实例信息和配置信息中的实例信息，确定是否需要对配置文件中的配置信息进行更新；若确定需要进行更新，根据服务信息更新配置信息，以使Prometheus根据更新后的配置信息从服务端拉取metrics信息以便完成监控，进而实现了自动发现自动接入监控，降低了人工维护成本，提高了用户体验。

说明书

技术领域

本申请涉及云监控技术领域，尤其涉及一种基于Zookeeper的监控方法、监控装置、设备及存储介质。

背景技术

目前，基于Zookeeper的监控方案分为两种，一种是客户端主动上报metric信息到服务端实现监控，但是由于客户端和服务端之间可能存在网络延迟，因此会导致客户端发送队列增长过快而发生内存溢出(Out Of Memory，OOM)，或者由于失败重试导致服务端获取到重复数据；另一种是服务端通过静态配置Zookeeper的实例信息和拉取接口，主动拉取metric信息，但是该方案无法自动接入监控系统，在微服务扩容时也无法达到自动发现的目标，人工维护成本高。

发明内容

本申请提供了一种基于Zookeeper的监控方法、监控装置、设备及存储介质，旨在解决目前Zookeeper的监控方案无法自动发现目标，人工维护成本高的问题。

为实现上述目的，本申请提供一种基于Zookeeper的监控方法，其特征在于，应用于包括Zookeeper、Prometheus和监听程序的微服务监控系统，所述Prometheus与所述监听程序通过网络文件系统实现共享配置文件；所述方法包括：

通过所述监听程序监听所述Zookeeper以获取所述Zookeeper的状态变更事件；

对所述状态变更事件进行处理，得到对应的服务信息，所述服务信息包括服务端的服务名和客户端的实例信息；

获取所述监听程序的配置文件的配置信息，所述配置信息至少包括已被监控的客户端的实例信息；

根据所述服务信息中的实例信息和所述配置信息中的实例信息，确定是否需要对所述配置文件中的配置信息进行更新；

若确定需要进行更新，根据所述服务信息更新所述配置信息，以使所述Prometheus根据更新后的配置信息从所述服务端拉取Metrics信息以便完成监控。

为实现上述目的，本申请还提供一种基于Zookeeper的监控装置，所述监控装置包括：

事件监听模块，用于通过所述监听程序监听所述Zookeeper以获取所述Zookeeper的状态变更事件；

信息处理模块，用于对所述状态变更事件进行处理，得到对应的服务信息，所述服务信息包括服务端的服务名和客户端的实例信息；

信息获取模块，用于获取所述监听程序的配置文件的配置信息，所述配置信息至少包括已被监控的客户端的实例信息；

更新确定模块，用于根据所述服务信息中的实例信息和所述配置信息中的实例信息，确定是否需要对所述配置文件中的配置信息进行更新；

更新监控模块，用于若确定需要进行更新，根据所述服务信息更新所述配置信息，以使所述Prometheus根据更新后的配置信息从所述服务端拉取Metrics信息以便完成监控。

此外，为实现上述目的，本申请还提供一种计算机设备，其特征在于，所述计算机设备包括存储器和处理器；所述存储器，用于存储计算机程序；所述处理器，用于执行所述的计算机程序并在执行所述的计算机程序时实现本申请实施例提供的任一项所述的监控方法。

此外，为实现上述目的，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时使所述处理器实现本申请实施例提供的任一项所述的监控方法。

本申请实施例公开的基于Zookeeper的监控方法、监控装置、计算机设备和存储介质，通过在微服务监控系统中预先设置的监听程序，用于监听Zookeeper的状态变更事件，以及通过网络文件系统(Network File System，NFS)实现监听程序和Prometheus的配置文件共享，由此通过监听Zookeeper的状态变更事件以及更新监听程序的配置文件，实现了可以主动发现需要监控的服务端和客户端，并实现自动接入进行监控，降低了人工维护成本，提高了用户体验。

附图说明

为了更清楚地说明本申请实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种现有的基于zookeeper的微服务监控系统的示意性框图；

图2是本申请实施例提供的一种基于zookeeper的微服务监控系统的示意性框图；

图3是本申请实施例提供的一种基于zookeeper的监控方法的流程示意图；

图4是本申请实施例提供的一种确定是否更新配置信息的子步骤流程示意图；

图5是本申请实施例提供的另一种确定是否更新配置信息的子步骤流程示意图；

图6是本申请实施例提供的一种更新配置信息的子步骤流程示意图；

图7是本申请实施例提供的一种展示Metrics信息的效果示意图；

图8是本申请实施例提供的一种展示Metrics信息的另一效果示意图；

图9是本申请实施例提供的一种基于zookeeper的监控装置的示意性框图；

图10是本申请一实施例提供的一种计算机设备的示意性框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

附图中所示的流程图仅是示例说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解、组合或部分合并，因此实际执行的顺序有可能根据实际情况改变。另外，虽然在装置示意图中进行了功能模块的划分，但是在某些情况下，可以以不同于装置示意图中的模块划分。

在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

目前，基于Zookeeper的微服务监控方案大多分为以下两种，一种是客户端主动上报metric信息到服务端实现监控，这种方案由于客户端和服务端之间存在可能的网络延迟，导致客户端发送队列增长过快而发生内存耗尽(Out Of Memory，OOM)现象，或者由于失败重试导致服务端会获取到重复数据。另一种是服务端通过静态配置Zookeeper微服务中的实例信息和拉取接口，主动拉取服务端的metric信息，这种方案可以避免重复数据，但是无法自动发现需要监控的目标，也无法自动接入监控，并且人工维护成本高。

为此，本申请提供了基于Zookeeper的监控方法、监控装置、计算机设备及存储介质，以解决上述问题。在详细介绍本申请提供的基于Zookeeper的监控方法之前，对本申请涉及的技术名称进行解释。

名词解释：

1、metric信息：提供一些监控指标的度量信息，主要包括微服务的jvm、cpu、负载、响应时间、网络IO大小等等；

2、Zookeeper：一种分布式应用程序协调服务，是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等等，尤其是Curator框架提供了完整的注册中心客户端实现，且维护成本较低，适合中小集群使用；

3、推模型：客户端主动推送数据给服务端；

4、拉模型：服务端主动拉取客户端的数据；

5、Prometheus：一种开源的监控服务，采用Go语言开发实现，内置了时序数据存储机制；

6、NFS：网络文件系统(Network File System)，是文件系统之上的一个网络抽象，允许远程客户端以与本地文件系统类似的方式通过网络进行访问。允许在多个用户之间共享公共文件系统，并提供数据集中的优势，来最小化所需的存储空间。

下面结合附图，对本申请的一些实施方式作详细说明。在不冲突的情况下，下述的实施例及实施例中的特征可以相互组合。

请参阅图1，图1是本申请实施例提供的一种现有的基于zookeeper的微服务监控系统的示意性框图。如图1所示，Zookeeper负责管理多个服务端(Service)和客户端(Client)，其中一个服务端可以对应多个不同的Client，在基于Zookeeper实现对客户端进行监控时，可以采用拉模型或推模型从服务端上获取metric信息，进而实现监控，但是由于推模型可能存在重复数据的问题，而拉模型无法自动发现需要监控的目标，也无法自动接入监控，并且人工维护成本高。

为此，首先对现有的Zookeeper的微服务监控系统进行改进，并基于该改进的微服务监控系统介绍本申请实施例提供的监控方法。请参阅图2，图2是本申请实施例提供的一种基于zookeeper的微服务监控系统的示意性框图。如图2所示，该改进后的微服务监控系统包括Zookeeper、Prometheus和预先开发的监听程序，其中，所述Prometheus与所述监听程序通过网络文件系统(Network File System，NFS)实现共享配置文件。

监听程序用于监听Zookeeper的状态变更事件，其中，该状态变更事件包括有新的客户端注册微服务对应的事件，和/或，客户端的注册元数据发生变化对应的事件，和/或，客户端或服务端的上下线对应的事件。

所述客户端注册微服务时需要向所述Zookeeper发送注册元数据，所述注册元数据包括实例信息、拉取接口信息、监控标志信息和鉴权信息，所述实例信息包括IP信息和端口信息。当然注册元数据还可以包括其他信息，在此不做限定。

其中，IP信息是指网络间互联的协议，端口信息是客户端与服务端进行通信的连接端口，拉取接口信息为客户端用于拉取数据的接口，监控标志信息为“是否接入监控标志”用于表示注册的客户端是否需要监控服务，鉴权信息用于确定该客户端是否被授权。

Prometheus用于根据所述监听程序的配置文件中的配置信息，从服务端拉取metric信息，以实现监控。

该监控系统还包括Alerts Manager(告警组件)、监控组件和存储组件(Grafana)，其中，告警组件用于的拉取的Metrics信息进行分析处理以确定是否存在告警信息，监控组件用于从告警组件中获取告警信息以提示用户，存储组件用于存储拉取的Metrics信息以便后续分析使用。

需要说明的是，上述基于Zookeeper的微服务监控系统可以部署在服务器中，实现对多个客户端与对应的服务端监控，其中，服务端可以部署在包括该微服务监控系统的服务器，或者不同于该微服务监控系统的服务器，客户端可以部署在终端设备中。

其中，终端设备可以包括诸如手机、平板电脑、笔记本电脑、掌上电脑、个人数字助理(Personal Digital Assistant，PDA)、以及诸如数字TV、台式计算机等固定终端。服务器例如可以为单独的服务器或服务器集群。

请参阅图3，图3是本申请实施例提供的一种基于Zookeeper的监控方法的示意流程图。该基于Zookeeper的监控方法可以应用于服务器中，实现自动发现目标自动接入监控，降低了人工维护成本，提高了用户体验度。

如图3所示，该基于Zookeeper的监控方法包括步骤S101至步骤S105。

S101、通过所述监听程序监听所述Zookeeper以获取所述Zookeeper的状态变更事件。

监听程序为预先开发的程序模块，部署在基于Zookeeper的微服务监控系统中，用于监听Zookeeper的状态变化事件。该监听程序具体可以是一个单独开发的程序模块，当然也可以是基于Zookeeper中的监控组件进行重新定义的组件。其中，对Zookeeper中的监控组件进行重新定义，可以节约开发资源进而节约了人力成本。

示例性的，可以选择Zookeeper的监控组件，对所述监控组件进行重新定义以用于获取Zookeeper的状态变更事件，并将所述监控组件通过NFS实现与Prometheus共享配置文件。

其中，所述状态变更事件包括：有新的客户端注册微服务对应的事件，和/或，客户端的注册元数据发生变化对应的事件，和/或，客户端或服务端的上下线对应的事件；状态变更事件中记录有服务信息，该服务信息包括服务端的服务名以及客户端的注册元数据等。

其中，所述客户端注册微服务时向所述Zookeeper发送注册元数据，所述注册元数据包括实例信息、拉取接口信息、监控标志信息和鉴权信息，所述实例信息包括IP信息和端口信息。当然，状态变更事件还可以包括其他状态变化事件，注册元数据也还可以包括其他信息，在此不做限定。

在客户端注册微服务时，需要将注册元数据提供给服务端，同时Zookeeper也会监控到客户端注册微服务以及注册元数据。

具体地，监听程序获取Zookeeper的状态变更事件，可以是监听程序主动拉取Zookeeper的状态变更事件，也可以是服务端主动上报状态变更事件。

S102、对所述状态变更事件进行处理，得到对应的服务信息，所述服务信息包括服务端的服务名和客户端的实例信息。

在获取到Zookeeper的状态变更事件后，解析该状态变更事件得到相应的服务信息，其中，该服务信息包括服务端的服务名和客户端的注册元数据，所述注册元数据至少包括所述客户端的实例信息，实例信息可例如包括客户端的IP信息和/或端口信息等。

在一些实施方式中，Zookeeper可以通过Curator框架实现的，Curator框架可以从以下几个方面降低了Zookeeper使用的复杂性:重试机制、连接状态监控、Zookeeper客户端实例管理和支持各种使用场景。

其中，Curator提供可插拔的重试机制，将给捕获可恢复的异常配置一个重试策略，并且内部也提供了几种标准的重试策略(比如Exponential Back off Retry:重试指定的次数，且每一次重试之间停顿的时间逐渐增加，Retry N Times:指定最大重试次数的重试策略，Retry One Time:仅重试一次，Retry Until Elapsed:一直重试直到达到规定的时间)。Curator初始化之后会一直的对Zookeeper连接进行监听，一旦发现连接状态发生变化，将做出相应的处理。Curator对Zookeeper客户端到server集群连接进行管理，并在需要的情况，重建Zookeeper实例，保证与Zookeeper集群的可靠连接。Curator实现Zookeeper支持的大部分使用场景支持(甚至包括Zookeeper自身不支持的场景)，这些实现都遵循了Zookeeper的最佳实践，并考虑了各种极端情况。由此可以降低客户端和服务端的微服务的复杂性。

S103、获取所述监听程序的配置文件的配置信息，所述配置信息至少包括已被监控的客户端的实例信息。

其中，已被监控的客户端的实例信息包括IP信息和端口信息等，实例信息还可以记录在实例列表中进行保存，即将服务端的服务名和客户端注册时的实例信息对应记录在实例列表中，并将该实例列表保存在配置文件中。

由于监听程序的配置文件和Prometheus的配置文件是通过NFS(网络文件系统)实现共享的，因此Prometheus的配置文件中也保存有已被监控的客户端的实例信息，或保存有实例列表。

示例性地，通过使用NFS不仅可以实现监听程序和Prometheus的配置文件的共享，还能够节省本地存储的配置文件的空间，将常用的配置文件存放在一台NFS服务器上，可以通过网络访问，那么本地服务器或终端将可以减少自身存储空间的使用。

在一些实施方式中，还可以将实例列表等信息转换成yaml和json格式的信息进行存储，因为Prometheus的配置文件针对yaml和json格式进行编写读取和更新的，由此方便Prometheus读取和使用，进而实现快速监控。

S104、根据所述服务信息中的实例信息和所述配置信息中的实例信息，确定是否需要对所述配置文件中的配置信息进行更新。

具体可以根据服务信息的实例信息与监听程序的配置信息中的实例信息进行对比，以确定Prometheus是否已经对该客户端以及该客户端对应的服务端进行监控；在确定存在相应的客户端时，则确定不需要对所述配置文件中的配置信息进行更新；在确定没有存在相应的客户端时，则确定需要对所述配置文件中的配置信息进行更新。

示例性的，比如根据IP信息，确定监听程序的配置信息中的实例信息是否在相同的IP，若确定监听程序的配置信息中的实例信息存在相同的IP，可以确定Prometheus已经对该客户端以及该客户端对应的服务端进行监控；再根据“监控标志”确定监听程序配置文件中的实例列表是否已经存在对应的客户端，若确定存在对应的客户端，可以确定Prometheus已经对该客户端以及该客户端对应的服务端进行监控。

在一些实施例中，为了快速确定是否需要更新配置信息，如图4所示，即确定是否更新配置信息的步骤，具体包括以下步骤：

S201、确定所述配置信息中是否存在与所述服务信息中的实例信息相同的实例信息；

S202、确定需要对所述配置文件中的配置信息进行更新；

S203、确定不需要对所述配置文件中的配置信息进行更新。

可以通过IP信息和/或端口信息确定所述配置信息中是否存在与所述服务信息中的实例信息相同的实例信息，若所述配置信息中未存在与所述服务信息中的实例信息相同的实例信息，则确定需要对所述配置文件中的配置信息进行更新；若所述配置信息中存在与所述服务信息中的实例信息相同的实例信息，则确定不需要对所述配置文件中的配置信息进行更新。

需要说明的是，服务信息可能包括多个客户端对应一个服务端的情况，因此在确定所述配置信息中是否存在与所述服务信息中的实例信息相同的实例信息时，若所述配置信息中存在与所述服务信息中所有客户端的实例信息相同的实例信息，则确定不需要对所述配置文件中的配置信息进行更新，若所述配置信息中存在至少一个与所述服务信息中客户端的实例信息不相同的实例信息，确定需要对所述配置文件中的配置信息进行更新。

在一些实施例中，可以通过监听程序配置文件中的实例列表判断是否需要对配置信息进行更新，该配置文件的配置信息中包括实例列表，所述实例列表用于记录已被监控的客户端的实例信息。具体如图5所示，根据所述服务信息中的实例信息和所述配置信息中的实例信息，确定是否需要对所述配置文件中的配置信息进行更新，包括：即确定是否更新配置信息的步骤，具体包括以下步骤：

S301、确定所述配置信息中的实例列表是否存在所述服务信息中的实例信息；

S302、确定需要对所述配置文件中的配置信息进行更新；

S303、确定不需要对所述配置文件中的配置信息进行更新。

具体地，确定所述配置信息中的实例列表是否存在所述服务信息中的实例信息，若所述配置信息中的实例列表未存在所述服务信息中的实例信息，则确定需要对所述配置文件中的配置信息进行更新；若所述配置信息中的实例列表存在所述服务信息中的实例信息，则确定不需要对所述配置文件中的配置信息进行更新。

S105、若确定需要进行更新，根据所述服务信息更新所述配置信息，以使所述Prometheus根据更新后的配置信息从所述服务端拉取Metrics信息以便完成监控。

具体地，根据服务信息更新配置信息，具体可以根据所述客户端的注册元数据更新所述实例列表中的客户端，以及根据所述服务端的服务名更新所述客户端对应的服务端。当然，除了包括更新实例列表(targets)外、还可以更新拉取接口(metric_path)和鉴权信息(basic_auth)的更新。以便Prometheus从其配置文件读取更新后配置信息，并根据更新后的配置信息从所述服务端拉取Metrics信息以便完成监控。

具体地，Prometheus主要分为三部分，分别为拉取模块(Retrieval)、存储模块(Storage)和语言模块(PromQL)。其中，Retrieval是负责定时去暴露的目标页面上去抓取Metrics信息，Storage是负责将所述Metrics信息写入磁盘进行存储，PromQL是Prometheus提供的查询语言模块，方便实时地查找和聚合时间序列数据。

示例性地，如图2所示，Prometheus采用Pull的方式从服务端拉取Metrics信息。Prometheus在本地存储抓取的所有数据，并通过一定规则进行清理和整理数据，并把得到的结果存储到新的时间序列(TSDB)中，以便后续分析使用。

在一些实施例中，为了避免造成资源浪费，所述微服务监控系统还包括预设的事件容器，所述事件容器被设置为在间隔预设时间时通过调度线程执行所述事件容器中的事件。

相应地，如图6所示，即更新所述配置信息，具体包括以下步骤：

S401、将根据所述服务信息更新所述配置信息对应的事件，保存在所述事件容器中；以及

S402、在间隔所述预设时间时，调度线程执行所述事件容器中的事件，实现对所述配置信息的更新。

可以将根据所述服务信息更新所述配置信息对应的事件，比如多个更新所述配置信息对应的事件，保存在所述事件容器中，并且在事件容器达到规定的间隔预设时间后，比如间隔30s，开启该事件容器调度线程执行所述事件容器中的事件，同时执行多个更新所述配置信息对应的事件，实现对所述配置信息的更新。由此可以避免重复更新配置文件，进而避免造成资源浪费。

在一些实施方式中，如图2所示，还可以定义Prometheus的Http接口(HttpServer)，以便连接告警组件(Alerts Manager)、监控组件(监控中心)和存储组件(Grafana)。

其中，告警组件用于对拉取的Metrics信息进行分析处理以确定是否存在告警信息，监控组件用于从告警组件中获取告警信息以提示用户，存储组件用于存储拉取的Metrics信息以便后续分析使用。

示例性地，提示用户的方式，具体可以将告警信息发送至对应的应用程序(APP)或以Email、短信、聊天工具例如微信、qq等手段通知用户。

在一些实施方式中，Prometheus定期从配置好的服务端(Service)中拉取Metrics信息，或者从TSDB中获取Metrics信息。TSDB在本地存储收集到的Metrics信息，并运行已定义好的alert.rules(报警规则)，记录新的时间序列或者向Alert manager推送警报。Alertmanager根据配置文件，对接收到的警报进行处理，发出告警。

在一些实施方式中，还可以基于Prometheus查询语言(PromQL)按照列表展示Metrics信息或通过趋势图展示Metrics信息，以便用户查看。示例性的，如图7所示，趋势图可以在同一界面上展示数据或同时展示多类数据，比如同时展示请求数和平均响应时间。示例性的，如图8所示，也可以分为多个小界面展示不同的数据。

请参阅图9，图9是本申请一实施例提供的一种基于Zookeeper监控装置的示意框图，该基于Zookeeper的监控装置可以配置于服务器中，用于执行前述的监控方法。

如图9所示，该基于Zookeeper的监控装置500包括：事件监听模块501、信息处理模块502、信息获取模块503、更新确定模块504和更新监控模块505。

事件监听模块501，用于通过所述监听程序监听所述Zookeeper以获取所述Zookeeper的状态变更事件；

信息处理模块502，用于对所述状态变更事件进行处理，得到对应的服务信息，所述服务信息包括服务端的服务名和客户端的实例信息；

信息获取模块503，用于获取所述监听程序的配置文件的配置信息，所述配置信息至少包括已被监控的客户端的实例信息；

更新确定模块504，用于根据所述服务信息中的实例信息和所述配置信息中的实例信息，确定是否需要对所述配置文件中的配置信息进行更新；

更新监控模块505，用于若确定需要进行更新，根据所述服务信息更新所述配置信息，以使所述Prometheus根据更新后的配置信息从所述服务端拉取Metrics信息以便完成监控。

在一些实施例中，监控装置500还可以包括信息展示模块，该信息展示模块用于基于PromQL，按照列表方式展示所述Metrics信息或通过趋势图展示所述Metrics信息。

需要说明的是，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的装置和各模块、单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本申请的方法、装置可用于众多通用或专用的计算系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、机顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

示例性地，上述的方法、装置可以实现为一种计算机程序的形式，该计算机程序可以在如图10所示的计算机设备上运行。

请参阅图10，图10是本申请实施例提供的一种计算机设备的示意图。该计算机设备可以是服务器或终端。

如图10所示，该计算机设备包括通过系统总线连接的处理器、存储器和网络接口，其中，存储器可以包括非易失性存储介质和内存储器。

非易失性存储介质可存储操作系统和计算机程序。该计算机程序包括程序指令，该程序指令被执行时，可使得处理器执行任意一种基于Zookeeper的监控方法。

处理器用于提供计算和控制能力，支撑整个计算机设备的运行。

内存储器为非易失性存储介质中的计算机程序的运行提供环境，该计算机程序被处理器执行时，可使得处理器执行任意一种基于Zookeeper的监控方法。

该网络接口用于进行网络通信，如发送分配的任务等。本领域技术人员可以理解，该计算机设备的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

应当理解的是，处理器可以是中央处理单元(Central Processing Unit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。其中，通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

其中，在一些实施方式中，所述处理器用于运行存储在存储器中的计算机程序，以实现如下步骤：

通过所述监听程序监听所述Zookeeper以获取所述Zookeeper的状态变更事件；对所述状态变更事件进行处理，得到对应的服务信息，所述服务信息包括服务端的服务名和客户端的实例信息；获取所述监听程序的配置文件的配置信息，所述配置信息至少包括已被监控的客户端的实例信息；根据所述服务信息中的实例信息和所述配置信息中的实例信息，确定是否需要对所述配置文件中的配置信息进行更新；若确定需要进行更新，根据所述服务信息更新所述配置信息，以使所述Prometheus根据更新后的配置信息从所述服务端拉取Metrics信息以便完成监控。

在一些实施例中，所述状态变更事件包括：有新的客户端注册微服务对应的事件，和/或，客户端的注册元数据发生变化对应的事件，和/或，客户端或服务端的上下线对应的事件；其中，所述客户端注册微服务时向所述Zookeeper发送注册元数据，所述注册元数据包括实例信息、拉取接口信息、监控标志信息和鉴权信息，所述实例信息包括IP信息和端口信息。

在一些实施例中，所述处理器在实现所述根据所述服务信息中的实例信息和所述配置信息中的实例信息，确定是否需要对所述配置文件中的配置信息进行更新时，具体用于：

确定所述配置信息中是否存在与所述服务信息中的实例信息相同的实例信息；若所述配置信息中存在与所述服务信息中的实例信息相同的实例信息，则确定不需要对所述配置文件中的配置信息进行更新；若所述配置信息中未存在与所述服务信息中的实例信息相同的实例信息，则确定需要对所述配置文件中的配置信息进行更新。

在一些实施例中，所述配置信息包括实例列表，所述实例列表用于记录已被监控的客户端的实例信息。

在一些实施例中，所述处理器在实现所述根据所述服务信息中的实例信息和所述配置信息中的实例信息，确定是否需要对所述配置文件中的配置信息进行更新时，具体用于：

确定所述配置信息中的实例列表是否存在所述服务信息中的实例信息；若所述配置信息中的实例列表存在所述服务信息中的实例信息，则确定不需要对所述配置文件中的配置信息进行更新；若所述配置信息中的实例列表未存在所述服务信息中的实例信息，则确定需要对所述配置文件中的配置信息进行更新。

在一些实施例中，所述处理器在实现所述根据所述服务信息更新所述配置信息时，具体实现：

根据所述客户端的实例信息更新所述实例列表；根据所述客户端的注册元数据更新所述实例列表中的客户端，以及根据所述服务端的服务名更新所述客户端对应的服务端。

在一些实施例中，所述微服务监控系统还包括预设的事件容器，所述事件容器被设置为在间隔预设时间时通过调度线程执行所述事件容器中的事件。

在一些实施例中，所述处理器在实现所述根据所述服务信息更新所述配置信息时，具体实现：

将根据所述服务信息更新所述配置信息对应的事件，保存在所述事件容器中；以及在间隔所述预设时间时，调度线程执行所述事件容器中的事件，实现对所述配置信息的更新。

在一些实施例中，所述处理器还用于实现：

基于PromQL，按照列表方式展示所述Metrics信息或通过趋势图展示所述Metrics信息。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序中包括程序指令，所述程序指令被执行时实现本申请实施例提供的任一种基于Zookeeper的监控方法。

其中，所述计算机可读存储介质可以是前述实施例所述的计算机设备的内部存储单元，例如所述计算机设备的硬盘或内存。所述计算机可读存储介质也可以是所述计算机设备的外部存储设备，例如所述计算机设备上配备的插接式硬盘，智能存储卡(SmartMedia Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。

进一步地，所述计算机可读存储介质可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据区块链节点的使用所创建的数据等。

本发明所指区块链语言模型的存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层等。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。