CN113010373A - 数据监控方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请实施例提供了一种数据监控方法、装置、电子设备及存储介质，涉及计算机技术领域。其中，该数据监控方法包括：接收数据监控请求，数据监控请求指示有监控目标在设定监控维度下的监控项；根据监控目标在设定监控维度下的监控项，确定数据查询方式；按照数据查询方式查询数据，包括：在数据查询方式为非单机查询时，根据设定监控维度在索引集合中搜索匹配的集合元素，并根据匹配到的集合元素查询对应的索引聚合数据；对查询到的数据进行相应处理，得到监控目标的监控结果，并返回监控目标的监控结果。本申请实施例解决了现有技术中数据监控的实时性较差的问题。

Description

数据监控方法、装置、电子设备及存储介质

技术领域

本申请涉及计算机技术领域，具体而言，本申请涉及一种数据监控方法、装置、电子设备及存储介质。

背景技术

随着互联网技术的发展，热门业务的用户访问量往往很大，例如，热门业务包括即时通讯业务、视频业务、游戏业务、商品购买业务、车联服务业务等等，用户可通过相关应用来访问该些业务，进而享受该些业务所提供的服务，例如，应用包括即时通讯类应用、视频类应用、游戏类应用、购物类应用、地图类应用等等。如果该些业务仅使用一台服务器为用户提供服务势必影响用户体验，这就需要多台服务器甚至是服务器集群来共同为用户提供服务。

随着用户访问量逐步上升，各服务器的存储能力和处理能力也将达到上限，通常需要通过业务变更的方式来缓解原有服务器的存储压力和负载压力。例如，业务变更可以是数据迁移等。

目前，业务变更时，监控人员通常需要对业务变更过程中涉及的服务器进行数据监控，以便于能够及时地发现业务变更过程中的数据异常，以此保障现有业务的正常运行。然而，相关技术中的数据监控方法在查询监控人员请求监控的数据时，一旦出现数据维度爆炸，将难以满足现有业务对数据监控的实时性要求。

发明内容

本申请各实施例提供了一种数据监控方法、装置、电子设备及存储介质，可以解决相关技术中存在的数据监控的实时性较差的问题。所述技术方案如下：

根据本申请实施例的一个方面，一种数据监控方法，包括：接收数据监控请求，数据监控请求指示有监控目标在设定监控维度下的监控项；根据监控目标在设定监控维度下的监控项，确定数据查询方式；按照数据查询方式查询数据，包括：在数据查询方式为非单机查询时，根据设定监控维度在索引集合中搜索匹配的集合元素，并根据匹配到的集合元素查询对应的索引聚合数据，集合元素用于表示监控对象存在对应索引聚合数据的监控维度或者监控维度组合；对查询到的数据进行相应处理，得到监控目标的监控结果，并返回监控目标的监控结果。

根据本申请实施例的一个方面，一种数据监控装置，包括：数据请求接收模块，用于接收数据监控请求，数据监控请求指示有监控目标在设定监控维度下的监控项；查询方式确定模块，用于根据监控目标在设定监控维度下的监控项，确定数据查询方式；数据查询模块，用于按照数据查询方式查询数据，数据查询模块包括：索引数据查询单元，用于在数据查询方式为非单机查询时，根据设定监控维度在索引集合中搜索匹配的集合元素，并根据匹配到的集合元素查询对应的索引聚合数据，集合元素用于表示监控对象存在对应索引聚合数据的监控维度或者监控维度组合；监控结果返回模块，用于对查询到的数据进行相应处理，得到监控目标的监控结果，并返回监控目标的监控结果。

在一种可能的实现方式，装置，还包括：数据接收模块，用于接收数据上报方上报的监控对象的监控数据；第一存储模块，用于存储接收到的监控数据，以形成监控对象对应于不同数据上报方的监控数据；以及第二存储模块，用于按照监控对象的聚合规则，对接收到的监控数据进行聚合，得到监控对象的聚合数据，存储监控对象的聚合数据，聚合数据包括IP聚合数据和索引聚合数据。

在一种可能的实现方式，第二存储模块，包括：第一聚合单元，用于对监控对象对应于不同数据上报方的监控数据按照相同监控项组合进行聚合，得到监控对象的IP聚合数据；第二聚合单元，用于根据索引集合中的集合元素，对监控对象的IP聚合数据进行聚合，得到监控对象对应于集合元素的索引聚合数据。

在一种可能的实现方式，待存储数据包括监控对象对应于不同数据上报方的监控数据、监控对象的IP聚合数据、以及监控对象对应于集合元素的索引聚合数据；第一存储模块，包括：标识生成单元，用于提取设定条目数的待存储数据，根据待存储数据的数据长度生成待存储数据对应的压缩标识；数据封装单元，用于将设定条目数的待压缩数据及其对应的压缩标识封装为压缩数据，压缩数据包括监控对象对应于不同数据上报方的第一压缩数据、监控对象的第二压缩数据、以及监控对象对应于集合元素的第三压缩数据，所述第一压缩数据对应所述监控数据、所述第二压缩数据对应所述IP聚合数据、以及所述第三压缩数据对应所述索引聚合数据；数据存储单元，用于将压缩数据存储至存储块，存储块的数据长度与压缩数据的数据长度相同。

在一种可能的实现方式，装置，还包括：数据监测模块，用于监测监控对象的监控数据的监控项组合数，并根据监测结果对索引集合进行相应处理。

在一种可能的实现方式，数据监测模块，包括：第一监测单元，用于如果索引集合中存在集合元素，则根据集合元素确定监控对象的监控数据的第一监控项组合，并监测第一监控项组合的数目；第一选取单元，用于当第一监控项组合的数目超过第一阈值，根据第一监控项组合所在的监控维度选取监控维度；元素更新单元，用于根据选取到的监控维度更新集合元素。

在一种可能的实现方式，数据监测模块，包括：第二监测单元，用于如果索引集合中不存在集合元素，则确定监控对象的监控数据的第二监控项组合，并监测第二监控项组合的数目；第二选取单元，用于当第二监控项组合的数目超过第二阈值，根据第二监控项组合所在的监控维度选取监控维度；元素添加单元，用于将选取到的监控维度作为新的集合元素，添加至索引集合。

在一种可能的实现方式，输入监控项组合包括第一监控项组合以及第二监控项组合；第一选取单元以及第二选取单元，包括：遍历子单元，用于对输入监控项组合所在的监控维度进行遍历，从所有监控维度中，选取排除遍历到的监控维度的剩余监控维度，作为统计维度；统计子单元，用于确定统计维度下的监控项组合的数目，作为遍历到的监控维度的统计值；选取子单元，用于选取统计值最小的监控维度。

在一种可能的实现方式，查询方式确定模块，包括：第一确定单元，用于如果监控项包括数据上报方的IP地址，则确定数据查询方式为单机查询；第二确定单元，用于确定数据查询方式为非单机查询。

在一种可能的实现方式，数据查询模块，还包括：监控数据查询单元，用于在数据查询方式为单机查询时，查询获取监控目标对应于数据上报方的监控数据；或者IP数据查询单元，用于在数据查询方式为非单机查询，并且根据包含全部监控项的设定监控维度在索引集合中未搜索到匹配的到集合元素时，查询获取监控目标在设定监控维度下的监控项对应的IP聚合数据。

在一种可能的实现方式，所述数据获取单元，包括：数据提取子单元，用于获取相应的压缩数据，从压缩数据中提取压缩标识，压缩数据包括监控对象对应于不同数据上报方的第一压缩数据、监控对象的第二压缩数据、以及监控对象对应于集合元素的第三压缩数据，监控项组合由设定监控维度下的监控项确定；数据解压子单元，用于根据压缩标识对压缩数据进行解压缩，得到相应数据，相应数据包括监控目标对应于数据上报方的监控数据、监控目标在设定监控维度下的监控项对应的IP聚合数据、以及集合元素对应的索引聚合数据。

在一种可能的实现方式，数据提取子单元，包括：时间段确定子单元，用于根据数据监控请求确定请求进行数据监控的时间段；第一查询子单元，用于如果时间段在设定时间范围之内，则从临时存储区的存储块中拉取相应的压缩数据；第二查询子单元，用于如果时间段未在设定时间范围之内，则从持久存储区的存储块中拉取相应的压缩数据。

在一种可能的实现方式，临时存储区包括主存储区和备份存储区；第一查询子单元，包括：存储区切换子单元，用于当主存储区中不存在相应的压缩数据，或者，主存储区的工作状态处于异常状态，则从备份临时存储区的存储块中拉取相应的压缩数据。

在一种可能的实现方式，数据获取单元，还包括：数据去重子单元，用于确定查询到的数据对应的数据标识，根据数据标识对查询到的数据进行去重处理。

在一种可能的实现方式，监控结果返回模块，包括：第三聚合单元，用于按照监控目标的聚合规则，将查询到的符合不同监控项组合的数据进行聚合，得到监控目标的细粒度数据；第二四聚合单元，用于根据设定时间粒度，对监控目标的细粒度数据进行聚合，得到监控目标的监控结果。

在一种可能的实现方式，监控目标为若干个单一型监控对象构成的复合型监控对象；第四聚合单元，包括：时间聚合子单元，用于针对每一个单一型监控对象，根据设定时间粒度，对单一型监控对象的细粒度数据进行聚合，得到单一型监控对象的粗粒度数据；结果生成子单元，用于按照监控目标的聚合规则对各单一型监控对象的粗粒度数据进行聚合，得到监控目标的监控结果。

在一种可能的实现方式，聚合数据处理模块，还包括：第三聚合单元，用于如果监控目标不存在未匹配到集合元素的其余监控项，则按照监控目标的聚合规则对集合元素对应的聚合数据进行聚合，得到监控目标的监控结果。

根据本申请实施例的一个方面，一种电子设备，包括：至少一个处理器、至少一个存储器、以及至少一条通信总线，其中，存储器上存储有计算机可读指令，处理器通过通信总线读取存储器中的计算机可读指令；计算机可读指令被处理器执行时实现如上所述的数据监控方法。

根据本申请实施例的一个方面，一种存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现如上所述的数据监控方法。

根据本申请实施例的一个方面，一种计算机程序产品，计算机程序产品包括计算机可读指令，计算机可读指令存储在存储介质中，计算机设备的处理器从存储介质读取计算机可读指令，处理器执行计算机可读指令，使得计算机设备执行时实现如上所述的数据监控方法。

本申请提供的技术方案带来的有益效果是：

在上述技术方案中，基于数据监控请求指示的监控目标在设定监控维度下的监控项，确定数据查询方式，在数据查询方式为非单机查询时，根据设定监控维度在索引集合中搜索匹配的集合元素，以根据匹配到的集合元素查询对应的索引聚合数据，并对查询到的数据进行相应处理，得到监控目标的监控结果，以此返回请求发起方，也就是说，通过提前存储监控对象的监控维度或者监控维度组合对应的索引聚合数据，在数据监控时，如果设定监控维度能够命中存在对应索引聚合数据的监控维度或者监控维度组合，便能够直接查询并拉取提前存储的索引聚合数据进行数据监控，以此方式有效地降低实际需要拉取的数据量，极大地提高了数据查询速度，从而能够有效地解决现有技术中存在的数据监控的实时性较差的问题。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍。

图1是根据本申请所涉及的实施环境的示意图。

图2是根据一示例性实施例示出的一种数据监控方法的流程图。

图3是图2对应实施例所涉及的监控界面显示数据查询入口和监控结果的示意图。

图4是根据一示例性实施例示出的另一种数据监控方法的流程图。

图5是图4对应实施例中步骤430在一个实施例的流程图。

图6是图5对应实施例所涉及的IP聚合过程的流程图。

图7是图5对应实施例所涉及的索引聚合过程的流程图。

图8是根据一示例性实施例示出的另一种数据监控方法的流程图。

图9是图8对应实施例所涉及的压缩数据及其压缩标识的示意图。

图10是根据一示例性实施例示出的另一种数据监控方法的流程图。

图11是图10对应实施例所涉及的主备存储的示意图。

图12是图11对应实施例中步骤610在一个实施例的流程图。

图13是图4对应实施例中步骤420在一个实施例的流程图。

图14是图4对应实施例中步骤420在另一个实施例的流程图。

图15是根据一示例性实施例示出的另一种数据监控方法的流程图。

图16是图2对应实施例中步骤370在一个实施例的流程图。

图17是图16对应实施例中步骤373在一个实施例的流程图。

图18是一应用场景中一种数据监控方法的实现示意图。

图19是图18对应应用场景所涉及的区块链网络的示意图。

图20是根据一示例性实施例示出的一种数据监控装置的结构框图。

图21是根据一示例性实施例示出的一种服务器的硬件结构图。

图22是根据一示例性实施例示出的一种电子设备的结构框图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

下面结合表1，对本申请涉及的几个名词进行介绍和解释：

表1即时通讯业务的监控数据

业务：也可以理解为项目，可以是即时通讯业务、视频业务、游戏业务、商品购买业务、车联服务业务等等。例如，表1中呈现的是即时通讯业务的监控数据。当然，根据应用场景的实际需要，也可以将前述业务归类为前端业务，则业务还可以包括后端业务，此处并非构成具体限定。

应用：可以是即时通讯类应用、视频类应用、游戏类应用、购物类应用、地图类应用等等。当然，此处的应用是狭义上的理解，根据应用场景的实际需要，也可以扩展至广义上的定义，则应用还涉及后端业务的应用，此处也并非构成具体限定。

指标：表示一个度量字段，以便于准确地衡量业务的运行状态是否正常，该指标包括但不限于请求数、下载速度、流量、成功率、丢包率等等，其中，请求数可以进一步地包括写请求数和读请求数。对应地，不同指标具有不同的聚合规则，例如，请求数的聚合规则可以是求和、求平均、下载速度的聚合规则可以是求最大、流量的聚合规则可以是求和、成功率的聚合规则可以是求最大、丢包率的聚合规则可以是求最小。该指标包括单一指标和复合指标，例如，请求数、下载速度、流量、丢包率为单一指标，成功率为复合指标。

复合指标：相对于单一指标而言，是指通过多个单一指标运算产生。例如，单一指标为请求数和请求成功数，则复合指标为成功率＝请求成功数/请求数。

监控对象：用于表示业务的应用的指标。例如，如上表1所示，即时通讯业务的A应用的请求数可视为一个监控对象，即时通讯业务的B应用的下载速度可视为另一个监控对象。也就是说，当业务、应用、指标中任意一项不同，监控对象将有所区别。由于指标包括单一指标和复合指标，对应地，监控对象包括单一型监控对象和复合型监控对象，复合型监控对象由若干个单一型监控对象构成。

监控维度：表示监控对象的不同属性。该属性可以是指表1中的地区、运营商、设备类型、IP地址等。当然，根据应用场景的实际需要，该属性还可以是集群、集成环境、机房、设备接口、端口号、进程、错误码等等，在此并非构成具体限定。监控维度具有查询属性，当监控人员指示查询该监控维度下的全部监控项，该监控维度的查询属性视为全部查询；当监控人员指示查询该监控维度下的其中一部分监控项，该监控维度的查询属性视为具体查询。

监控项：也可以理解为监控维度的维度子项，用于表示监控对象的属性的具体内容。如表1所示，当监控维度为地区时，广东、福建、海南视为地区维度下的监控项。或者，当监控维度为运营商时，电信、移动、联通视为运营商维度下的监控项。或者，当监控维度为IP地址时，具体IP地址视为IP地址维度下的监控项。值得一提的是，如果还存在广州、深圳隶属于广东，福州、厦门隶属于福建，此时，既可以进一步地细化监控项，即广东广州、广东深圳、福建福州、福建厦门视为地区维度下的监控项；也可以增加一个与地区维度并列的维度，例如，市县维度，那么，广州、深圳、福州、厦门可视为市县维度下的监控项。然而，无论上述何种方式，都将使得监控维度下的监控项有所增加。随着监控维度下监控项的增加，监控项组合数将呈量级上涨，例如，2个监控维度下各包含2个监控项，对应的监控项组合数为4；2个监控维度下各包含3个监控项，对应的监控项组合数为9。一旦监控项组合数过多，便有可能导致数据监控过程中出现数据维度爆炸的现象。

监控数据：是指数据上报方上报的一条携带IP地址且符合一定属性的监控对象的数据。该数据上报方可以是机房中某业务部署的某个服务器，也可以是接入某业务所部署的某个服务器的用户设备。如表1所示，每一个条目视为一条监控数据，例如，序号1的监控数据，表示该监控数据的监控对象为即时通讯业务的A应用的请求数，该监控数据所符合的监控对象的监控维度分别为地区、运营商、设备类型、IP地址，以及各监控维度下的监控项分别为广东、电信、电脑、具体IP地址，该监控数据是由具体IP地址为192.168.125.10的数据上报方上报的，10/min表示该监控数据用于聚合的具体数值。

监控目标：用于表示请求进行数据监控的一个监控对象或者多个监控对象。例如，即时通讯业务进行变更时，监控人员请求监控即时通讯业务的B应用的请求数和请求成功数，那么，本次数据监控的监控目标可以包括两个监控对象，为即时通讯业务的B应用的请求数和请求成功数。当然，监控人员也可以请求监控即时通讯业务的B应用的成功率，此时，监控目标为复合型监控对象，由两个单一型监控对象构成，该两个单一型监控对象包括即时通讯业务的B应用的请求数和请求成功数。

如前所述，现有的数据监控过程，在按照监控人员的指示查询请求监控的数据时，一旦出现数据维度爆炸，将难以满足现有业务对数据监控的实时性要求。

通常的解决办法是警示监控人员降低数据维度，以使得请求监控的数据得以减少数据量，避免数据维度爆炸，以此方式来满足现有业务对数据监控的实时性要求，然而用户体验并不好。

由此，又提出了一种解决方法，如图1a所示，在存储数据上报方上报的监控对象的监控数据之前，先根据该监控数据的监控项或者监控项组合，为该监控数据注册特性ID，然后由配置更新系统按照该特性ID对该监控数据进行分发，以使得具有不同特性ID的监控数据得以在不同缓存cache中存储。那么，在监控人员进行数据查询时，首先根据监控目标在设定监控维度下的监控项查找到已注册的特性ID，以根据该特性ID从相应的cache中拉取对应的监控数据，并在即时计算模块中计算，以此“由整化零”的方式降低数据维度，进而来满足实时性要求。

然而，在上述解决方法中，随着数据上报方上报的监控对象的监控数据呈量级上涨，将导致即时计算模块的计算时间愈来愈长，仍然无法满足现有业务对数据监控的实时性要求。

此外，特性ID本身存在缺陷：一方面，特性ID是数值类型，有上限限制，无法满足海量级别的监控数据，并且随着对应监控数据删除而注销之后容易出现复用的现象；另一方面，特性ID是存储在数据库的，注册速度往往受到数据库性能的限制，可能导致数据上报方上报的监控对象的监控数据无法及时注册，仍可能影响数据监控的实时性。

由上可知，现有的数据监控方法仍存在难以满足现有业务对数据监控的实时性要求的局限性。

为此，本申请提供的数据监控方法、装置、电子设备及存储介质，旨在解决现有技术的如上技术问题。

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

图1为一种数据监控方法所涉及的实施环境的示意图。该实施环境包括数据上报方100、数据监控方200和请求发起方300。

具体地，数据上报方100可以是机房中某业务部署的某个服务器，也可以是接入某业务所部署的某个服务器的用户设备。该数据上报方100可以是台式电脑、笔记本电脑、平板电脑、智能手机、服务器、车载设备等等电子设备，在此不进行限定。

数据监控方200可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器，还可以是提供车联网服务、路网协同、车路协同、智能交通、自动驾驶、工业互联网服务、数据通信(如4G、5G等)等专门或平台服务器。例如，本实施环境中，数据监控方200提供的后台服务包括数据监控服务。

数据监控方200通过有线或者无线等方式预先建立与数据上报方100之间的通信连接，以通过该通信连接实现数据上报方100与数据监控方200之间的数据传输。例如，传输的数据包括数据上报方100上报的监控数据等。

请求发起方300，可供具备数据监控功能的客户端运行，可以是台式电脑、笔记本电脑、车载设备、平板电脑、服务器等等电子设备，在此不进行限定。

其中，客户端，具备数据监控功能，例如，数据监控装置，可以是应用程序形式，也可以是网页形式，相应地，该客户端用于数据监控的监控界面则可以是程序窗口形式，还可以是网页页面形式的，此处也并未加以限定。

数据监控方200通过有线或者无线等方式预先建立与请求发起方300之间的通信连接，以通过该通信连接实现数据监控方200与请求发起方300之间的数据传输。例如，传输的数据包括请求发起方300发送的数据监控请求、数据监控方200返回的监控目标的监控结果等。

一方面，随着数据上报方100与数据监控方200之间的交互，数据上报方100将监控对象的监控数据上报至数据监控方200，对应地，数据监控方200便能够接收到该监控对象的监控数据，以便于后续基于该监控数据为请求发起方300提供数据监控服务。

另一方面，就请求发起方300而言，如果监控人员请求进行关于监控目标在设定监控维度下的监控项的数据监控，便向数据监控方200发送数据监控请求，对应地，数据监控方200在接收到该数据监控请求之后，便能够响应于该数据监控请求为请求发起方300提供数据监控服务，以使得请求发起方300接收到监控目标的监控结果，进而在请求发起方300的监控界面中向监控人员展示监控目标的监控结果。

请参阅图2，本申请实施例提供了一种数据监控方法，该方法适用于服务器，例如图1所示出实施环境中的数据监控方200。

在下述方法实施例中，为了便于描述，以各步骤的执行主体为服务器加以说明，但是并不对此构成限定。

如图2所示，该方法可以包括以下步骤：

步骤310，接收数据监控请求。

其中，数据监控请求用于指示监控目标在设定监控维度下的监控项。

该监控目标是指监控人员请求进行数据监控的监控对象，该监控目标可以是单一型监控对象，例如请求数，也可以是由若干个单一型监控对象构成的复合型监控对象，例如成功率，此处并未加以限定。

该设定监控维度是指监控人员请求进行数据监控的监控维度，可以由监控人员指定，也可以由系统配置，此处也并未加以限定。

就请求发起方而言，监控界面中显示数据查询入口，如果监控人员期望监控某些监控对象在某些监控维度下的某些监控项对应的监控数据，便可在该数据查询入口触发相关的操作，以使得请求发起方能够检测到该操作。

例如，如图3所示，其示例性示出了监控界面显示数据查询入口的示意图。在监控界面中显示有若干个选择输入框，具体包括：业务选择框、应用选择框、指标选择框、地区选择框、运营商选择框、设备类型选择框以及IP地址选择框。其中，业务选择框、应用选择框以及指标选择框用于支持不同监控对象的选择，地区选择框用于支持地区纬度下各监控项的选择，运营商选择框用于支持运营商纬度下各监控项的选择，设备类型选择框用于支持设备类型纬度下各监控项的选择，IP地址选择框用于支持IP地址纬度下各监控项的输入。

值得一提的是，在该监控界面中，还提供支持选择请求进行数据监控时间段的选择输入框“当前周期”、提供支持对比的选择输入框“对比”、以及支持展示粒度的选择输入框“展示粒度”，此处并非构成具体限定。

当监控人员分别在上述选择输入框中选择了“即时通讯业务”、“A应用”、“请求数”、“广东”、“电信”、“电脑”以及“全部”，即表示监控人员请求进行数据监控的监控对象，即监控目标为即时通讯业务的A应用的请求数，监控人员请求进行数据监控的监控维度，即设定监控维度包括地区维度、运营商维度、设备类型维度以及IP地址维度，在该些设定监控维度下的监控项分别为广东、电信、电脑以及全部具体IP地址。其中，地区维度、运营商维度以及设备类型维度的查询属性为具体查询，而IP地址维度的查询属性为全部查询。

由此，请求发起方便能够检测到上述选择操作，以此获知监控目标在设定监控维度下的监控项。其中，选择输入框视为数据查询入口，选择操作视为监控人员在该数据查询入口触发的相关操作。

需要说明的是，根据请求发起方所配置输入组件(例如显示屏幕上铺盖的触摸层、鼠标、键盘等)的不同，监控人员在数据查询入口触发的相关操作的具体行为也可以各不相同。例如，借由触摸层输入的平板电脑而言，操作可以是点击、滑动等手势操作，而对于配置鼠标的台式电脑而言，操作则可以是拖拽、单击、双击等机械操作，在此不进行具体限定。

当请求发起方获知监控目标在设定监控维度下的监控项，便能够以此生成数据监控请求，并将该数据监控请求发送至数据监控方。对应地，数据监控方便能够接收到该数据监控请求，进而响应于该数据监控请求，为监控人员提供关于监控目标在设定监控维度下的监控项的数据监控服务。

步骤330，根据监控目标在设定监控维度下的监控项，确定数据查询方式。

如前所述，监控维度具有不同的查询属性：全部查询和具体查询。可以理解，当监控维度的查询属性为具体查询，即监控人员指定查询该监控维度下的其中一部分监控项甚至于其中一个监控项，相较于监控维度的查询属性为全部查询，即监控人员指定查询该监控维度下的全部监控项，拉取的数据量会少很多。

在此，发明人意识到，如果针对数据量拉取最多的监控人员指定查询监控维度下的全部监控项，提供预聚合多次的数据，而针对数据量拉取较少的监控人员指定查询监控维度下的其中一部分监控项，提供预聚合一两次的数据，而针对数据量拉取最少的监控人员指定查询监控维度下的其中一个监控项，提供原始未聚合的数据，以此方式能够有效地降低实际拉取的数据量，进而有利于提高数据查询速度。

因此，本实施例中，为了提高数据监控过程中数据查询速度，将针对数据上报方上报的监控对象的监控数据进行预聚合。那么，在进行数据查询之前，需要首先确定数据查询方式，以按照不同的数据查询方式查询相应数据。也可以理解为，数据查询方式用于指示是否查询经过聚合的数据。

其中，数据查询方式包括单机查询、非单机查询。该单机查询是指监控人员指定查询某一个具体IP地址的数据上报方上报的监控对象的监控数据。该非单机查询则是指监控人员指定查询不同数据上报方上报的监控对象的监控数据。

在一种可能的实现方式中，数据查询方式的确定可以包括以下步骤：如果设定监控维度下的监控项包括数据上报方的IP地址，则确定数据查询方式为单机查询；否则，确定数据查询方式为非单机查询。

举例来说，回请参阅表1所示，如果设定监控维度下的监控项分别为广东、电信、电脑、192.168.125.10，即表示监控人员指定查询具体IP地址为192.168.125.10的数据上报方上报的监控目标为即时通讯业务的A应用的请求数的监控数据。此时，数据监控方便可确定数据查询方式为单机查询。

步骤350，按照数据查询方式查询数据。

如前所述，数据查询方式用于指示是否查询经过聚合的数据。

也就是说，当数据查询方式为单机查询时，拉取的数据量最少，则直接拉取原始未经过聚合的数据。

当数据查询方式为非单机查询时，一方面，如果各设定监控维度的查询属性均为全部查询，此时拉取的数据量最多，便可拉取经过多次聚合的集合元素对应的索引聚合数据，由于该索引聚合数据是已提前多次聚合形成的，则不必重复拉取，以此降低实际需要拉取的数据量，进而避免出现数据维度爆炸；另一方面，如果任意一个设定监控维度的查询属性为具体查询，此时拉取的数据量相对较少，便可拉取经过一次聚合的监控对象对应于监控项组合的IP聚合数据，而并非拉取数据上报方上报的原始未经过聚合的监控对象的监控数据，以此方式来使得实际需要拉取的数据量得以减少，有利于提升数据查询速度。

具体地，在一种可能的实现方式中，在数据查询方式为单机查询时，查询监控目标对应于数据上报方的监控数据，以此方式针对拉取数据量最少情况下实现原始未聚合的数据的快速命中。

仍以前述例子说明，数据监控方查询到监控目标对应于具体IP地址为192.168.125.10的数据上报方的监控数据，即表1中示出的序号1的监控数据。

在一种可能的实现方式中，在数据查询方式为非单机查询时，根据设定监控维度在索引集合中搜索匹配的集合元素。其中，集合元素用于表示监控对象存在对应索引聚合数据的监控维度或者监控维度组合。

如果在索引集合中未搜索到匹配的集合元素，则查询监控目标在设定监控维度下的监控项对应的IP聚合数据。其中，该IP聚合数据是指监控对象对应于不同数据上报方的监控数据按照相同监控项组合进行聚合形成的。此种方式针对拉取数据量较少情况下实现经过一次聚合的数据的快速命中。

如果在索引集合中搜索到匹配的集合元素，则查询匹配到的集合元素对应的索引聚合数据。其中，索引聚合数据是指根据该集合元素对监控对象对应于监控项组合的IP聚合数据进行聚合形成的。此种方式针对拉取数据量最多情况下实现经过多次聚合的数据的快速命中。

步骤370，对查询到的数据进行相应处理，得到监控目标的监控结果，并返回监控目标的监控结果。

就查询到的数据而言，无论是监控目标对应于数据上报方的监控数据，或者监控目标在设定监控维度下的监控项对应的IP聚合数据，还是集合元素对应的索引聚合数据，实质是不同时刻符合不同监控项组合的数据，还需要进行相应处理，方可得到监控目标的监控结果。在数据监控方得到监控目标的监控结果之后，便可将该监控目标的监控结果返回至请求发起方。

对应地，请求发起方便能够接收到该监控目标的监控结果，进而在监控界面中展示该监控目标的监控结果。可选地，根据应用场景的实际需要，该监控目标的监控结果的展示方式包括但不限于文字、数字、图形、列表等形式。

例如，如图3所示，其示例性示出了监控界面展示监控目标的监控结果的示意图。当监控目标为即时通讯业务的A应用的请求数，监控项包括地区纬度下的广东、运营商维度下的电信、设备类型维度下的电脑、以及IP地址维度下的全部具体IP地址时，监控目标的监控结果包括请求数在不同时刻的累计值、全天的累计值、全天的平均值、以及最大值、最小值、最新值等等。在监控界面中，以图形方式显示了请求数在不同时刻的累计值对应的波形，并以列表方式显示了请求数的最大值、最小值、最新值、全天的平均值以及全天的累计值。

通过上述过程，通过提前存储监控对象的监控项或者监控项组合对应的聚合数据，在数据监控时，如果监控目标的监控项能够命中存在对应聚合数据的监控项或者监控项组合，便能够直接查询提前存储的聚合数据进行数据监控，以此方式有效地降低数据维度，极大地提高了数据查询速度，从而能够有效地解决现有技术中存在的数据监控的实时性较差的问题。

请参阅图4，本申请实施例中提供了一种可能的实现方式，该方法还可以包括以下步骤：

步骤410，接收数据上报方上报的监控对象的监控数据。

随着海量数据上报方上报的关于各监控对象的监控数据，对于数据监控方而言，接收到监控数据对应于不同数据上报方，监控对象也可能各不相同。

举例来说，如表1所示，在某一时刻，序号1至序号7的监控数据，为数据监控方接收到各数据上报方上报的监控对象(即时通讯业务的A应用的请求数)的监控数据。序号8的监控数据，为数据监控方接收到各数据上报方上报的监控对象(即时通讯业务的B应用的请求数)的监控数据。序号9至序号10的监控数据，为数据监控方接收到各数据上报方上报的监控对象(即时通讯业务的B应用的下载速度)的监控数据。

那么，在接收到上述监控数据之后，便能够对该些监控数据进行预聚合，以此方式来提高数据查询速度。

步骤430，按照监控对象的聚合规则，对接收到的监控数据进行聚合，得到监控对象的聚合数据，并存储。

其中，聚合数据包括IP聚合数据和索引聚合数据。

具体地，在一种可能的实现方式中，如图5所示，步骤430可以包括以下步骤：

步骤431，对监控对象对应于不同数据上报方的监控数据按照相同监控项组合进行聚合，得到监控对象的IP聚合数据。

举例来说，如表1所示，序号1的监控数据和序号2的监控数据，视为监控对象(即时通讯业务的A应用的请求数)对应于不同数据上报方(192.168.125.10和192.168.125.20)的监控数据，由于该两条监控数据具有相同监控项组合(广东、电信、电脑)，故而，二者可聚合为该监控对象(即时通讯业务的A应用的请求数)对应于该相同监控项组合(广东、电信、电脑)的IP聚合数据。同理，序号5的监控数据可视为该监控对象对应于监控项组合(福建、电信、电脑)的IP聚合数据。

也就是说，针对监控对象在设定监控维度下的监控项而言，IP聚合实质是忽略IP地址维度，将其余监控维度下具有相同监控项组合的监控数据聚合。

例如，如图6所示，其示例性示出了IP聚合过程的流程图。

步骤433，根据索引集合中的集合元素，对监控对象的IP聚合数据进行聚合，得到监控对象对应于集合元素的索引聚合数据。

仍以前述例子进行说明，如表1所示，针对该监控对象(即时通讯业务的A应用的请求数)而言，假设索引集合中存在的集合元素为地区，则对应于监控项组合(广东、电信、电脑)的IP聚合数据、以及对应于监控项组合(福建、电信、电脑)的IP聚合数据，便可进一步地聚合为该集合元素对应的索引聚合数据。

也就是说，针对监控对象在设定监控维度下的监控项而言，索引聚合实质是忽略集合元素所表示的监控维度或者监控维度组合，将其余监控维度下具有相同监控项组合的监控数据聚合。

例如，如图7所示，其示例性示出了索引聚合过程的流程图。

在上述实施例的作用下，实现了监控数据的预聚合以及分层存储，使得不同数据查询方式得以快速命中相应数据，尤其是命中集合元素时，能够有效地减少实际需要拉取的数据量，从而有利于提高数据查询速度，进而充分地保障数据监控的实时性。

关于数据的存储通常是为每一个数据开辟固定数据长度的存储块，例如，固定数据长度设置为数据的最大数据长度。随着数据上报方上报的监控对象的监控数据的条目数不断增加，数据监控方的存储压力也随之上涨，有限的存储区将难以满足现有业务的存储需求，此种情况下，往往需要删除存储时间最久的历史数据，以此来缓解数据监控方的存储压力。

本申请实施例中提供了一种可能的实现方式，基于动态数据长度的存储块实现数据的压缩存储。其中，待存储数据包括但不限于：监控对象对应于不同数据上报方的监控数据、监控对象的IP聚合数据、以及监控对象对应于集合元素的索引聚合数据。

具体地，如图8所示，待存储数据的压缩存储过程可以包括以下步骤：

步骤510，提取设定条目数的待存储数据，根据待存储数据的数据长度生成待存储数据对应的压缩标识。

其中，设定条目数，可以根据应用场景的实际需要灵活地调整，此处并未加以限定。例如，本实施例中，设定条目数为120条。假设数据上报方每间隔1分钟上报一条监控对象的监控数据，则提取该数据上报方2小时内上报的120条监控对象的监控数据作为待存储数据。

压缩标识，用于指示待存储数据的数据长度。

步骤530，将设定条目数的待压缩数据及其对应的压缩标识封装为压缩数据。

其中，压缩数据包括监控对象对应于不同数据上报方的第一压缩数据、监控对象的第二压缩数据、以及监控对象对应于集合元素的第三压缩数据。

例如，如图9a所示，示例性示出了压缩标识的数据结构。其中，压缩标识的数据长度以及每一个比特位的含义，可以根据应用场景的实际需要灵活地设置，在此并未加以限定。例如，本实施例中，该压缩标识的数据长度为1个字节。第一个比特位sign用于表示符号位。第二个至第五个比特位(即d1-d4)用于表示待压缩数据中整数部分的数据长度，例如，d1d2d3d4＝0100，用于表示待压缩数据中整数部分的数据长度为5字节。第六个至第七个比特位(即f1-f2)用于表示待压缩数据中浮点部分的数据长度。第八个比特位reserve用于表示保留位。

如图9b所示，示例性示出了压缩数据的数据结构。其中，1个字节的version区用于填充版本位，120个字节的bitmap区用于填充压缩标识(各字节由b_i表示)，数据长度不确定的数据区用于填充待压缩数据(各字节由d_i表示)。当然，version区和bitmap区的数据长度可以根据应用场景的实际需要灵活地调整，此处并非构成具体限定。由此可见，bitmap区存储了120个压缩标识b_i，数据区存储了120个待压缩数据d_i，每一个压缩标识b_i对应一个待压缩数据d_i，用于表示其所对应的待压缩数据d_i的数据长度，以此方式实现最大限度地利用有限的存储空间。

步骤550，将压缩数据存储至存储块，存储块的数据长度与压缩数据的数据长度相同。也就是说，存储块的数据长度，将随着压缩数据的数据长度的变化而变化，不会再出现压缩数据的数据长度过小难以填满存储块的现象，避免存储块浪费存储空间，有效地提高了每一个存储块的存储空间利用率。

如图9b所示，压缩数据＝版本区+bitmap区+数据区。

对应地，请参阅图10，本申请实施例中提供了一种可能的实现方式，，压缩数据的解压缩过程可以包括以下步骤：

步骤610，获取相应的压缩数据，从压缩数据中提取压缩标识。

其中，压缩数据包括监控对象对应于不同数据上报方的第一压缩数据、监控对象的第二压缩数据、以及监控对象对应于集合元素的第三压缩数据，监控项组合由设定监控维度下的监控项确定。

步骤630，根据压缩标识对压缩数据进行解压缩，得到相应数据。

其中，相应数据包括监控目标对应于数据上报方的监控数据、监控目标在设定监控维度下的监控项对应的IP聚合数据、以及集合元素对应的索引聚合数据。

在上述过程中，实现了数据的高效压缩和解压缩。

表2压缩效率对比

如表2所示，相较于现有技术(例如相对较优的zfp压缩技术)，压缩时间可由19.5秒降低至4.3秒，解压缩时间可由18.6秒降低至2.5秒，压缩比可由42％提高至66％。

如前所述，随着数据上报方上报的监控对象的监控数据的条目数不断增加，数据监控方的存储压力也随之上涨。为此，在一种可能的实现方式中，数据存储采用快慢速策略，实现数据的均衡落地。

一方面，设定时间段内的压缩数据存储至临时存储区。

其中，该设定时间段可以根据应用场景的实际需要灵活地调整，例如，该设定时间段为系统当前4小时。

另一方面，在压缩数据存储至临时存储区达到设定时间段，将该压缩数据同时存储至持久存储区。

其中，该设定时间段也可根据应用场景的实际需要利灵活地调整，例如，该设定时间段为2小时。

由此，不仅极大地缓解了数据监控方的存储压力，解决了海量数据无法直接落地的问题，而且使得数据监控方的存储区具备一定的容灾能力，例如，机房异常时，2小时内的数据都不会丢失。

此外，基于数据存储的安全性策略，在一种可能的实现方式中，数据存储采用主备存储的方式实现。也就是说，压缩数据不仅存储于主存储区，同时存储于备份存储区。

例如，如图11所示，其示例性示出了主备存储的示意图。具体地，SET-1作为主存储区，在工作状态处于正常状态时，负责缓存压缩数据(写请求)以及压缩数据落地(CTDB)，同时对外提供压缩数据的读服务(读请求)。

当SET-1自身工作状态处于异常状态，例如异常重启或者扩容时，SET-2作为备份存储区，与SET-1自动进行同步，数据同步期间，SET-1不再对外提供压缩数据的读服务，由SET-2对外承接压缩数据的读服务。

此外，正常同步期间，采取增量同步，即将区别于SET-1的增量数据存储至SET-2，也可以认为是新写入数据存储至SET-2；异常同步期间，采取全量同步，即将SET-1中存储的全部数据存储至SET-2，避免因SET-1异常而导致写数据出错，以此充分地保障了数据存储的安全性。

对应地，请参阅图12，本申请实施例中提供了一种可能的实现方式，压缩数据的获取过程可以包括以下步骤：

步骤611，根据数据监控请求确定请求进行数据监控的时间段。

在确定该时间段之后，便进行该时间段与设定时间范围之间的比较。

其中，设定时间范围可以根据应用场景的实际需要灵活地调整，例如，本实施例中，设定时间范围为4小时。

如果时间段在设定时间范围之外，表示压缩数据已从临时存储区同步存储至持久化存储区，则执行步骤613。

反之，如果时间段在设定时间范围之内，表示压缩数据仍存储于临时存储区，尚未同步至持久化存储区，则执行步骤615。

步骤613，从持久存储区的存储块中拉取相应的压缩数据。

步骤615，从临时存储区的存储块中拉取相应的压缩数据。

其中，临时存储区包括主存储区和备份存储区。

也就是说，主存储区和备份存储区作为主备存储区，实现压缩数据的主备存储。例如，以备份存储区作为备份临时存储区。

那么，当主存储区中不存在相应的压缩数据，或者，主存储区的工作状态处于异常状态，则从备份临时存储区的存储块中拉取相应的压缩数据。

本申请实施例中提供了一种可能的实现方式，步骤410之后，该方法还可以包括以下步骤：

步骤420，监测监控对象的监控数据的监控项组合数，并根据监测结果对索引集合进行相应处理。

如前所述，一旦监控项组合数过多，便有可能导致数据监控过程中出现数据维度爆炸的现象。因此，监测，实质是数据监控方定时巡检该监控数据的监控项组合数。如果监控项组合数过多，一方面，如果索引集合中不存在集合元素，对该监控数据符合的监控维度进行分析，以从中选取监控维度作为新的集合元素，添加至索引集合；另一方面，如果索引集合中存在集合元素，则对该监控数据剩余的监控维度进行分析，以从中选取监控维度更新该集合元素。

具体地，在一种可能的实现方式，如图13所示，步骤420可以包括以下步骤：

步骤421，如果索引集合中存在集合元素，则根据集合元素确定监控对象的监控数据的第一监控项组合，并监测第一监控项组合的数目。

步骤423，当第一监控项组合的数目超过第一阈值，根据第一监控项组合所在的监控维度选取监控维度。

其中，第一阈值可以根据应用场景的实际需要灵活地设置，此处并未加以限定。

步骤425，根据选取到的监控维度更新集合元素。

举例来说，如表1所示，假设索引集合为{{地区}、其余集合元素}，该索引集合中存在集合元素地区，该集合元素地区用于表示监控对象(即时通讯业务的A应用的请求数)存在索引聚合数据的监控维度为地区维度。

则，根据该集合元素地区确定该监控对象的监控数据包括序号1至序号7的监控数据，同时确定第一监控项组合所在的监控维度包括：运营商维度和设备类型维度。在此说明的是，对于相同条目数的监控数据来说，考虑IP地址的唯一性，并不会使得该监控数据的监控项组合数随着监控维度的变化而变化，故IP地址维度在本实施例中不参与监控项组合数的监测。

也就是说，第一监控项组合所在的监控维度，是从监控数据符合的监控维度中排除集合元素表示的监控维度之后剩余的监控维度。这种情况下，如果剩余监控维度下的监控项组合数目仍然过大，便考虑选取新的一个监控维度更新集合元素，以此方式提高数据查询速度。

那么，基于参与监控项组合数监测的运营商维度和设备类型维度，如表1所示，序号1、序号2和序号5的监控数据具有相同的监控项组合，序号6和序号7的监控数据具有相同的监控项组合，其余序号(3、4)的监控数据的监控项组合各不相同，因此，序号1至序号7的监控数据的第一监控项组合的数目为4，分别包括：电信电脑、电信手机、移动电脑、联通手机。

如果该第一监控项组合的数目超过第一阈值，便从运营维度和设备类型维度中选取监控维度更新集合元素地区。

在一种可能的实现方式，如图14所示，步骤420可以包括以下步骤：

步骤422，如果索引集合中不存在集合元素，则确定监控对象的监控数据的第二监控项组合，并监测第二监控项组合的数目。

步骤424，当第二监控项组合的数目超过第二阈值，根据第二监控项组合所在的监控维度选取监控维度。

其中，第二阈值可以根据应用场景的实际需要灵活地设置，此处并未加以限定。

步骤426，将选取到的监控维度作为新的集合元素，添加至索引集合。

举例来说，如表1所示，假设索引集合中不存在集合元素，则确定监控对象(即时通讯业务的A应用的请求数)的监控数据包括序号1至序号7的监控数据，同时确定第二监控项组合所在的监控维度包括：地区维度、运营商维度和设备类型维度。同理，IP地址维度在本实施例中不参与监控项组合数的监测。

也就是说，第二监控项组合所在的监控维度，即为监控数据符合的监控维度。这种情况下，如果监控维度下的监控项组合数目过大，便考虑选取新的一个监控维度作为集合元素，以此方式提高数据查询速度。

那么，基于参与监控项组合数监测的地区维度、运营商维度和设备类型维度，如表1所示，序号1和序号2的监控数据具有相同的监控项组合，其余序号(3-7)的监控数据的监控项组合各不相同，因此，序号1至序号7的监控数据的第二监控项组合的数目为6，分别包括：广东电信电脑、广东移动电脑、广东联通手机、福建电信电脑、福建电信手机、海南电信手机。

如果该第二监控项组合的数目超过第二阈值，便从地区维度、运营维度和设备类型维度中选取监控维度更新索引集合。

应当理解，无论是从第一监控项组合所在的监控维度中选取监控维度，还是从第二监控项组合所在的监控维度中选取监控维度，选取监控维度的原理是一致的，区别仅在于监控维度的选取来源是第一监控项组合所在的监控维度还是第二监控项组合所在的监控维度。

下面对根据输入监控项组合所在的监控维度选取监控维度的过程进行详细地说明。

其中，输入监控项组合包括第一监控项组合以及第二监控项组合，相应地，输入监控项组合所在的监控维度包括第一监控项组合所在的监控维度和第二监控项组合所在的监控维度。

请参阅图15，本申请实施例中提供了一种可能的实现方式，选取监控项的过程，可以包括以下步骤：

步骤510，对输入监控项组合所在的监控维度进行遍历，从所有监控维度中，选取排除遍历到的监控维度的剩余监控维度，作为统计维度。

步骤530，确定统计维度下的监控项组合的数目，作为遍历到的监控维度的统计值。

步骤550，选取统计值最小的监控维度。

一方面，以索引集合中存在集合元素地区为例说明监控维度的选取过程。

此时，输入监控项组合包括：电信电脑、电信手机、移动电脑、联通手机，相应地，该输入监控项组合所在的监控维度包括：运营商维度和设备类型维度。

那么，对于运营商维度而言，统计维度即是设备类型维度，该统计维度下的监控项组合包括电脑和手机，也就是说，运营商维度的统计值为2。

同理，对于设备类型维度而言，统计维度即是运营商维度，该统计维度下的监控项组合包括电信、联通和移动，也就是说，设备类型维度的统计值为3。

由此，选取运营商维度更新集合元素地区，即集合元素更新为地区+运营商，用于表示监控对象存在对应索引聚合数据的监控维度组合为地区维度和运营商维度，相应地，索引集合由{{地区}、其余集合元素}更新为{{地区、运营商}、其余集合元素}。

另一方面，以索引集合中不存在集合元素为例说明监控维度的选取过程。

此时，输入监控项组合包括：广东电信电脑、广东移动电脑、广东联通手机、福建电信电脑、福建电信手机、海南电信手机，相应地，该输入监控项组合所在的监控维度包括：地区维度、运营商维度和设备类型维度。

那么，对于地区维度而言，统计维度为运营商维度和设备类型维度，该统计维度下的监控项组合包括电信电脑、电信手机、移动电脑、联通手机，也就是说，地区维度的统计值为4。

对于运营商维度而言，统计维度包括地区维度和设备类型维度，该统计维度下的监控项组合包括广东电脑、广东手机、福建电脑、福建手机、海南手机，也就是说，运营商维度的统计值为5。

同理，对于设备类型维度而言，统计维度包括地区维度和运营商维度，该统计维度下的监控项组合包括广东电信、广东移动、广东联通、福建电信、海南电信，也就是说，设备类型维度的统计值也为5。

由此，选取地区维度更新索引集合，即索引集合更新为{{地区}}，该索引集合中的集合元素地区，用于表示监控对象存在对应索引聚合数据的监控维度为地区维度。

通过上述实施例的配合，实现索引集合的构建和更新，以此作为索引聚合的依据，使得监控数据的预聚合得以实现，进而有利于提高数据查询速度，从而有利于满足现有业务对数据实时性的要求。

请参阅图16，其示例性示出了监控目标的监控结果的生成过程的流程图。

如图16a所示，本申请实施例中提供了一种可能的实现方式，步骤370可以包括以下步骤：

步骤371，按照监控目标的聚合规则，将查询到的符合不同监控项组合的数据进行聚合，得到监控目标的细粒度数据。

以查询到的数据为监控目标的IP聚合数据为例进行说明，如图16b所示，其示例性示出了数据聚合的示意图。在该示意图中，各节点表示数据，各节点的层级关系遵循至下而上逐层向上汇聚的原则。

假设监控目标为即时通讯业务的A应用的请求数，对应地，该监控目标的聚合规则为求和。

首先，最底层的若干个节点，例如J节点和K节点，该J节点对应的监控项组合包括广东、电信、电脑、IP1，该K节点对应的监控项组合包括广东、电信、手机、IP2，先各自经过IP聚合分别形成节点F和节点G，即监控目标的IP聚合数据，也即是查询到的数据。

其次，倒数第二层的若干个节点，例如F节点和G节点，该F节点对应的监控项组合包括广东、电信、电脑，该G节点对应的监控项组合包括广东、电信、手机，该两个符合不同监控项组合的节点聚合形成节点C，该节点C对应的监控项组合包括广东、电信；同理，符合不同监控项组合的H节点和I节点聚合形成节点E，该节点E对应的监控项组合包括广东、移动。

再次，倒数第三层的若干个节点，例如C节点和E节点，该两个符合不同监控项组合的节点聚合形成节点A，该节点A对应的监控项组合包括广东；同理，由倒数第三层的其余若干个符合不同监控项组合的节点聚合形成节点A’，该节点A’对应的监控项组合包括福建。

最后，符合不同监控项组合的节点A和节点A’经过聚合，得到监控目标的细粒度数据。例如，监控目标在18:00的细粒度数据，亦即即时通讯业务的A应用在18:00的请求总数。

步骤373，根据设定时间粒度，对监控目标的细粒度数据进行聚合，得到监控目标的监控结果。

基于设定时间粒度的聚合，由监控目标的细粒度数据得到监控目标的粗粒度数据。其中，设定时间粒度可以根据应用场景的实际需要灵活地设置，此处不加以限定。

例如，本实施例中，设定时间粒度为5分钟，也就是说，5分钟之内的监控目标的细粒度数据进行聚合，譬如，将监控目标分别在18:00、18:01、18:02、18:03、18:04的细粒度数据聚合形成该监控目标的粗粒度数据，亦即是即时通讯业务的A应用在18:00～18:04的请求总数。同理，根据监控人员指定查询的时间段，例如，18:00～20:00，便可得到即时通讯业务的A应用在18:00～20:00的请求总数。

一方面，如果监控目标为单一型监控对象，则监控目标的粗粒度数据即为监控目标的监控结果。

例如，监控目标为即时通讯业务的A应用的请求数，视为单一型监控对象，那么，即时通讯业务的A应用在18:00～20:00的请求总数可视为该监控目标的监控结果。

另一方面，监控目标为若干个单一型监控对象构成的复合型监控对象。那么，在基于设定时间粒度聚合之后，还需要根据监控目标的聚合规则进行聚合方可得到监控目标的监控结果。

具体地，如图17所示，在一种可能的实现方式，步骤373可以包括以下步骤：

步骤3731，针对每一个单一型监控对象，根据设定时间粒度，对单一型监控对象的细粒度数据进行聚合，得到单一型监控对象的粗粒度数据。

步骤3733，按照监控目标的聚合规则对各单一型监控对象的粗粒度数据进行聚合，得到监控目标的监控结果。

例如，监控目标为即时通讯业务的A应用的成功率，视为复合型监控对象，由单一型监控对象构成，该单一型监控对象包括即时通讯业务的A应用的请求数和请求成功数。

那么，即时通讯业务的A应用在18:00～20:00的请求成功总数/请求总数可视为该监控目标的监控结果。

由此，数据监控方即完成数据监控服务，对于请求发起方而言，便可在监控界面中向监控人员展示监控目标的监控结果，实现数据监控的可视化，有利于提升用户体验。

图18是一应用场景中一种数据监控方法的实现示意图。

该应用场景中，如图18a所示，其示例性示出了一种数据监控方法的系统架构图。该系统用于数据监控方法的系统包括六个模块：流式计算模块801、维度分析模块802、数据查询模块803、缓存模块804、数据库模块805、以及Tag数据存储模块806。

下面介绍上述各个模块在数据监控方法中实现的功能：

流式计算模块801：

利用系统部署的中间件kafka，对接收到的各数据上报方上报的关于各监控对象的监控数据进行预聚合，该预聚合包括IP聚合和索引聚合。

一方面，对接收到的监控数据按照相同监控项组合进行聚合，得到监控对象对应于监控项组合的IP聚合数据。

回请参阅图6所示，IP聚合过程可以包括以下流程：

1)从中间件kafka中消费实时的监控数据输入到处理算子InsConvert中，通用flink广播流将从数据库DB中读取的配置流输入到处理算子InsConvert中，与中间件kafka实时消费的数据流联合形成实例数据，利用处理算子InsConvert将实例数据转换为缓存模块Cache可识别的单机数据，并存储至缓存模块Cache，形成监控对象对应于不同数据上报方的监控数据。

同时，将转换后的实例数据通过flink广播流流向下一个处理算子ConvertFlatmap。

2)利用处理算子ConvertFlatmap按照相同监控项组合的数目将转换后的实例数据扁平化，保证扁平化后的每一条数据只包含单个转换后的实例数据，将扁平化后的每一条数据按照监控对象+监控项组合路由输出至下一个处理算子BaseWindow中，路由的目的是将相同监控对象相同监控项组合(忽略IP维度下的监控项)的数据放在该处理算子BaseWindow的同一个线程task中计算，以利于实现IP聚合。

3)在将扁平化后的每一条数据路由至下一个处理算子BaseWindow之前，可通过定时器HeartbeatTimer向下游发送心跳数据来推进flink watermark水位线，以此方式来解决数据延迟或提前路由而使得水位线提前导致的数据丢弃问题，避免因数据丢弃造成IP聚合不准确的问题。

4)同时，利用定时触发窗口计算的方式，能够有效地解决处理算子BaseWindow中只有一条数据或者只剩下最后一条数据不聚合的问题。

5)上游将相同监控对象相同监控项组合的数据发送到处理算子BaseWindow、处理算子SplitConvert的同一个线程task中，task会根据监控对象的聚合规则，将最细粒度(例如一分钟)的监控数据进行求和、求最大、求最小、求平均等汇聚计算，并将计算得到的数据输出到缓存模块Cache中，从而实现数据的IP聚合，得到监控对象的IP聚合数据。

另一方面，根据索引集合中的集合元素，对监控对象的IP聚合数据进行聚合，得到监控对象对应于集合元素的索引聚合数据。

回请参阅图7所示，索引聚合过程可以包括以下流程：

1)将上游处理算子BaseWindow输出的IP聚合数据，通过flink广播流流向下一个处理算子ConvertFlatmap。

2)利用处理算子ConvertFlatmap，按照集合元素所表示监控维度下的监控项组合将IP聚合数据扁平化，保证扁平化后的每一条数据只包含单个IP聚合数据，将扁平化后的每一条数据按照监控对象+监控项组合路由输出至下一个处理算子AggWindow，路由的目的是将相同监控对象相同监控项组合(忽略集合元素所表示监控维度下的监控项)的数据放在该处理算子AggWindow的同一个线程task中计算，以利于实现索引聚合。

3)上游将相同监控对象相同监控项组合的数据依次发送到处理算子AggWindow、处理算子SplitConvert的同一个线程task中，task会根据监控对象的聚合规则，将最细粒度(例如一分钟)的IP聚合数据进行求和、求最大、求最小、求平均等汇聚计算，并将计算得到的数据输出到缓存模块Cache中，从而实现数据的索引聚合，得到监控对象对应于集合元素的索引聚合数据。

维度分析模块802：

针对数据上报方上报的监控数据，定时巡检该监控数据在所符合的监控维度下的监控项组合数，一旦发现监控项组合数过大，可能导致数据监控过程中出现数据维度爆炸，便选取监控维度对索引集合进行相应处理。

具体地：一方面，如果索引集合中存在集合元素，则监测第一监控项组合的数目，一旦该数目超过阈值，便根据第一监控项组合所在的监控维度选取监控维度，以根据选取到的监控维度更新集合元素。

另一方面，如果索引集合中不存在集合元素，则监测第二监控项组合的数目，一旦该数目超过阈值，便根据第二监控项组合所在的监控维度选取监控维度，以根据选取到的监控维度更新索引集合。

由此，随着监控数据的监控项组合数的变化，索引集合能够得到实时更新，使得即使是新写入的监控数据，系统也能够做到秒级实时查询响应。

此外，如图18b所示，随着监控人员选择/输入而发起即席查询时，基于监控目标在设定监控维度下的监控项，当数据查询方式为非单机查询时，维度分析模块802还需要根据设定监控维度在索引集合中搜索匹配的集合元素，如果匹配到集合元素，则通知数据查询模块803实现该集合元素对应的索引聚合数据的快速查询，否则，如果未匹配到集合元素，则通知数据查询803实现监控目标的IP聚合数据的快速查询。

数据查询模块803：

针对需要拉取的数据量不同，确定数据查询方式，并按照数据查询方式查询相应的数据。

具体地：如图18c所示，数据查询方式为单机查询时，查询原始未聚合的监控数据；数据查询方式为非单机查询时，如果未命中索引集合中的集合元素，查询经过IP聚合的IP聚合数据；数据查询方式为非单机查询时，如果命中索引集合中的集合元素，查询经过索引聚合的索引聚合数据。

这种方式能够有效地降低实际需要拉取的数据量，有利于提高数据查询速度，避免了数据监控过程中出现数据维度爆炸的现象，能够很好地满足现有业务对数据监控的实时性要求。

此外，查询过程中，如果查询到的数据是系统当前4小时的数据，从缓存模块804中拉取最新数据，如果查询到的数据是超过系统当前4小时的数据，则从数据库模块805中拉取历史数据。

缓存模块804：

该缓存模块804，用于存储系统当前4小时的数据，该数据包括监控对象对应于不同数据上报方的监控数据、监控对象的IP聚合数据、以及监控对象对应于集合元素的索引聚合数据。

由此，不仅极大地缓解了数据监控方的存储压力，解决了海量数据无法直接落地的问题，而且使得数据监控方的存储区具备一定的容灾能力，例如，机房异常时，2小时内的数据都不会丢失。

本应用场景中，缓存模块804可对接后端多种类型的存储介质，包括但不限于：CES、TDSQL、CTDB、ES、TDSQL、OpenTSDB、Druid等，使得该缓存模块Cache能够最大化地降低对后端存储的并发读和写的要求。

数据库模块805：

当数据存储于缓存模块Cache达到2小时，便由该缓存模块804中存储至数据库模块805，以此方式实现数据均衡落地。

Tag数据存储模块806：

为了便于数据库模块805中的数据存储和查询，本应用场景中，数据存储和查询基于key-value方式实现。

具体地：根据数据上报方上报的监控数据确定监控维度下的监控项，根据所确定的监控维度下的监控项生成tag数据，以该tag数据作为键key，并以对应的监控数据作为键值value。

如表1所示，序号1的监控数据，键key＝tag数据＝(即时通讯业务、A应用、请求数、广东、电信、电脑、192.168.125.10)，对应地，键值value＝(即时通讯业务、A应用、请求数、广东、电信、电脑、192.168.125.10、10/min)。

那么，Tag数据存储模块，用于存储tag数据。

由此，数据查询过程中，基于键key与键值value之间的对应关系，便可根据Tag数据存储模块806中存储的tag数据在缓存模块804/数据库模块805中快速精准地在定位并查找到对应的数据。

此外，如图18d所示，不管是tag数据还是数据，能够实现区间自适应并发，即系统当前4小时的tag数据及其对应的数据同时全量/增量存储至缓存模块804，当存储时间达到2小时，该tag数据及其对应的数据同时存储至数据库模块805，以此最大限度地降低对后端存储介质的要求，最大限度地保障数据安全性。

在此说明的是，对于缓存模块804/数据库模块805来说，实质存储的键值value是经过压缩的压缩数据，例如，该压缩数据包括监控对象对应于不同数据上报方的第一压缩数据、监控对象的第二压缩数据、以及监控对象对应于集合元素的第三压缩数据。

上述数据监控过程中，压缩数据可存储至区块链网络中，以利用区块链网络中数据具有不可篡改的特性，来充分地保证压缩数据的真实性和可信度。

随着压缩数据生成，数据监控方将该压缩数据发送至区块链网络中的任意一个节点，例如，该任意一个节点与数据监控方之间的物理距离最近。

对应地，在区块链网络中，该任意一个节点将获取到数据监控方发送的该压缩数据，并为该压缩数据分配相同数据长度的存储块(区块)进行存储，使得该压缩数据可由此节点同步至区块链网络中的其余节点中，以便于提供去中心化的压缩数据共享服务。

下面对本应用场景所涉及的区块链网络进行如下说明：

参见图19a所示的区块链网络，区块链网络是指用于进行节点与节点之间数据共享的系统，该区块链网络中可以包括多个节点101，多个节点101可以是指区块链网络中各个客户端。每个节点101在进行正常工作可以接收到输入信息，并基于接收到的输入信息维护该区块链网络内的共享数据。为了保证区块链网络内的信息互通，区块链网络中的每个节点之间可以存在信息连接，节点之间可以通过上述信息连接进行信息传输。例如，当区块链网络中的任意节点接收到输入信息时，区块链网络中的其他节点便根据共识算法获取该输入信息，将该输入信息作为共享数据中的数据进行存储，使得区块链网络中全部节点上存储的数据均一致。

对于区块链网络中的每个节点，均具有与其对应的节点标识，而且区块链网络中的每个节点均可以存储有区块链网络中其他节点的节点标识，以便后续根据其他节点的节点标识，将生成的区块广播至区块链网络中的其他节点。每个节点中可维护一个如下表所示的节点标识列表，将节点名称和节点标识对应存储至该节点标识列表中。其中，节点标识可为IP(Internet Protocol，网络之间互联的协议)地址以及其他任一种能够用于标识该节点的信息，表1中仅以IP地址为例进行说明。

表1

节点名称	节点标识
		节点1	117.114.151.174
节点2	117.116.189.145
		…	…
节点N	119.123.789.258

区块链网络中的每个节点均存储一条相同的区块链。区块链由多个区块组成，参见图19b，区块链由多个区块组成，创始块中包括区块头和区块主体，区块头中存储有输入信息特征值、版本号、时间戳和难度值，区块主体中存储有输入信息；创始块的下一区块以创始块为父区块，下一区块中同样包括区块头和区块主体，区块头中存储有当前区块的输入信息特征值、父区块的区块头特征值、版本号、时间戳和难度值，并以此类推，使得区块链中每个区块中存储的区块数据均与父区块中存储的区块数据存在关联，保证了区块中输入信息的安全性。

在生成区块链中的各个区块时，参见图19c，区块链所在的节点在接收到输入信息时，对输入信息进行校验，完成校验后，将输入信息存储至内存池中，并更新其用于记录输入信息的哈希树；之后，将更新时间戳更新为接收到输入信息的时间，并尝试不同的随机数，多次进行特征值计算，使得计算得到的特征值可以满足下述公式：

SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x))<TARGET

其中，SHA256为计算特征值所用的特征值算法；version(版本号)为区块链中相关区块协议的版本信息；prev_hash为当前区块的父区块的区块头特征值；merkle_root为输入信息的特征值；ntime为更新时间戳的更新时间；nbits为当前难度，在一段时间内为定值，并在超出固定时间段后再次进行确定；x为随机数；TARGET为特征值阈值，该特征值阈值可以根据nbits确定得到。

这样，当计算得到满足上述公式的随机数时，便可将信息对应存储，生成区块头和区块主体，得到当前区块。随后，区块链所在节点根据区块链网络中其他节点的节点标识，将新生成的区块分别发送给其所在的区块链网络中的其他节点，由其他节点对新生成的区块进行校验，并在完成校验后将新生成的区块添加至其存储的区块链中。

综上所述，该系统可支持热点字段(例如地区、运营商等)相关数据的快速查询，可以真正做到水平扩展。同时，该系统支持实时写入，实时查询，可以应对高并发、低延迟的查询要求、支持单机房写入、多机房聚合查询、支持维度上卷和下钻分析。此外，该系统可支持多副本，副本数可指定，只要仍有一个副本存活就能够保证正常提供数据监控服务，充分地保障了系统的安全性和可靠性。

在一实际应用中，该系统的接入量在5亿/min、缓存总量达到将了10亿/min。即使数据写入达到了毫秒级，通过tag数据的写入以及维度分析，使得新数据在读的过程中能够及时地纳入读请求，保证数据精准，进而使得实时查询的性能也能够达到近毫秒级。同时，该系统的容量能够在机器资源累加的情况下得到线性的容量涨幅，从而有效地解决特性ID带来的一系列限容问题。目前，接入到该系统的CDN、直播等业务，在业务变更中上报的监控数据，都能够及时地查询而实现可视化展示以及纳入到监控告警中，从而有效地保障了现网业务在变更过程中的正常运行。

下述为本申请装置实施例，可以用于执行本申请所涉及的数据监控方法。对于本申请装置实施例中未披露的细节，请参照本申请所涉及的数据监控方法的方法实施例。

请参阅图20，本申请实施例中提供了一种数据监控装置900，包括但不限于：数据请求接收模块910、查询方式确定模块930、数据查询模块950、以及监控结果返回模块970。

其中，数据请求接收模块910，用于接收数据监控请求，数据监控请求用于指示监控目标在设定监控维度下的监控项。

查询方式确定模块930，用于根据监控目标在设定监控维度下的监控项，确定数据查询方式。

数据查询模块950，用于按照数据查询方式查询数据，包括：在数据查询方式为非单机查询时，根据查询属性为全部查询的设定监控维度在索引集合中搜索匹配的集合元素，并根据匹配到的集合元素查询对应的索引聚合数据，集合元素用于表示监控对象存在对应索引聚合数据的监控维度或者监控维度组合。

监控结果返回模块970，用于对查询到的数据进行相应处理，得到监控目标的监控结果，并返回监控目标的监控结果。

需要说明的是，上述实施例所提供的数据监控装置在进行数据监控时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即数据监控装置的内部结构将划分为不同的功能模块，以完成以上描述的全部或者部分功能。

另外，上述实施例所提供的数据监控装置与数据监控方法的实施例属于同一构思，其中各个模块执行操作的具体方式已经在方法实施例中进行了详细描述，此处不再赘述。

由此，通过提前存储监控对象的监控维度或者监控维度组合对应的索引聚合数据，在数据监控时，如果查询属性为全部查询的设定监控维度能够命中存在对应索引聚合数据的监控维度或者监控维度组合，便能够直接拉取提前存储的索引聚合数据进行数据监控，以此方式有效地降低实际需要拉取的数据量，极大地提高了数据查询速度，从而能够有效地解决现有技术中存在的数据监控的实时性较差的问题。

图21一示例性实施例示出的一种服务器的结构示意。该服务器适用于图1所示出实施环境的数据监控方200。

需要说明的是，该服务器只是一个适配于本申请的示例，不能认为是提供了对本申请的使用范围的任何限制。该服务器也不能解释为需要依赖于或者必须具有图21的示例性的服务器2000中的一个或者多个组件。

服务器2000的硬件结构可因配置或者性能的不同而产生较大的差异，如图21，服务器2000包括：电源210、接口230、至少一存储器250、以及至少一中央处理器(CPU,CentralProcessing Units)270。

具体地，电源210用于为服务器2000上的各硬件设备提供工作电压。

接口230包括至少一有线或无线网络接口，用于与外部设备交互。例如，进行图1所示出实施环境中数据上报方100与数据监控方200之间的交互。

当然，在其余本申请适配的示例中，接口230还可以进一步包括至少一串并转换接口233、至少一输入输出接口235以及至少一USB接口237等，如图21，在此并非对此构成具体限定。

存储器250作为资源存储的载体，可以是只读存储器、随机存储器、磁盘或者光盘等，其上所存储的资源包括操作系统251、应用程序253及数据255等，存储方式可以是短暂存储或者永久存储。

其中，操作系统251用于管理与控制服务器200上的各硬件设备以及应用程序253，以实现中央处理器270对存储器250中海量数据255的运算与处理，其可以是WindowsServerTM、Mac OS XTM、UnixTM、LinuxTM、FreeBSDTM等。

应用程序253是基于操作系统251之上完成至少一项特定工作的计算机程序，其可以包括至少一模块(图20未示出)，每个模块都可以分别包含有对服务器2000的一系列计算机可读指令。例如，数据监控装置可视为部署于服务器2000的应用程序253。

数据255可以是存储于磁盘中的照片、图片等，还可以是监控数据、聚合数据等，存储于存储器250中。

中央处理器270可以包括一个或多个以上的处理器，并设置为通过至少一通信总线与存储器250通信，以读取存储器250中存储的计算机可读指令，进而实现对存储器250中海量数据255的运算与处理。例如，通过中央处理器270读取存储器250中存储的一系列计算机可读指令的形式来完成数据监控方法。

此外，通过硬件电路或者硬件电路结合软件也能同样实现本申请，因此，实现本申请并不限于任何特定硬件电路、软件以及两者的组合。

请参阅图22，本申请实施例中提供了一种电子设备4000，该电子设备4000可以是服务器等。

该电子设备4000包括至少一个处理器4001、至少一条通信总线4002以及至少一个存储器4003。

其中，处理器4001和存储器4003相连，如通过通信总线4002相连。可选地，电子设备4000还可以包括收发器4004，收发器4004可以用于该电子设备与其他电子设备之间的数据交互，如数据的发送和/或数据的接收等。需要说明的是，实际应用中收发器4004不限于一个，该电子设备4000的结构并不构成对本申请实施例的限定。

处理器4001可以是CPU(Central Processing Unit，中央处理器)，通用处理器，DSP(Digital Signal Processor，数据信号处理器)，ASIC(Application SpecificIntegrated Circuit，专用集成电路)，FPGA(Field Programmable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器4001也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

通信总线4002可包括一通路，在上述组件之间传送信息。通信总线4002可以是PCI(Peripheral Component Interconnect，外设部件互连标准)总线或EISA(ExtendedIndustry Standard Architecture，扩展工业标准结构)总线等。通信总线4002可以分为地址总线、数据总线、控制总线等。为便于表示，图22中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器4003可以是ROM(Read Only Memory，只读存储器)或可存储静态信息和指令的其他类型的静态存储设备，RAM(Random Access Memory，随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory，电可擦可编程只读存储器)、CD-ROM(Compact DiscRead Only Memory，只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

存储器4003上存储有计算机可读指令，处理器4001通过通信总线4002读取存储器4003中存储的计算机可读指令。

该计算机可读指令被处理器4001执行时实现上述各实施例中的数据监控方法。

此外，本申请实施例中提供了一种存储介质，该存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述各实施例中的数据监控方法。

本申请实施例中提供了一种计算机程序产品，该计算机程序产品包括计算机可读指令，该计算机可读指令存储在存储介质中。计算机设备的处理器从存储介质读取该计算机可读指令，处理器执行该计算机可读指令，使得该计算机设备执行上述各实施例中的数据监控方法。

与现有技术相比，通过提前存储监控对象的监控维度或者监控维度组合对应的索引聚合数据，在数据监控时，如果设定监控维度能够命中存在对应索引聚合数据的监控维度或者监控维度组合，便能够直接查询并拉取提前存储的索引聚合数据进行数据监控，以此方式有效地降低实际需要拉取的数据量，极大地提高了数据查询速度，从而能够有效地解决现有技术中存在的数据监控的实时性较差的问题。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

以上所述仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (15)

1.一种数据监控方法，其特征在于，包括：

接收数据监控请求，所述数据监控请求指示有监控目标在设定监控维度下的监控项；

根据所述监控目标在设定监控维度下的监控项，确定数据查询方式；

按照所述数据查询方式查询数据，包括：在所述数据查询方式为非单机查询时，根据设定监控维度在索引集合中搜索匹配的集合元素，并根据匹配到的集合元素查询对应的索引聚合数据，所述集合元素用于表示监控对象存在对应索引聚合数据的监控维度或者监控维度组合；

对查询到的数据进行相应处理，得到所述监控目标的监控结果，并返回所述监控目标的监控结果。

2.如权利要求1所述的方法，其特征在于，所述方法还包括：

接收数据上报方上报的所述监控对象的监控数据；

存储接收到的监控数据，以形成所述监控对象对应于不同数据上报方的监控数据；

按照所述监控对象的聚合规则，对接收到的监控数据进行聚合，得到所述监控对象的聚合数据，存储所述监控对象的聚合数据，所述聚合数据包括IP聚合数据和索引聚合数据。

3.如权利要求2所述的方法，其特征在于，所述按照所述监控对象的聚合规则，对接收到的监控数据进行聚合，得到所述监控对象的聚合数据，包括：

对所述监控对象对应于不同数据上报方的监控数据按照相同监控项组合进行聚合，得到所述监控对象的IP聚合数据；

根据所述索引集合中的集合元素，对所述监控对象的IP聚合数据进行聚合，得到所述监控对象对应于所述集合元素的索引聚合数据。

4.如权利要求2或3所述的方法，其特征在于，存储所述监控数据、所述IP聚合数据、以及所述索引聚合数据的方式，包括：

提取设定条目数的待存储数据，根据所述待压缩数据的数据长度生成所述待压缩数据对应的压缩标识；

将设定条目数的所述待压缩数据及其对应的压缩标识封装为压缩数据，所述压缩数据包括对应于所述监控数据的第一压缩数据、对应于所述IP聚合数据的第二压缩数据、以及对应于所述索引聚合数据的第三压缩数据；

将所述压缩数据存储至存储块，所述存储块的数据长度与所述压缩数据的数据长度相同。

5.如权利要求2所述的方法，其特征在于，所述接收数据上报方上报的所述监控对象的监控数据之后，所述方法还包括：

监测所述监控对象的监控数据的监控项组合数，并根据监测结果对所述索引集合进行相应处理。

6.如权利要求5所述的方法，其特征在于，所述监测所述监控对象的监控数据的监控项组合数，并根据监测结果对所述索引集合进行相应处理，包括：

如果所述索引集合中存在所述集合元素，则根据所述集合元素确定所述监控对象的监控数据的第一监控项组合，并监测所述第一监控项组合的数目；

当所述第一监控项组合的数目超过第一阈值，根据所述第一监控项组合所在的监控维度选取监控维度；

根据选取到的监控维度更新所述集合元素。

7.如权利要求5所述的方法，其特征在于，所述监测所述监控对象的监控数据的监控项组合数，并根据监测结果对所述索引集合进行相应处理，包括：

如果所述索引集合中不存在所述集合元素，则确定所述监控对象的监控数据的第二监控项组合，并监测所述第二监控项组合的数目；

当所述第二监控项组合的数目超过第二阈值，根据所述第二监控项组合所在的监控维度选取监控维度；

将选取到的监控维度作为新的集合元素，添加至所述索引集合。

8.如权利要求6或7所述的方法，其特征在于，输入监控项组合包括第一监控项组合以及第二监控项组合；

所述选取监控维度，包括：

对所述输入监控项组合所在的监控维度进行遍历，从所有监控维度中，选取排除遍历到的监控维度的剩余监控维度，作为统计维度；

确定所述统计维度下的监控项组合的数目，作为遍历到的监控维度的统计值；

选取统计值最小的监控维度。

9.如权利要求1所述的方法，其特征在于，所述根据所述监控目标在设定监控维度下的监控项，确定数据查询方式，包括：

如果所述监控项包括数据上报方的IP地址，则确定所述数据查询方式为单机查询；

否则，确定所述数据查询方式为非单机查询。

10.如权利要求9所述的方法，其特征在于，所述按照所述数据查询方式查询数据，还包括：

在所述数据查询方式为单机查询时，查询所述监控目标对应于所述数据上报方的监控数据；或者

在所述数据查询方式为非单机查询，并且根据设定监控维度在索引集合中未搜索到匹配的集合元素时，查询所述监控目标在设定监控维度下的监控项对应的IP聚合数据。

11.如权利要求1或10所述的方法，其特征在于，所述查询的方式，包括：

获取相应的压缩数据，从所述压缩数据中提取压缩标识，所述压缩数据包括所述监控对象对应于不同数据上报方的第一压缩数据、所述监控对象的第二压缩数据、以及所述监控对象对应于所述集合元素的第三压缩数据，所述监控项组合由所述设定监控维度下的所述监控项确定；

根据所述压缩标识对所述压缩数据进行解压缩，得到相应数据，所述相应数据包括所述监控目标对应于所述数据上报方的监控数据、所述监控目标在设定监控维度下的监控项对应的IP聚合数据、以及所述集合元素对应的索引聚合数据。

12.如权利要求11所述的方法，其特征在于，所述获取相应的压缩数据，包括：

根据所述数据监控请求确定请求进行数据监控的时间段；

如果所述时间段在设定时间范围之内，则从临时存储区的存储块中拉取相应的压缩数据；

否则，从持久存储区的存储块中拉取相应的压缩数据；

其中，所述临时存储区包括主存储区和备份存储区；

所述从临时存储区的存储块中拉取相应的压缩数据，包括：

当所述主存储区中不存在相应的压缩数据，或者，所述主存储区的工作状态处于异常状态，则从所述备份临时存储区的存储块中拉取相应的压缩数据。

13.如权利要求11所述的方法，其特征在于，所述按照所述数据查询方式查询数据之后，所述方法还包括：

确定查询到的数据对应的数据标识，根据所述数据标识对查询到的数据进行去重处理；

所述对查询到的数据进行相应处理，得到所述监控目标的监控结果，包括：

对去重处理后的数据进行相应处理，得到所述监控目标的监控结果。

14.如权利要求1所述的方法，其特征在于，所述对查询到的数据进行相应处理，得到所述监控目标的监控结果，包括：

按照所述监控目标的聚合规则，将查询到的符合不同监控项组合的数据进行聚合，得到所述监控目标的细粒度数据；

根据设定时间粒度，对所述监控目标的细粒度数据进行聚合，得到所述监控目标的监控结果。

15.如权利要求14所述的方法，其特征在于，所述监控目标为若干个单一型监控对象构成的复合型监控对象；

所述根据设定时间粒度，对所述监控目标的细粒度数据进行聚合，得到所述监控目标的监控结果，包括：

针对每一个所述单一型监控对象，根据设定时间粒度，对所述单一型监控对象的细粒度数据进行聚合，得到所述单一型监控对象的粗粒度数据；

按照所述监控目标的聚合规则对各所述单一型监控对象的粗粒度数据进行聚合，得到所述监控目标的监控结果。

Images