CN116302826A - 一种智能运维监控平台、方法、存储介质及电子设备 - Google Patents

Abstract

本申请的一些实施例提供了一种智能运维监控平台、方法、存储介质及电子设备，该智能运维监控平台包括：数据处理模块，用于将获取的多个业务系统的指标数据与对应的监控指标阈值进行对比，得到对比结果；监控展示模块，用于基于所述对比结果，显示所述多个业务系统中各个业务系统的数据状态；告警处理模块，用于在所述数据状态为所述告警状态时，向目标人员发送告警指令，其中，所述告警指令中携带有告警推送信息，以便于所述目标人员及时定位并解决所述告警推送信息中的问题。本申请的一些实施例可以实现对公司系统的全面监控，确保系统安全稳定运行。

Description

一种智能运维监控平台、方法、存储介质及电子设备

技术领域

本申请涉及数据运维技术领域，具体而言，涉及一种智能运维监控平台、方法、存储介质及电子设备。

背景技术

随着公司的发展和变迁，公司内部的业务系统越来越多，业务系统的运维工作量也越来越大，随之而来需要处理的业务系统的问题的难度也会越来越大。

目前，大多数监控软件主要针对主流监控项进行监控。而且随着业务系统复杂度的不断升级，当业务报备系统出现异常时，需要运维人员查看系统是否可以稳定运行，并且通过日志主动发现问题，当业务系统的问题被发现之后，从定位到解决需要耗费较长的时间周期，效率较低。

因此，如何提供一种高效的智能运维监控平台的技术方案成为亟需解决的技术问题。

发明内容

本申请的一些实施例的目的在于提供一种智能运维监控平台、方法、存储介质及电子设备，通过本申请的实施例的技术方案可以实现对各种业务系统的统一监控，并且可以对异常进行告警，对告警进行快速定位，及时解决告警，效率较高，有效确保了公司系统的安全稳定运行。

第一方面，本申请的一些实施例提供了一种智能运维监控平台，包括：数据处理模块，用于将获取的多个业务系统的指标数据与对应的监控指标阈值进行对比，得到对比结果；监控展示模块，用于基于所述对比结果，显示所述多个业务系统中各个业务系统的数据状态，其中，所述数据状态表征所述各个业务系统中的多个层级对应的指标数据的状态，所述状态包括以下中的至少两种：正常状态、预警状态和告警状态；告警处理模块，用于在所述数据状态为所述告警状态时，向目标人员发送告警指令，其中，所述告警指令中携带有告警推送信息，以便于所述目标人员及时定位并解决所述告警推送信息中的问题。

本申请的一些实施例通过数据处理模块可以获取多个业务系统的监控指标，并与监控指标阈值进行对比得到对比结果。然后监控展示模块可以将对比结果展示出来，并显示指标数据的状态。最后在指标数据的状态为告警状态时，可以向相关目标人员发送告警指令，以便于及时解决告警。本申请实施例可以实现对各种业务系统的统一监控，并且可以对异常进行告警，对告警进行快速定位，及时解决告警，效率较高，有效确保了公司系统的安全稳定运行。

在一些实施例，所述智能运维监控平台还包括：链路拓扑模块，用于展示所述各个业务系统之间的调用信息，以及展示所述各个业务系统内部的接口调用信息。

本申请的一些实施例通过链路拓扑模块可以展示各个业务系统内部和外部之间的关系，可以清晰准确的展示业务系统的运行情况。

在一些实施例，所述链路拓扑模块，还用于：基于所述各个业务系统中的多个层级对应的指标数据的状态，按照预设规则展示所述各个业务系统的系统状态，以便于所述目标人员快速定位异常。

本申请的一些实施例链路拓扑模块通过拓扑图展示业务系统之间的调用状态，通过链路视图来追踪定位具体问题，效率较高。

在一些实施例，所述多个层级包括：机器层、数据库层和系统层，在所述数据处理模块之前，所述智能运维监控平台还包括：数据获取模块，用于：通过不同的数据收集渠道分别收集所述机器层的指标数据、数据库层的指标数据以及所述系统层的指标数据，其中，所述机器层的指标数据的类型包括：中央处理器使用率、虚拟内存使用率和磁盘使用率，所述数据库层的指标数据的类型包括：数据库慢查询、数据库连接数和数据库锁数量，所述系统层的指标数据的类型包括：访问数据量、响应时间和请求数据量。

本申请的一些实施例通过不同的渠道获取不同层级的数据，可以实现对个异化系统的有效监控。

在一些实施例，在所述数据处理模块之前，所述智能运维监控平台还包括：数据获取模块，用于：实时采集所述多个业务系统的指标数据；所述数据处理模块，用于实时将所述多个业务系统的指标数据与所述监控指标阈值进行对比，得到所述对比结果；或者，定期采集所述多个业务系统的指标数据；所述数据处理模块，用于定期将所述多个业务系统的指标数据与所述监控指标阈值进行对比，得到所述对比结果。

本申请的一些实施例通过实时或定期采集业务系统的指标数据并与监控指标阈值进行对比，可以实现对系统的有效监控。

在一些实施例，所述监控展示模块，用于：响应于用户的操作指令，跳转至与所述操作指令对应的目标业务系统的详细页面，其中，所述详细页面中包括：所述目标业务系统的运行状态、所述多个层级中各个层级对应的指标数据以及所述告警推送信息。

本申请的一些实施例通过用户的操作指令向用户展示目标业务系统的运营的详细页面，可以清晰准确的展示系统运行情况，快速定位问题。

在一些实施例，所述数据处理模块，还用于：配置与所述各个业务系统中各个层级下的指标数据对应的各项监控指标阈值；将所述各个业务系统中各个层级下的指标数据与所述各项监控指标阈值进行对比，得到所述对比结果。

本申请的一些实施例通过配置各项监控指标阈值，可以实现对不同业务系统的统一监控。

第二方面，本申请的一些实施例提供了一种智能运维监控方法，包括：将获取的多个业务系统的指标数据与对应的监控指标阈值进行对比，得到对比结果；基于所述对比结果，显示所述多个业务系统中各个业务系统的数据状态，其中，所述数据状态表征所述各个业务系统中的多个层级对应的指标数据的状态，所述状态包括以下中的至少两种：正常状态、预警状态和告警状态；在所述数据状态为所述告警状态时，向目标人员发送告警指令，其中，所述告警指令中携带有告警推送信息，以便于所述目标人员及时定位并解决所述告警推送信息中的问题。

第三方面，本申请的一些实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时可实现如第一方面任一实施例所述的方法。

第四方面，本申请的一些实施例提供一种电子设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，其中，所述处理器执行所述程序时可实现如第一方面任一实施例所述的方法。

第五方面，本申请的一些实施例提供一种计算机程序产品，所述的计算机程序产品包括计算机程序，其中，所述的计算机程序被处理器执行时可实现如第一方面任一实施例所述的方法。

附图说明

为了更清楚地说明本申请的一些实施例的技术方案，下面将对本申请的一些实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请的一些实施例提供的一种智能运维监控平台的架构图；

图2为本申请的一些实施例提供的智能运维监控平台的展示图之一；

图3为本申请的一些实施例提供的智能运维监控平台的展示图之二；

图4为本申请的一些实施例提供的一种智能运维监控的方法流程图；

图5为本申请的一些实施例提供的一种电子设备示意图。

具体实施方式

下面将结合本申请的一些实施例中的附图，对本申请的一些实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

相关技术中，随着公司的不断发展和业务的变迁，公司内部的业务系统(简称系统)不断增多，系统的运维工作量也越来越大，处理问题的难度也越来越大。如何保证系统的稳定运行以及快速的解决问题，成为了当前很多公司面临的难题。目前市场上也有许多监控软件，例如zabbix、prometheus等监控软件，其可以进行系统的监控。但有些个异化的系统、特殊监控项的指标不能很好的实现监控。从现有的系统监控情况来看，主要面临以下两个方面的问题：

(1)监控差异化。目前大多数监控软件，主要针对主流监控项监控采集。而对于日志、事件或链路的监控比较差。因此在进行链路追踪，或者预警系统攻击的时候，就会比较被动。例如：一个系统陌生ip的访问情况，一个ip针对公司内部所有系统的访问情况等等，这些指标都需要提前预警，保证公司系统的安全稳定的运行。

(2)快速定位问题。针对系统复杂度的升级，快速解决问题也是一个关键。当前处理问题的一个逻辑为：业务报备系统不好用时，运维人员需要查看系统是否稳定运行。通过查看日志去定位问题、处理问题和解决问题。很明显。当前解决问题的方案时长较长，时效性不强。

由上述相关技术可知，现有技术中对公司业务系统的监控全面性较差且无法快速定位问题，效率较低。

鉴于此，本申请的一些实施例提供了一种智能运维监控平台，该智能运维监控平台的数据处理模块可以将获取的多个业务系统的指标数据与对应的监控指标阈值进行对比，得到对比结果后，通过监控显示模块将对比结果转换为数据状态展示出来。对于存在告警状态的数据，告警处理模块可以向目标人员推送相关的告警指令，以使得目标人员可以根据告警指令快速定位告警问题并解决。本申请的一些实施例可以将公司的业务系统集成在智能运维监控平台上进行统一管理，并且通过显示可以及时得知出现告警状态的数据，进而可以快速定位并解决问题，效率较高，确保了公司系统的安全稳定运行。

下面结合附图1示例性阐述本申请的一些实施例提供的智能运维监控平台的整体组成结构。

如图1所示，本申请的一些实施例提供了一种智能运维监控平台的架构图。智能运维监控平台包括：数据处理模块110、监控展示模块120以及告警处理模块130。

下面示例性阐述各模块的功能。

在本申请的一些实施例中，数据处理模块110，用于将获取的多个业务系统的指标数据与对应的监控指标阈值进行对比，得到对比结果。

例如，在本申请的一些实施例中，数据处理模块110可以将收集到的各个系统的各项监控指标(作为指标数据的一个具体示例)汇总。之后与设置的各项监控指标对应的阈值(作为监控指标阈值的一个具体示例)进行对比，以实现实时、准确的系统异常预警。

在本申请的一些实施例中，在数据处理模块110之前，智能运维监控平台还包括：数据获取模块(图中未示出)，用于：通过不同的数据收集渠道分别收集所述机器层的指标数据、数据库层的指标数据以及所述系统层的指标数据，其中，所述机器层的指标数据的类型包括：中央处理器使用率、虚拟内存使用率和磁盘使用率，所述数据库层的指标数据的类型包括：数据库慢查询、数据库连接数和数据库锁数量，所述系统层的指标数据的类型包括：访问数据量、响应时间和请求数据量。

例如，在本申请的一些实施例中，智能运维监控平台可以监控全方位的、覆盖整个系统。例如可以包括监控的机器层、数据库层和系统层三个层级。系统层级方面的监控，弥补了prometheus不能监控日志、链路图的缺憾，增加了监控的维度。监控指标的意义在于系统，不同系统有不同的侧重点，所以针对不同的系统所监控的指标也不一样。因此智能运维监控平台之所谓全方位，就是汇总监控指标、制订个异化监控指标阈值。

具体的，在本申请的一些实施例中，根据监控指标的特点，可以通过不同的渠道进行收集汇总监控指标，然后推送到Kafka，供大数据订阅消费及处理，然后可以通过小屏(作为监控展示模块的一个具体示例)的方式进行展示。其中，数据库层的数据收集分为两种：自主收集数据和对接API(Application Programming Interface，应用程序接口)模式。系统层的日志的数据收集采取filebeat或者http接口等模式。主机层(也就是机器层)的数据收集主要是通过zabbix获取数据。Web页面信息的统计，则主要是通过http接口的模式获取。

例如，作为本申请的一个具体示例：

数据库层面(也就是数据库层)：针对oracle、redis等数据库，直接对接源库进行采集。针对mysql、tbase、oceanbase等数据库，通过http请求接口获取数据。将采集到的数据统计推送到数据处理模块110的Kafka，直接供智能运维监控平台使用。

nginx日志：通过在nginx中配置上报服务地址，可收集通过nginx转发的请求，获取关注系统、ip(Internet Protocol，网际互连协议)、重点url的访问量和响应时间，然后推送至Kafka。

服务日志：通过Flume/FileBeat可增量识别并解析日志文件，可收集应用日志中关注的监控信息、错误信息并格式化后推送至Kafka。

主机层面：通过zabbix底层使用mysql进行数据存储，通过cannal将Zabbix数据库中的监控数据推送至Kafka中。

Web统计-Piwik：piwik使用mysql进行数据存储，直接通过接口的模式获取想要的埋点数据推送至kafka。

需要说明的是，在本申请的一些实施例中，针对不同的监控指标可以采用对应的方式获取。应理解，上述列举的只是部分监控指标的具体获取方式，本申请实施例并不局限于此。

在本申请的一些实施例中，数据处理模块110，还用于：配置与所述各个业务系统中各个层级下的指标数据对应的各项监控指标阈值；将所述各个业务系统中各个层级下的指标数据与所述各项监控指标阈值进行对比，得到所述对比结果。

例如，在本申请的一些实施例中，由于不同的层级所获取的监控指标的类型也不相同，因此需要针对监控指标的类型配置不同的监控指标阈值，并在后续进行分别对比，得到各项监控指标的对比结果。例如，对于机器层来说，其监控指标的类型包括：中央处理器CPU(Central Processing Unit)使用率、虚拟内存swap使用率以及磁盘disk使用率。在监控之前需要对CPU使用率设置CPU监控指标阈值，swap使用率设置swap监控指标阈值以及disk使用率设置disk监控指标阈值。可以理解的是，数据库层和系统层的设置方式与机器层类似，在此不作赘述。

在本申请的一些实施例中，数据获取模块，用于：实时采集所述多个业务系统的指标数据；数据处理模块110，用于实时将所述多个业务系统的指标数据与所述监控指标阈值进行对比，得到所述对比结果。

例如，在本申请的一些实施例中，对监控指标进行监控时可以采用实时流式计算。例如，从Kafka中或Hbase中获取实时的监控指标对应的数据，并进行实时计算。然后将计算后的结果持久化至Hbase或ClickHouse中，并推送至Kafka。系统前端可以实时消费，根据各系统配置的监控指标阈值以及告警人，对于存在异常的监控指标进行实时推送告警信息(作为告警推送信息的一个具体示例)给运维人员(作为目标人员的一个具体示例)。

在本申请的一些实施例中，智能运维监控平台还可以根据实时的监控数据，将监控指标在预设时间内的实际发展趋势通过折线图或柱形图的方式展示出来，以便于运维人员以及开发人员观察系统运行情况，快速定位问题。

在本申请的另一些实施例中，数据获取模块，用于：定期采集所述多个业务系统的指标数据；数据处理模块110，用于定期将所述多个业务系统的指标数据与所述监控指标阈值进行对比，得到所述对比结果。

例如，在本申请的一些实施例中，对监控指标进行监控时可以采用批处理的方式进行计算。也就是定期从Hbase或ClickHouse中获取原始的监控指标的数据、监控指标的数据统计结果、业务流程数据，然后进行计算统计分析，并推送至Kafka。

在本申请的一些实施例中，监控展示模块120，用于基于所述对比结果，显示所述多个业务系统中各个业务系统的数据状态，其中，所述数据状态表征所述各个业务系统中的多个层级对应的指标数据的状态，所述状态包括以下中的至少两种：正常状态、预警状态和告警状态。

例如，在本申请的一些实施例中，监控展示模块120可以是可视化显示屏。该模块可以通过对比结果，展示出各个业务系统的监控指标的状态。例如，如图2所示的智能运维监控平台的展示图，其包括：公司系统下的智能中枢平台以及统一人力办公app(阳光plusapp)两个业务系统。每个业务系统包括：服务层(也就是机器层)、系统层和数据库层。每个层级通过圆饼图的方式显示每种监控指标的状态。在不同的状态下，可以采用不同的颜色进行表征。例如，在正常状态下用蓝色表征，逼近告警状态(也就是预警状态)下用黄色表征，告警状态(也就是图2中的有告警)下用橘色表征等等。可以理解的是，基于公司集团下的业务系统的类型可以在可视化显示屏上均通过如图2的方式显示业务系统的运营情况。通过颜色区分状态可以快速实现告警定位。

并且需要说明的是，智能运维平台根据监控指标的不同，进行不同图形化的展示。也可以根据自己系统的需求，进行个异化选择，实现监控可视化。智能运维监控平台操作灵活方便，运维人员可以通过小屏+小屏的方式，查看运维系统的运维情况。可以自己制订监控指标，实现个异化指标监控。可以根据系统的需要，进行各监控指标的阈值配置。

在本申请的一些实施例中，监控展示模块120，用于响应于用户的操作指令，跳转至与所述操作指令对应的目标业务系统的详细页面，其中，所述详细页面中包括：所述目标业务系统的运行状态、所述多个层级中各个层级对应的指标数据以及所述告警推送信息。

例如，在本申请的一些实施例中，用户可以是运维人员也可以是具有权限的其他人员。用户通过点击图2中的“查看更多”可以跳转至图3所示的详情页(作为详细页面的一个具体示例)。其中，图3是以公司中的共享平台下的质检系统Quliatyinspect为例进行展示的，有图3可知，详情页中包括：质检系统的错误率、健康状况、告警推送信息(主要包括：告警来源、告警信息和响应时间)、服务层的CPU使用率、磁盘使用率、swap区使用率，数据库层的数据库连接数、慢SQL(也就是数据库慢查询)、锁个数(也就是数据库锁数量)以及等待Wait统计等等。在其详情页的右上角还会显示当前数据的时间阶段。

在本申请的一些实施例中，告警处理模块130，用于在所述数据状态为所述告警状态时，向目标人员发送告警指令，其中，所述告警指令中携带有告警推送信息，以便于所述目标人员及时定位并解决所述告警推送信息中的问题。

传统的定位问题是查看日志，然后跟开发人员沟通确认是哪里有告警。为了实现对告警的快速定位，例如，在本申请的一些实施例中，智能运维监控平台的监控是模块化的，若某个系统存在问题，监控展示模块120可以在用颜色展示出存在告警的同时向运维人员发送告警指令，以便于运维人员可以及时得到并定位当前告警，大大节省了解决问题的时间、运维成本，也降低了因为系统问题导致公司财产损失的风险。

在本申请的一些实施例中，所述智能运维监控平台还包括：链路拓扑模块(图中未示出)，用于展示所述各个业务系统之间的调用信息，以及展示所述各个业务系统内部的接口调用信息。

例如，在本申请的一些实施例中，针对系统重点url(Uniform Resource Locator,统一资源定位器)、突发攻击等特殊预警，链路拓扑模块可以通过可视大屏展示拓扑图以展示业务系统间的调用关系，通过链路视图来实现追踪定位具体告警问题。具体的，通过调用skywalking的接口模式，直接获取对接的业务系统的链路系统，得到链路图谱，并且运维人员可以配置自定义规则，使得链路拓扑模块可以根据自定义规则展示告警。

在本申请的一些实施例中，链路拓扑模块，还用于：基于所述各个业务系统中的多个层级对应的指标数据的状态，按照预设规则展示所述各个业务系统的系统状态，以便于所述目标人员快速定位异常。

例如，在本申请的一些实施例中，链路拓扑模块可以根据自定义规则在拓扑图中展示告警位置(例如，通过颜色不同确定系统的告警位置)。例如，当某个业务系统存在问题时，可以在拓扑图上该业务系统的位置标注实心红色圆点。并通过链路图分析其他业务系统是否稳定运行，以此确保公司整个系统的稳定安全运行。

通过上述本申请的一些实施例提供的智能运维监控平台可知，本发明运维人员通过大屏+小屏的方式，查看运维系统的运维情况。通过对公司系统的全方位、多监控指标的监控运维，保证系统的稳定运行，并且还可以提前预警系统问题，准确快速的解决问题，缩短了处理风险问题的时效，从而避免了因系统故障导致资金费用损失情况的出行。通过个异化的图标展示，方便了开发以及运维人员查看系统的运行情况以及资源使用情况，客观的展示系统的稳定性，个异化的报警设置，可以达到一对一的告警处理，从而减少运维人力，降低人工成本。

下面结合附图4示例性阐述本申请的一些实施例提供的由智能运维监控平台执行的智能运维监控方法的实现过程。

请参见附图4，图4为本申请的一些实施例提供的一种智能运维监控方法流程图，该方法包括：S410，将获取的多个业务系统的指标数据与对应的监控指标阈值进行对比，得到对比结果。S420，基于所述对比结果，显示所述多个业务系统中各个业务系统的数据状态，其中，所述数据状态表征所述各个业务系统中的多个层级对应的指标数据的状态，所述状态包括以下中的至少两种：正常状态、预警状态和告警状态。S430，在所述数据状态为所述告警状态时，向目标人员发送告警指令，其中，所述告警指令中携带有告警推送信息，以便于所述目标人员及时定位并解决所述告警推送信息中的问题。

例如，作为本申请的一个具体示例。首先采集到某个业务系统的监控指标，并与监控指标阈值进行对比，确定当前业务系统存在问题时，智能运维监控平台第一时间会发送告警指令进行推送告警(例如，通过阳光小助手、短信等方式推送)，告警人(也就是运维人员)接受告警。通过告警信息快速定位告警层(例如，告警信息属于主机层，应用层，数据库层或公共服务层)。例如应用层nginx错误数(4xx)过高。运维人员第一时间去通过图2的展示图查看系统访问量是否可接受，系统是否稳定。还可以与开发人员一块通过应用日志查看错误数过高是否正常，以此达到准确定位，快速解决问题的效果。

在本申请的一些实施例中，智能运维监控方法还包括：展示所述各个业务系统之间的调用信息，以及展示所述各个业务系统内部的接口调用信息。

在本申请的一些实施例中，智能运维监控方法还包括：基于所述各个业务系统中的多个层级对应的指标数据的状态，按照预设规则展示所述各个业务系统的系统状态，以便于所述目标人员快速定位异常。

在本申请的一些实施例中，所述多个层级包括：机器层、数据库层和系统层，在S410之前，智能运维监控方法还包括：通过不同的数据收集渠道分别收集所述机器层的指标数据、数据库层的指标数据以及所述系统层的指标数据，其中，所述机器层的指标数据的类型包括：中央处理器使用率、虚拟内存使用率和磁盘使用率，所述数据库层的指标数据的类型包括：数据库慢查询、数据库连接数和数据库锁数量，所述系统层的指标数据的类型包括：访问数据量、响应时间和请求数据量。

在本申请的一些实施例中，S410还可以包括：实时采集所述多个业务系统的指标数据；实时将所述多个业务系统的指标数据与所述监控指标阈值进行对比，得到所述对比结果；或者，定期采集所述多个业务系统的指标数据；定期将所述多个业务系统的指标数据与所述监控指标阈值进行对比，得到所述对比结果。

在本申请的一些实施例中，S420还可以包括：响应于用户的操作指令，跳转至与所述操作指令对应的目标业务系统的详细页面，其中，所述详细页面中包括：所述目标业务系统的运行状态、所述多个层级中各个层级对应的指标数据以及所述告警推送信息。

在本申请的一些实施例中，S410还可以包括：配置与所述各个业务系统中各个层级下的指标数据对应的各项监控指标阈值；将所述各个业务系统中各个层级下的指标数据与所述各项监控指标阈值进行对比，得到所述对比结果。

本申请的一些实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时可实现如上述实施例提供的上述方法中的任意实施例所对应方法的操作。

本申请的一些实施例还提供了一种计算机程序产品，所述的计算机程序产品包括计算机程序，其中，所述的计算机程序被处理器执行时可实现如上述实施例提供的上述方法中的任意实施例所对应方法的操作。

如图5所示，本申请的一些实施例提供一种电子设备500，该电子设备500包括：存储器510、处理器520以及存储在存储器510上并可在处理器520上运行的计算机程序，其中，处理器520通过总线530从存储器510读取程序并执行所述程序时可实现如上述任意实施例的方法。

处理器520可以处理数字信号，可以包括各种计算结构。例如复杂指令集计算机结构、结构精简指令集计算机结构或者一种实行多种指令集组合的结构。在一些示例中，处理器520可以是微处理器。

存储器510可以用于存储由处理器520执行的指令或指令执行过程中相关的数据。这些指令和/或数据可以包括代码，用于实现本申请实施例描述的一个或多个模块的一些功能或者全部功能。本公开实施例的处理器520可以用于执行存储器510中的指令以实现上述所示的方法。存储器510包括动态随机存取存储器、静态随机存取存储器、闪存、光存储器或其它本领域技术人员所熟知的存储器。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

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

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (10)

1.一种智能运维监控平台，其特征在于，包括：

数据处理模块，用于将获取的多个业务系统的指标数据与对应的监控指标阈值进行对比，得到对比结果；

监控展示模块，用于基于所述对比结果，显示所述多个业务系统中各个业务系统的数据状态，其中，所述数据状态表征所述各个业务系统中的多个层级对应的指标数据的状态，所述状态包括以下中的至少两种：正常状态、预警状态和告警状态；

告警处理模块，用于在所述数据状态为所述告警状态时，向目标人员发送告警指令，其中，所述告警指令中携带有告警推送信息，以便于所述目标人员及时定位并解决所述告警推送信息中的问题。

2.如权利要求1所述的智能运维监控平台，其特征在于，所述智能运维监控平台还包括：

链路拓扑模块，用于展示所述各个业务系统之间的调用信息，以及展示所述各个业务系统内部的接口调用信息。

3.如权利要求2所述的智能运维监控平台，其特征在于，所述链路拓扑模块，还用于：

基于所述各个业务系统中的多个层级对应的指标数据的状态，按照预设规则展示所述各个业务系统的系统状态，以便于所述目标人员快速定位异常。

4.如权利要求1-3中任一项所述的智能运维监控平台，其特征在于，所述多个层级包括：机器层、数据库层和系统层，在所述数据处理模块之前，所述智能运维监控平台还包括：数据获取模块，用于：

通过不同的数据收集渠道分别收集所述机器层的指标数据、数据库层的指标数据以及所述系统层的指标数据，其中，所述机器层的指标数据的类型包括：中央处理器使用率、虚拟内存使用率和磁盘使用率，所述数据库层的指标数据的类型包括：数据库慢查询、数据库连接数和数据库锁数量，所述系统层的指标数据的类型包括：访问数据量、响应时间和请求数据量。

5.如权利要求1-3中任一项所述的智能运维监控平台，其特征在于，在所述数据处理模块之前，所述智能运维监控平台还包括：数据获取模块，用于：

实时采集所述多个业务系统的指标数据；

所述数据处理模块，用于实时将所述多个业务系统的指标数据与所述监控指标阈值进行对比，得到所述对比结果；

或者，

定期采集所述多个业务系统的指标数据；

所述数据处理模块，用于定期将所述多个业务系统的指标数据与所述监控指标阈值进行对比，得到所述对比结果。

6.如权利要求1-3中任一项所述的智能运维监控平台，其特征在于，所述监控展示模块，用于：

响应于用户的操作指令，跳转至与所述操作指令对应的目标业务系统的详细页面，其中，所述详细页面中包括：所述目标业务系统的运行状态、所述多个层级中各个层级对应的指标数据以及所述告警推送信息。

7.如权利要求1-3中任一项所述的智能运维监控平台，其特征在于，所述数据处理模块，还用于：

配置与所述各个业务系统中各个层级下的指标数据对应的各项监控指标阈值；

将所述各个业务系统中各个层级下的指标数据与所述各项监控指标阈值进行对比，得到所述对比结果。

8.一种智能运维监控方法，其特征在于，包括：

将获取的多个业务系统的指标数据与对应的监控指标阈值进行对比，得到对比结果；

基于所述对比结果，显示所述多个业务系统中各个业务系统的数据状态，其中，所述数据状态表征所述各个业务系统中的多个层级对应的指标数据的状态，所述状态包括以下中的至少两种：正常状态、预警状态和告警状态；

在所述数据状态为所述告警状态时，向目标人员发送告警指令，其中，所述告警指令中携带有告警推送信息，以便于所述目标人员及时定位并解决所述告警推送信息中的问题。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，其中，所述计算机程序被处理器运行时执行如权利要求8所述的方法。

10.一种电子设备，其特征在于，包括存储器、处理器以及存储在所述存储器上并在所述处理器上运行的计算机程序，其中，所述计算机程序被所述处理器运行时执行如权利要求8所述的方法。

Images