CN113132431A - 服务监控方法、服务监控装置、电子设备及介质 - Google Patents

Abstract

本公开提供了一种服务监控方法、服务监控装置、电子设备及介质。该服务监控方法包括：接收待监控服务的服务标识；响应于服务标识，从注册信息集合中获取注册信息，并且从服务资源配置集合中获取服务配置信息，注册信息为提供待监控服务的多个对象进行注册后形成的，服务配置信息为针对待监控服务为多个对象设置的配置信息；以及基于注册信息和配置信息确定多个对象的服务能力关联信息。

Description

服务监控方法、服务监控装置、电子设备及介质

技术领域

本公开涉及互联网技术领域，更具体地，涉及一种服务监控方法、服务监控装置、电子设备及介质。

背景技术

在基于服务远程调用的应用系统中，关键服务的不可用会导致应用系统整体业务故障，对业务目标的达成和业务连续性造成灾难性的影响。

相关的监控方案基于对服务生产者所在主机的监控，通过探测程序定时探测主机是否联通、探测健康检查页面，并探测主机其他性能指标。例如CPU使用、内存占用、端口是否开启监听等。将探测到的指标数据逐级汇总，以便于实现服务监控。

在实现本公开构思的过程中，发明人发现相关技术中至少存在如下问题：需逐台监控服务生产者所在的主机，并且，监控指标之间的数据无法互用，如探测主机存活与健康页检查需要分别建立探测连接，导致需要建立数量巨大的探测连接。

发明内容

有鉴于此，本公开提供了一种用于减少探测连接数量，并且提升服务监控效果的服务监控方法、服务监控装置、电子设备及介质。

本公开的一个方面提供了一种由服务器端执行的服务监控方法，包括：首先，接收待监控服务的服务标识。然后，响应于服务标识，从注册信息集合中获取注册信息，并且从服务资源配置集合中获取服务配置信息，注册信息为提供待监控服务的多个对象进行注册后形成的，服务配置信息为针对待监控服务为多个对象设置的配置信息，这样就可以实现基于注册信息和配置信息确定多个对象的服务能力关联信息。

根据本公开的实施例，不再直接对提供服务的对象进行探测，极大地降低了探测连接数量，有助于降低监控对服务能力的影响，并有助于提升监控实时性，使得监控数据采集用时从分钟级减少至秒级。

根据本公开的实施例，基于注册信息和配置信息确定多个对象的服务能力关联信息包括：从注册信息中获取实际运行信息，并且从服务配置信息中获取期望运行信息，其中，实际运行信息包括以下至少一种：对象地址、端口号、服务版本号和服务权重，期望运行信息包括以下至少一种：数据中心标识、应用标识、对象集群信息和服务信息；以及基于实际运行信息和期望运行信息确定多个对象的服务能力关联信息。

根据本公开的实施例，注册信息包括以下至少一种：对象存活状态、对象地址、待监控服务分别在多个对象的服务状态、待监控服务分别在多个对象的服务权重。配置信息包括以下至少一种：为待监控服务配置的对象、待监控服务分别在多个对象的配置服务权重。

根据本公开的实施例，待监控服务包括从多个服务中确定的关键服务。

根据本公开的实施例，多个对象的服务能力关联信息包括以下至少一种：数据中心期望服务能力、数据中心实际服务能力、集群期望服务能力、集群实际服务能力、存活对象比例、数据中心服务能力健康度和集群服务能力健康度。

根据本公开的实施例，上述方法还包括如下操作：在确定多个对象的服务能力关联信息之后，确定多个对象的服务能力关联信息是否满足提示条件；以及在确定多个对象的服务能力关联信息满足提示条件时，输出提示信息。

根据本公开的实施例，提示条件包括多个等级，不同等级对应不同的提示策略。相应地，在确定多个对象的服务能力关联信息满足提示条件时，输出提示信息包括：确定多个对象的服务能力关联信息满足的提示条件等级；以及基于提示条件等级对应的提示策略输出提示信息。

根据本公开的实施例，上述方法还可以包括如下操作：在基于注册信息和配置信息确定多个对象的服务能力关联信息之后，对多个对象的服务能力关联信息进行图形化处理，得到图形化服务能力关联信息；以及输出图形化服务能力关联信息。

根据本公开的实施例，从注册信息集合中获取注册信息包括：通过定期轮训的方式从注册信息集合中获取注册信息。

本公开的另一个方面提供了一种服务监控装置，包括：服务标识接收模块、信息获取模块和关联信息确定模块。其中，服务标识接收模块，用于接收待监控服务的服务标识；信息获取模块，用于响应于服务标识，从注册信息集合中获取注册信息，并且从服务资源配置集合中获取服务配置信息，注册信息为提供待监控服务的多个对象进行注册后形成的，服务配置信息为针对待监控服务为多个对象设置的配置信息；以及关联信息确定模块，用于基于注册信息和配置信息确定多个对象的服务能力关联信息。

根据本公开的实施例，关联信息确定模块包括：信息获取单元、能力关联信息确定单元。其中，信息获取单元用于从注册信息中获取实际运行信息，并且从服务配置信息中获取期望运行信息，其中，实际运行信息包括以下至少一种：对象地址、端口号、服务版本号和服务权重，期望运行信息包括以下至少一种：数据中心标识、应用标识、对象集群信息和服务信息；以及能力关联信息确定单元用于基于实际运行信息和期望运行信息确定多个对象的服务能力关联信息。

根据本公开的实施例，注册信息包括以下至少一种：对象存活状态、对象地址、待监控服务分别在多个对象的服务状态、待监控服务分别在多个对象的服务权重；配置信息包括以下至少一种：为待监控服务配置的对象、待监控服务分别在多个对象的配置服务权重。

根据本公开的实施例，待监控服务包括从多个服务中确定的关键服务。

根据本公开的实施例，多个对象的服务能力关联信息包括以下至少一种：数据中心期望服务能力、数据中心实际服务能力、集群期望服务能力、集群实际服务能力、存活对象比例、数据中心服务能力健康度和集群服务能力健康度。

根据本公开的实施例，上述装置还包括：提示条件确定模块、提示信息输出模块。其中，提示条件确定模块用于在确定多个对象的服务能力关联信息之后，确定多个对象的服务能力关联信息是否满足提示条件；以及提示信息输出模块用于在确定多个对象的服务能力关联信息满足提示条件时，输出提示信息。

根据本公开的实施例，提示信息输出模块包括：等级确定单元和提示信息输出单元。其中，等级确定单元用于确定多个对象的服务能力关联信息满足的提示条件等级；以及提示信息输出单元用于基于提示条件等级对应的提示策略输出提示信息。

根据本公开的实施例，上述装置还包括：图形化处理模块、图形化信息输出模块。其中，图形化处理模块用于在基于注册信息和配置信息确定多个对象的服务能力关联信息之后，对多个对象的服务能力关联信息进行图形化处理，得到图形化服务能力关联信息；以及图形化信息输出模块用于输出图形化服务能力关联信息。

根据本公开的实施例，信息获取模块具体用于通过定期轮训的方式从注册信息集合中获取注册信息。

本公开的另一方面提供了一种电子设备，包括一个或多个处理器以及存储装置，其中，存储装置用于存储可执行指令，可执行指令在被处理器执行时，实现如上所述的方法。

本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，指令在被执行时用于实现如上所述的方法。

本公开的另一方面提供了一种计算机程序，计算机程序包括计算机可执行指令，指令在被执行时用于实现如上所述的方法。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述以及其他目的、特征和优点将更为清楚，在附图中：

图1示意性示出了根据本公开实施例的服务监控方法、服务监控装置、电子设备及介质的应用场景；

图2示意性示出了根据本公开实施例的适用服务监控方法、服务监控装置、电子设备及介质的系统架构；

图3示意性示出了相关技术的服务监控方法的信息流图；

图4示意性示出了根据本公开实施例的服务监控方法的流程图；

图5示意性示出了根据本公开实施例的服务监控的信息流图；

图6示意性示出了根据本公开另一实施例的服务监控方法的流程图；

图7示意性示出了根据本公开另一实施例的服务监控的信息流图；

图8示意性示出了根据本公开另一实施例的服务监控方法的流程图；

图9示意性示出了根据本公开实施例的可视化报告的示意图；

图10示意性示出了根据本公开实施例的服务监控装置的框图；以及

图11示意性示出了根据本公开实施例的电子设备的方框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。在使用类似于“A、B或C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B或C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个所述特征。

本公开的实施例提供了一种由服务器端执行的服务监控方法。该方法包括信息获取过程和能力确定过程。在信息获取过程中，响应于接收到的服务标识，从注册信息集合中获取注册信息，并且从服务资源配置集合中获取服务配置信息，注册信息为提供待监控服务的多个对象进行注册后形成的，服务配置信息为针对待监控服务为多个对象设置的配置信息，在完成信息获取过程之后，进入能力确定过程，基于注册信息和配置信息确定多个对象的服务能力关联信息。

图1示意性示出了根据本公开实施例的服务监控方法、服务监控装置、电子设备及介质的应用场景。

如图1所示，XX数据中心包括多个能提供服务的服务器，XX数据中心可以提供一种或多种服务。每个服务器具有针对某个服务的服务权重，多个服务器共同对上述某个服务提供支持。服务器的正常运行是向用户提供服务的基础保障。相关技术中需要服务的监控端与提供该服务的各服务器之间建立连接，以分别获取各服务器的运行状态参数，导致建立了大量的连接，消耗网络资源且运行状态等数据采集速度较慢，并且会占用各服务器的计算资源。本公开提供的服务监控方法无需监控端分别与各服务器之间建立连接，只需从注册信息集合中获取各服务器的注册信息，并且从服务资源配置集合中获取服务配置信息，然后对注册信息和服务配置信息进行比对分析，即可实现服务监控，分析得到的服务能力关联信息更加全面准确，且速度快，也不会占用服务器的计算资源。

图2示意性示出了根据本公开实施例的适用服务监控方法、服务监控装置、电子设备及介质的系统架构200。需要注意的是，图2所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

如图2所示，根据该实施例的系统架构200可以包括终端设备201、202、203，网络204和服务器205。网络204用以在终端设备201、202、203和服务器205之间提供通信链路的介质。网络204可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备201、202、203通过网络204与服务器205交互，以接收或发送消息等。终端设备201、202、203上可以安装有各种通讯客户端应用，例如监控类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

终端设备201、202、203可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器205可以是提供各种服务的服务器，例如对用户利用终端设备201、202、203所浏览的网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的用户请求等数据进行分析等处理，并将处理结果(例如根据用户请求获取或生成的多个对象的服务能力关联信息等)反馈给终端设备。

需要说明的是，本公开实施例所提供的服务监控方法一般可以由服务器205执行。相应地，本公开实施例所提供的服务监控装置一般可以设置于服务器205中。本公开实施例所提供的服务监控方法也可以由不同于服务器205且能够与终端设备201、202、203和/或服务器205通信的服务器或服务器集群执行。

应该理解，终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

本公开中技术术语包括：

远程调用：从一台计算机主机向其他计算机主机发起请求并获得返回结果的过程，是迄今企业应用软件系统中的主流的协作方式之一。

Dubbo:一个高性能的基于Java的开源的远程调用框架，是迄今主流的远程调用框架之一。

Java：迄今为止，主流的服务器端计算机编程语言之一。

服务：通过远程调用相互协作的应用系统中，发布并注册到远程调用框架(如：Dubbo)上，供其他主机调用的程序功能单元。

服务监控：通过程序自动探测监控目标的可用性，并设置阈值，在触发阈值规则时自动发送告警的技术保障手段。

关键服务：在基于服务协作的应用系统中，部分服务是完成核心业务目标必备的条件，当这些服务不可用时，会导致应用系统整体业务故障，这些服务称为关键服务。

服务生产者：部署服务并被调用的主机，如服务器。

整体服务能力：综合服务生产者的数量和每个服务生产者服务能力的综合指标。

图3示意性示出了相关技术的服务监控方法的信息流图。

如图3所示，相关监控方案基于对服务生产者所在主机的监控，基于远程调用框架(如Dubbo))通过探测程序定时探测主机是否联通、探测健康检查页面，并探测主机其他性能指标(如：CPU使用、内存占用、端口是否开启监听等)，将探测到的指标数据逐级汇总，并配置规则发出告警。

但是，该监控方案存在以下问题：首先，需逐台监控服务生产者所在的主机，主机数量为n，则每次需连接n台主机探测。其中，n为大于零的正整数。其次，针对同一台主机的探测，不同指标之间没有共享使用探测数据，如：探测主机存活与健康页检查分别建立了探测连接。此外，服务状态探测不准确：只能探测主机和端口号。服务权重(降权一般是因为服务生产者服务品质下降)、服务在某生产者上是否启用等状态无法探测得知。在汇总有哪些生产者可用时，无法正确计算得到整体服务能力的数值。另外，告警信息冗余度高，且未呈现整体视图。探测后的数据未进行汇总，告警只发送了某主机故障，但从服务的角度，未包含特定服务一共有多少台主机、存活多少台主机的信息。更没有根据整体可用程度设置阈值，设置告警策略。在批量故障的情况下，会发送大量告警，但都是主机层面的，告警数量虽然多，但对整体情况的把握处置没有直接的参考意义。

本公开的实施例解决服务监控过程中采集效率和告警信息呈现效率等问题。具体地，从服务的角度采集、汇总、处理监控数据，而不是主机角度。另外，从服务注册中心(远程调用框架提供的服务登记的地方)采集服务信息，而不是从主机采集。此外，结合配置管理数据库(简称CMDB，其用于保存服务生产者配置信息，展示正常情况下应该有哪些服务生产者)汇总发送告警信息，提高信息呈现效率。

以下结合图4～图11对本公开的技术方案进行详细说明。

图4示意性示出了根据本公开实施例的服务监控方法的流程图

如图4所示，该方法包括操作S401～操作S405。

在操作S401，接收待监控服务的服务标识。其中，服务标识用于全局唯一的标识一个服务，用户可以通过该服务标识找到待监控服务。例如，待监控服务包括从多个服务中确定的关键服务。可以是由用户从客户端指定的，也可以是系统基于规则或算法等自动确定的，如，还可以结合监控实践(Prometheus)的服务发现(Service Discovery)机制进行自定义扩展，可实现监控目标的自定义发现，减轻配置负担，提高应对变化的自动化水平。

在操作S403，响应于服务标识，从注册信息集合中获取注册信息，并且从服务资源配置集合中获取服务配置信息，注册信息为提供待监控服务的多个对象进行注册后形成的，服务配置信息为针对待监控服务为多个对象设置的配置信息。

具体地，基于注册信息和配置信息确定多个对象的服务能力关联信息包括：首先，从注册信息中获取实际运行信息，并且从服务配置信息中获取期望运行信息，其中，实际运行信息包括以下至少一种：对象地址、端口号、服务版本号和服务权重，期望运行信息包括以下至少一种：数据中心标识、应用标识、对象集群信息和服务信息。然后，基于实际运行信息和期望运行信息确定多个对象的服务能力关联信息。

其中，注册信息包括以下至少一种：对象存活状态、对象地址、待监控服务分别在多个对象的服务状态、待监控服务分别在多个对象的服务权重。

配置信息包括以下至少一种：为待监控服务配置的对象、待监控服务分别在多个对象的配置服务权重。

监控数据采集的信息来源可以为服务注册中心和配置管理数据库，并不从对象直接采集数据。

由相关技术从多个点建立网络连接采集(且每个点建立多个连接)，改变为从1个点采集数据(服务注册中心本身是高可用的，不存在单点问题)，提高了采集效率。

服务注册中心包含了服务生产者的实时信息，包括：对象是否存活、对象地址(IP、端口号等)、服务在某个对象上启用或禁用的状态、服务在某个对象上的权重。

这样使得采集的信息更全面，且针对服务的服务能力采集指标，更有针对性。

CMDB中保存了某服务分配了哪些主机资源，依据这些数据可以计算得出“正常情况下”(没有对象故障、服务降权、对象服务禁用的情况下)，总体的服务能力。结合在线服务生产者清单，可以比对得出故障离线、维修中的服务生产者清单。

本公开的实施例有效降低了服务在服务生产者上禁用或权重降级或版本不匹配造成的实际上服务能力降低却未发现的情况的可能性。此外，监控信息量及对业务处理的指导意义提高。整体的服务能力才是业务角度关注的重点，依据监控数据可以直接映射到运维动作，减少中间的人工汇总信息分析确认的操作，降低运维负担，提高运维响应能力。

在操作S405，基于注册信息和配置信息确定多个对象的服务能力关联信息。

其中，多个对象的服务能力关联信息包括以下至少一种：数据中心期望服务能力、数据中心实际服务能力、集群期望服务能力、集群实际服务能力、存活对象比例、数据中心服务能力健康度和集群服务能力健康度。

图5示意性示出了根据本公开实施例的服务监控的信息流图。

如图5所示，首先，从服务注册中心采集实时服务生产者数据。然后，从CMDB采集服务资源分配和主机维修状态数据。接着，汇总计算。图5中服务注册中心采用的是Zookeeper，核心功能为从Zookeeper查询信息并分析提取。可选地，从注册信息集合中获取注册信息包括：通过定期轮训的方式从注册信息集合中获取注册信息。定期轮训的方式对Zookeeper只有读操作，而不是采用监听由Zookeeper推送的方式，减轻了Zookeeper的负担，不会干扰Zookeeper正常的作为注册中心的职责。

采集实时服务生产者数据可以包括如下操作。

首先，查询注册信息。

具体地，可以在监控程序的配置文件中配置了需要监控的服务的标识。例如：“com.nucc.component.decrypt.api.AsymetricsService”，结合服务标识，将从Zookeeper“/dubbo/服务表识/providers”和“/dubbo/服务表识/configurators”两个节点下获取子节点数据。

然后，分析注册信息。

具体地，可以从获取的信息中，分析出生产者IP、端口号、版本号和权重。对于生产者仍然在线，但生产者上的某些服务已经禁用但情况，可以通过providers信息中权重为0，版本号信息缺失等特征分析出来。

从CMDB采集服务资源分配和主机维修状态数据可以包括如下操作。

通过程序接口获取CMDB数据，包括：互联网数据中心(IDC)、应用、集群、服务信息。并在本地缓存，定时更新。通过程序接口获取维修中的主机信息。

汇总计算可以包括如下操作。

汇总特定服务的当前IDC的服务能力、当前集群的服务能力，如下所示。

期望服务能力＝期望服务生产者数*期望服务权重

实际服务能力＝求和(生产者实际服务权重)

其中，以上统计是针对特定服务的。如果生产者下线，则生产者实际服务权重为0。如服务在生产者上禁用，则生产者实际服务权重为0。如生产者提供的服务版本号与期望统计的不符，则生产者服务权重为0。

此外，还可以得到如下服务能力关联信息：存活服务生产者比例和服务能力健康度。具体地，可以基于期望服务生产者数量、实际服务生产者数量确定存活服务生产者比例和服务能力健康度。基于期望服务能力和实际服务能力确定服务能力健康度。

例如，存活服务生产者比率＝(实际服务生产者数量/期望服务生产者数量)*100％

服务能力健康度＝(实际服务能力/期望服务能力)*100％其中，以上统计是针对特定服务的。实际生产者数量不包括：生产者下线的、当前服务在生产者上权重为0的。生产者为提供指定版本的服务的对象，如服务器等。

图6示意性示出了根据本公开另一实施例的服务监控方法的流程图。

如图6所示，在执行操作S305在确定多个对象的服务能力关联信息之后，上述方法还可以包括操作S601～操作S603。

在操作S601，确定多个对象的服务能力关联信息是否满足提示条件。

其中，提示条件可以是由用户设定的，如服务能力健康度低于设定健康度阈值、存活服务生产者比率低于存活阈值等。

在操作S603，在确定多个对象的服务能力关联信息满足提示条件时，输出提示信息。

在一个实施例中，提示条件包括多个等级，不同等级对应不同的提示策略。相应地，在确定多个对象的服务能力关联信息满足提示条件时，输出提示信息可以包括如下操作。

首先，确定多个对象的服务能力关联信息满足的提示条件等级。

然后，基于提示条件等级对应的提示策略输出提示信息。

图7示意性示出了根据本公开另一实施例的服务监控的信息流图。

如图7所示，监控数据采集程序在从注册中心获取服务状态，并从CMDB获取服务资源配置信息后，进行信息汇总，输出给客户端，使得客户端可以向用户展示多个对象的服务能力关联信息、提示信息等。为提供全局视图，态势感知提供数据依据，通过全局视图提高问题分析、故障处置的效率。

图8示意性示出了根据本公开另一实施例的服务监控方法的流程图。

如图8所示，上述方法在执行操作305基于注册信息和配置信息确定多个对象的服务能力关联信息之后，还可以包括操作S801～操作S803。

在操作S801，对多个对象的服务能力关联信息进行图形化处理，得到图形化服务能力关联信息。

例如，可以对多个对象的服务能力关联信息进行图表化，便于用户直观地查看服务能力变化趋势、报警信息分布、全局视图等。

在操作S803，输出图形化服务能力关联信息。

图9示意性示出了根据本公开实施例的可视化报告的示意图。

如图9所示，可视化报告中可以包括多个数据中心的服务器状态。其中，每个数据中心可以包括多个集群，分别展示各集群的状态。此外，也可以从服务的角度进行展示，如一个服务由哪些数据中心提供支持，其中，各数据中心的哪些集群的哪些服务器提供该服务，都可以从可视化报告中查看到。例如，每个集群相关服务能力关联信息可以包括存活服务器的数量和配置服务器的数量、服务能力健康度和报警信息等。本公开的实施例有效提升了用户进行服务监控的便捷度。

本公开实施例提供的服务监控方法，从业务角度切入，汇总数据提供监控数据整体视图，监控数据的业务指导性更高，提高了风险发现和处置的能力。

本公开实施例提供的服务监控方法，采集数据更全面、准确，降低了因服务禁用、降权、版本不匹配等因素造成的对服务能力的误判，降低了潜在风险。

本公开实施例提供的服务监控方法，监控数据采集方式的改变，提高了数据采集的效率，对监控对象影响更小，效率更高，从分钟级采集提高到秒级采集。

图10示意性示出了根据本公开实施例的服务监控装置的框图。

如图10所示，服务监控装置1000包括服务标识接收模块1010、信息获取模块1030和关联信息确定模块1050。

服务标识接收模块1010用于接收待监控服务的服务标识；

信息获取模块1030用于响应于服务标识，从注册信息集合中获取注册信息，并且从服务资源配置集合中获取服务配置信息，注册信息为提供待监控服务的多个对象进行注册后形成的，服务配置信息为针对待监控服务为多个对象设置的配置信息。例如，信息获取模块具体用于通过定期轮训的方式从注册信息集合中获取注册信息。

关联信息确定模块1050用于基于注册信息和配置信息确定多个对象的服务能力关联信息。

在一个实施例中，关联信息确定模块1050包括：信息获取单元、能力关联信息确定单元。

其中，信息获取单元用于从注册信息中获取实际运行信息，并且从服务配置信息中获取期望运行信息，其中，实际运行信息包括以下至少一种：对象地址、端口号、服务版本号和服务权重，期望运行信息包括以下至少一种：数据中心标识、应用标识、对象集群信息和服务信息；以及能力关联信息确定单元用于基于实际运行信息和期望运行信息确定多个对象的服务能力关联信息。

具体地，注册信息包括以下至少一种：对象存活状态、对象地址、待监控服务分别在多个对象的服务状态、待监控服务分别在多个对象的服务权重；配置信息包括以下至少一种：为待监控服务配置的对象、待监控服务分别在多个对象的配置服务权重。

例如，待监控服务包括从多个服务中确定的关键服务。

在一个实施例中，多个对象的服务能力关联信息包括以下至少一种：数据中心期望服务能力、数据中心实际服务能力、集群期望服务能力、集群实际服务能力、存活对象比例、数据中心服务能力健康度和集群服务能力健康度。

在另一个实施例中，上述装置1000还包括：提示条件确定模块、提示信息输出模块。

其中，提示条件确定模块用于在确定多个对象的服务能力关联信息之后，确定多个对象的服务能力关联信息是否满足提示条件。

提示信息输出模块用于在确定多个对象的服务能力关联信息满足提示条件时，输出提示信息。

具体地，提示信息输出模块可以包括：等级确定单元和提示信息输出单元。

等级确定单元用于确定多个对象的服务能力关联信息满足的提示条件等级。

提示信息输出单元用于基于提示条件等级对应的提示策略输出提示信息。

在另一个实施例中，上述装置1000还可以包括：图形化处理模块、图形化信息输出模块。

图形化处理模块用于在基于注册信息和配置信息确定多个对象的服务能力关联信息之后，对多个对象的服务能力关联信息进行图形化处理，得到图形化服务能力关联信息；以及图形化信息输出模块用于输出图形化服务能力关联信息。

根据本公开的实施例的模块、子模块、单元、子单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、子模块、单元、子单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

例如，服务标识接收模块1010、信息获取模块1030和关联信息确定模块1050中的任意多个可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，服务标识接收模块1010、信息获取模块1030和关联信息确定模块1050中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，服务标识接收模块1010、信息获取模块1030和关联信息确定模块1050中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

图11示意性示出了根据本公开实施例的电子设备的方框图。。图11示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图11所示，根据本公开实施例的电子设备1100包括处理器1101，其可以根据存储在只读存储器(ROM)1102中的程序或者从存储部分1108加载到随机访问存储器(RAM)1103中的程序而执行各种适当的动作和处理。处理器1101例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器1101还可以包括用于缓存用途的板载存储器。处理器1101可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在RAM 1103中，存储有电子设备1100操作所需的各种程序和数据。处理器1101、ROM 1102以及RAM 1103通过总线1104彼此相连。处理器1101通过执行ROM 1102和/或RAM1103中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，程序也可以存储在除ROM 1102和RAM 1103以外的一个或多个存储器中。处理器1101也可以通过执行存储在一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，系统1100还可以包括输入/输出(I/O)接口1105，输入/输出(I/O)接口1105也连接至总线1104。系统1100还可以包括连接至I/O接口1105的以下部件中的一项或多项：包括键盘、鼠标等的输入部分1106；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1107；包括硬盘等的存储部分1108；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1109。通信部分1109经由诸如因特网的网络执行通信处理。驱动器1110也根据需要连接至I/O接口1105。可拆卸介质1111，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1110上，以便于从其上读出的计算机程序根据需要被安装入存储部分1108。

根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1109从网络上被下载和安装，和/或从可拆卸介质1111被安装。在该计算机程序被处理器1101执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的ROM 1102和/或RAM 1103和/或ROM 1102和RAM1103以外的一个或多个存储器。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解的是，本公开的各个实施例和/或权利要求中记载的特征，可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。

Claims (12)

1.一种由服务器端执行的服务监控方法，包括：

接收待监控服务的服务标识；

响应于所述服务标识，从注册信息集合中获取注册信息，并且从服务资源配置集合中获取服务配置信息，所述注册信息为提供所述待监控服务的多个对象进行注册后形成的，所述服务配置信息为针对所述待监控服务为所述多个对象设置的配置信息；以及

基于所述注册信息和所述配置信息确定所述多个对象的服务能力关联信息。

2.根据权利要求1所述的方法，其中，所述基于所述注册信息和所述配置信息确定所述多个对象的服务能力关联信息包括：

从所述注册信息中获取实际运行信息，并且从所述服务配置信息中获取期望运行信息，其中，所述实际运行信息包括以下至少一种：对象地址、端口号、服务版本号和服务权重，所述期望运行信息包括以下至少一种：数据中心标识、应用标识、对象集群信息和服务信息；以及

基于所述实际运行信息和所述期望运行信息确定所述多个对象的服务能力关联信息。

3.根据权利要求1所述的方法，其中：

所述注册信息包括以下至少一种：对象存活状态、对象地址、所述待监控服务分别在所述多个对象的服务状态、所述待监控服务分别在所述多个对象的服务权重；以及

所述配置信息包括以下至少一种：为所述待监控服务配置的对象、所述待监控服务分别在所述多个对象的配置服务权重。

4.根据权利要求1所述的方法，其中，所述待监控服务包括从多个服务中确定的关键服务。

5.根据权利要求1所述的方法，其中，所述多个对象的服务能力关联信息包括以下至少一种：数据中心期望服务能力、数据中心实际服务能力、集群期望服务能力、集群实际服务能力、存活对象比例、数据中心服务能力健康度和集群服务能力健康度。

6.根据权利要求1所述的方法，还包括：在确定所述多个对象的服务能力关联信息之后，

确定所述多个对象的服务能力关联信息是否满足提示条件；以及

在确定所述多个对象的服务能力关联信息满足提示条件时，输出提示信息。

7.根据权利要求1所述的方法，其中：

所述提示条件包括多个等级，不同等级对应不同的提示策略；

所述在确定所述多个对象的服务能力关联信息满足提示条件时，输出提示信息包括：

确定所述多个对象的服务能力关联信息满足的提示条件等级；以及

基于所述提示条件等级对应的提示策略输出提示信息。

8.根据权利要求1所述的方法，还包括：在基于所述注册信息和所述配置信息确定所述多个对象的服务能力关联信息之后，

对所述多个对象的服务能力关联信息进行图形化处理，得到图形化服务能力关联信息；以及

输出所述图形化服务能力关联信息。

9.根据权利要求1所述的方法，其中，所述从注册信息集合中获取注册信息包括：

通过定期轮训的方式从注册信息集合中获取注册信息。

10.一种服务监控装置，包括：

服务标识接收模块，用于接收待监控服务的服务标识；

信息获取模块，用于响应于所述服务标识，从注册信息集合中获取注册信息，并且从服务资源配置集合中获取服务配置信息，所述注册信息为提供所述待监控服务的多个对象进行注册后形成的，所述服务配置信息为针对所述待监控服务为所述多个对象设置的配置信息；以及

关联信息确定模块，用于基于所述注册信息和所述配置信息确定所述多个对象的服务能力关联信息。

11.一种电子设备，包括：

一个或多个处理器；

存储装置，用于存储可执行指令，所述可执行指令在被所述处理器执行时，实现根据权利要求1～9中任一项所述的方法。

12.一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时实现根据权利要求1～9中任一项所述的方法。

Images