CN114860510B - 微服务系统的数据监控方法和系统 - Google Patents

Abstract

本申请提供一种微服务系统的数据监控方法和系统，应用于含存储节点和多个采集节点的数据监控系统，采集节点采集微服务系统的指标数据；每一指标数据均被至少两个采集节点采集；存储节点存储指标数据；存储节点响应查询请求，在存储的指标数据中查询指标数据。现有部分时序数据库（如Prometheus）重启后会向内存加载数据，导致一段时间不可用。本方案将指标数据的采集和存储分给不同节点，且采集节点有多个，既避免采集节点重启后加载数据，使采集节点重启后立即恢复采集，又使多个采集节点的数据互为备份，任一采集节点宕机不影响指标数据的完整，提高数据监控系统的可用性。

Description

微服务系统的数据监控方法和系统

技术领域

本发明涉及系统数据监控技术领域，特别涉及一种微服务系统的数据监控方法和系统。

背景技术

随着互联网行业的飞速发展，传统的架构模式已经完全不能满足业务发展的节奏，分布式微服务系统（以下简称微服务系统）已经成为各互联网甚至传统软件公司广泛使用的微服务系统架构。因此，针对微服务系统的数据监控就显得尤为重要。

数据监控，是指实时监控微服务系统运行过程中产生的一些数据，以便能及时发现和预防微服务系统的故障的技术。目前的数据监控方案主要是对微服务系统的日志数据(Log)，指标数据(Metrics)和链路数据(Trace)进行监控。

指标数据一般是通过在服务中进行埋点来收集，再通过定时的推送(push)或者拉取(pull)来将数据传输到数据库中。指标数据通常有着统一的格式：每一条数据都会携带一个时间戳(timestamp)。而存储指标数据的数据库被称为时间序列数据库(time-seriesdatabase，TSDB，以下称时序数据库)。目前主流的时序数据库解决方案有Prometheus等。

当收集的指标数据的数据量较大时，现有的时序数据库响应用户查询的速度会显著变慢，并且现有的部分时序数据库（例如Prometheus）在重启后会有一段时间处于不可用的状态。因此，基于现有的时序数据库实现的数据监控方案可用性较差。

发明内容

针对上述现有技术的缺点，本发明提供一种微服务系统的数据监控方法和系统，以提供一种可用性更好的数据监控方案。

本申请第一方面提供一种微服务系统的数据监控方法，应用于数据监控系统，所述数据监控系统包括采集节点和存储节点，所述采集节点的数量为多个，所述方法包括：

所述采集节点采集所述微服务系统的指标数据；其中，每一条所述指标数据均被至少两个所述采集节点采集；

所述存储节点存储所述采集节点采集的所述指标数据；

所述存储节点响应查询请求，在存储的指标数据中查询满足所述查询请求的指标数据。

可选的，所述存储节点的数量为多个，多个所述存储节点中有至少一个主存储节点和至少一个备存储节点；

所述存储节点存储所述采集节点采集的所述指标数据，包括：

所述主存储节点和所述备存储节点均存储所述采集节点采集的所述指标数据；

所述存储节点响应查询请求，在存储的指标数据中查询满足所述查询请求的指标数据，包括：

所述主存储节点可用时，所述主存储节点响应查询请求，在存储的指标数据中查询满足所述查询请求的指标数据；

所述主存储节点不可用时，所述备存储节点响应查询请求，在存储的指标数据中查询满足所述查询请求的指标数据。

可选的，多个所述存储节点均和代理服务器连接；

所述主存储节点响应查询请求，在存储的指标数据中查询满足所述查询请求的指标数据之前，还包括：

所述代理服务器确定所述主存储节点可用；

所述代理服务器将接收的查询请求发送给所述主存储节点；

所述备存储节点响应查询请求，在存储的指标数据中查询满足所述查询请求的指标数据之前，还包括：

所述代理服务器确定所述主存储节点不可用；

所述代理服务器将接收的查询请求发送给所述备存储节点。

可选的，所述主存储节点的数量为多个；

所述代理服务器将接收的查询请求发送给所述主存储节点，包括：

所述代理服务器确定每一个所述主存储节点的负载；

所述代理服务器将接收的查询请求发送给负载最低的所述主存储节点。

可选的，所述存储节点存储所述采集节点采集的所述指标数据之前，还包括：

所述存储节点从所述采集节点采集的所述指标数据中筛除重复的指标数据。

本申请第二方面提供一种微服务系统的数据监控系统，包括采集节点和存储节点，所述采集节点的数量为多个；

所述采集节点用于采集所述微服务系统的指标数据；其中，每一条所述指标数据均被至少两个所述采集节点采集；

所述存储节点用于存储所述采集节点采集的所述指标数据；

所述存储节点用于响应查询请求，在存储的指标数据中查询满足所述查询请求的指标数据。

可选的，所述存储节点的数量为多个，多个所述存储节点中有至少一个主存储节点和至少一个备存储节点；

所述主存储节点和所述备存储节点均用于存储所述采集节点采集的所述指标数据；

所述主存储节点可用时，所述主存储节点用于响应查询请求，在存储的指标数据中查询满足所述查询请求的指标数据；

所述主存储节点不可用时，所述备存储节点用于响应查询请求，在存储的指标数据中查询满足所述查询请求的指标数据。

可选的，所述系统还包括和多个所述存储节点连接的代理服务器；

所述代理服务器用于：

确定所述主存储节点可用；

将接收的查询请求发送给所述主存储节点；

或者用于：

确定所述主存储节点不可用；

将接收的查询请求发送给所述备存储节点。

可选的，所述主存储节点的数量为多个；

所述代理服务器将接收的查询请求发送给所述主存储节点时，具体用于：

所述代理服务器确定每一个所述主存储节点的负载；

所述代理服务器将接收的查询请求发送给负载最低的所述主存储节点。

可选的，所述存储节点还用于：

从所述采集节点采集的所述指标数据中筛除重复的指标数据。

本申请提供一种微服务系统的数据监控方法和系统，方法应用于由存储节点和多个采集节点组成的数据监控系统，方法包括：采集节点采集微服务系统的指标数据；每一条指标数据均被至少两个采集节点采集；存储节点存储采集的指标数据；存储节点响应查询请求，在存储的指标数据中查询满足查询请求的指标数据。现有部分时序数据库（例如Prometheus）重启后会自动向内存加载数据，导致重启后一段时间不可用。本方案将指标数据的采集和存储分给不同节点，且采集节点有多个，一方面避免采集节点重启后向内存加载数据，使采集节点重启后立即恢复采集，另一方面多个采集节点的数据互为备份，任一采集节点宕机也不影响指标数据的完整，提高了数据监控系统的可用性。

附图说明

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

图1为本申请实施例提供的一种微服务系统的数据监控方法的流程图；

图2为本申请实施例提供的一种微服务系统的数据监控系统的结构框图；

图3为本申请实施例提供的一种微服务系统的数据监控系统的技术架构示意图。

具体实施方式

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

为了便于理解本申请的技术方案，首先简要介绍本申请可能涉及的部分概念。

Prometheus，是一套开源的系统监控报警框架。可以认为是一个时序数据库，以配置的方式监控目标数据，定时通过HTTP请求获取目标监控数据，默认存储在本地硬盘，同时支持远程写入到可扩展的第三方存储系统。并且提供多维度数据模型和灵活的查询方式。是目前业内主流的度量指标方案。

VictoriaMetrics，是一个高效的时序数据库。可以用做prometheus的远程存储。提供比prometheus更高的压缩比以及更快的处理速度。

Nginx，是一个高性能的http和反向代理web服务器。本发明中nginx中用做负载均衡服务使用。

Grafana，是一个业内主流的开源数据可视化工具。可以做数据监控和数据统计，带有告警功能。拥有多种可视化模块，同时支持众多数据库类型。

如背景技术所述，当收集的指标数据的数据量较大时，现有的时序数据库响应用户查询的速度会显著变慢，并且现有的时序数据库在重启后会有一段时间处于不可用的状态。因此，基于现有的时序数据库实现的数据监控方案可用性较差。

以基于Prometheus框架的时序数据库为例，导致上述问题的原因在于：

Prometheus为了保证数据的快速响应，会实时地将最近2小时内收集到的微服务系统的指标数据放在本地设备的内存，当最近2小时内的指标数据的数据量较大时，这一特性就会导致大量的内存被占用，同时当用户从Prometheus查询历史数据时，Prometheus也需要将硬盘中的数据加载到内存。由此可见，当最近2小时内的指标数据的数据量较大时，由于内存空间有限，Prometheus响应用户查询的速度就会下降，甚至当历史数据较多时还会导致内存满载，使得设备重启。

进一步的，在重新启动后，内存被清空，此时Prometheus又会将最近2小时的指标数据加载到内存，在这段加载的时间内Prometheus就会处于不可用状态。

针对上述问题，本申请实施例提供一种微服务系统的数据监控方法，以便提供一种高可用性的数据监控方案。

本申请实施例提供的微服务系统的数据监控方法，本实施例提供的方法数据监控系统执行，数据监控系统包括采集节点和存储节点，采集节点的数量为多个。请参见图1，该方法包括如下步骤。

S101，采集节点采集微服务系统的指标数据。

其中，每一条指标数据均被系统中至少两个采集节点采集。例如，在采集指标数据时，某一条指标数据A，会被采集节点1采集，也会被采集节点2采集，由此，采集节点1的指标数据A和采集节点2的指标数据A可以互为备份。

也就是说，在步骤S101中多个采集节点按交叉收集的方式采集微服务系统的指标数据时，由此，不同的采集节点所采集到的指标数据之间可以互为备份，其中任意一个采集节点宕机都不会影响采集到的指标数据的完整性。

上述交叉收集具体可以通过多种方法实现，本实施例对其具体实现方法不做限定。

作为一种示例，多个采集节点可以按如下方法实现交叉收集：

为了便于说明，假定本示例中采集节点的数量为三个，可以理解，本示例的实现方法可以适用于任意多个采集节点。

首先，将需要收集的指标数据按照一定的分类规则划分为多个类别。例如，可以按照指标数据的名称开头的字符串来分类。

示例性的，不妨假设需要收集的所有指标数据的名称均以a，b，c，d四个字符串中的任意一个字符串开头，那么根据这四个字符串对指标数据的名称进行模糊匹配，就可以将需要收集的指标数据划分为a，b，c，d四个类别。

其次，在完成分类后，通过采集节点中的配置项来指定每个采集节点采集某几个类别的指标数据，其中，每一个类别的指标数据均会被多个采集节点采集。

结合前述示例，可以设定采集节点1采集a，b，c三个类别的指标数据，采集节点2采集b，c，d三个类别的指标数据，采集节点3采集c，d，a三个类别的指标数据。

由此，每一条指标数据，不论其属于a，b，c，d中哪一个类别，该指标数据都会被多个采集节点同时采集，从而实现了多个采集节点的相互备份，即使有任意一个采集节点宕机也不会影响指标数据的完整性。

本实施例中，采集节点可以基于任意一种技术框架实现，本实施例对具体实现不做限定。

示例性的，本实施例的采集节点可以是基于前述Prometheus框架实现的采集节点，也即Prometheus节点。

以Prometheus节点为例，前述用于指定采集的指标数据的类别的配置项可以是Prometheus框架提供的metric_relabel_configs配置项。

结合前述示例中为各采集节点分配的类别，采集节点1的metric_relabel_configs配置项具体可以配置如下：

metric_relabel_configs:

- source_labels: [__name__]

regex: a.*|b.*|c.*

action: keep

上述配置表示，收集名称以字符串a，b和c开头（基于模糊匹配）的指标数据，可以看出，通过上述配置可以指定采集节点1收集a，b和c三个类别的数据。

S102，存储节点存储采集节点采集的指标数据。

在步骤S102中，采集节点将采集到的指标数据传输给存储节点，由存储节点存储采集到的指标数据。

在一些可选的实施例中，采集节点也可以在本地保存少量的最近采集到的指标数据，保存的时间段可以根据需要设定。示例性的，采集节点可以被配置为，在本地保存最近30分钟内采集到的指标数据。

需要说明，存储节点的数量可以是一个或多个。并且，每一个存储节点，均会收到全部采集节点采集到的指标数据，也就是说，S101中采集到的所有指标数据在每一个存储节点均有备份。由此，当有多个存储节点时，任意一个存储节点宕机都不会影响对指标数据的查询和监控。

采集节点向存储节点传输指标数据的方式，可以是，采集节点中预先配置有存储节点的网络地址，采集节点基于该网络地址，将采集到的指标数据主动发送给存储节点；也可以是，存储节点定时向采集节点发送数据获取请求，从而指示采集节点反馈采集到的指标数据。

下面以主动发送的方式为例进行说明：

仍假设采集节点为基于Prometheus框架的Prometheus节点，每个Prometheus节点的远程写入（remote_write）配置项均可以配置上述示例性的信息：

remote_write:

- url: http://{victoriaMetrics-major-ip}:8428/api/v1/write

- url: http://{victoriaMetrics-minor-ip}:8428/api/v1/write

上述配置信息中的两个url分别是两个存储节点的网络地址，每一个采集节点采集到指标数据后，均可以基于配置中的网络地址，向这两个存储节点发送采集到的指标数据，使得存储节点存储采集到的指标数据。

通过上述配置，可以在数据存储方面保证存储脱离Prometheus，不会因为Prometheus的宕机导致存储的指标数据不可用，提高了数据监控系统的可用性。

本实施例中，存储节点所采用的技术框架同样不做限定。作为示例，存储节点具体可以是前述VictoriaMetrics时序数据库，也就是说，在本发明的方案利用VictoriaMetrics时序数据库来承担存储和查询的职责。

用VictoriaMetrics时序数据库作为存储节点的好处在于，VictoriaMetrics实现了Prometheus的全部api和PromQL，并且它有比Prometheus高的压缩比和更快的处理速度。单机的数据存储与查询耗时已经比Prometheus等其他同类框架提高7倍有余(官方文档数据资料)。

S103，存储节点响应查询请求，在存储的指标数据中查询满足查询请求的指标数据。

当有多个存储节点时，每一个存储节点均可以响应查询请求，查询满足查询请求的指标数据。

其中，上述查询请求可以有用户通过数据监控系统的可视化工具发送。具体的，用户可以在数据监控系统的可视化工具中输入查询条件，然后可视化工具基于查询条件生成查询请求，再将查询请求发送至任意一个存储节点。

本实施例中，可视化工具可以采用Grafana框架，当然，也可以采用其他技术框架，本实施例不做限定。

结合上述实施例不难看出，本方案将指标数据的采集与指标数据的存储（和查询）分离，指标数据的采集由采集节点负责，指标数据的存储和查询由存储节点负责，从而避免采集节点因为在内存中加载过多的数据而导致查询效率降低，甚至导致宕机的问题。

在一些可选的实施例中，为了提高存储节点的可用性，避免存储的指标数据丢失，本发明可以采用存储节点主备部署方案，具体的，当存储节点具体为VictoriaMetrics时序数据库，可以采用VictoriaMetrics单机版主备部署。

下面对基于主备部署方案配置的存储节点的工作方法进行说明：

首先，为实现主备部署方案，数据监控系统的存储节点的数量被设置为多个，并且多个存储节点中有至少一个主存储节点（用major表示）和至少一个备存储节点（用minor表示）。

其中，存储节点存储采集节点采集的指标数据，包括：

主存储节点和备存储节点均存储采集节点采集的指标数据，也就是说，在主备部署方案中，主存储节点和备存储节点都用于存储每一个采集节点采集的指标数据。

基于主备部署方案，步骤S103，即存储节点响应查询请求，在存储的指标数据中查询满足查询请求的指标数据的具体实现方式包括：

主存储节点可用时，主存储节点响应查询请求，在存储的指标数据中查询满足查询请求的指标数据；

主存储节点不可用时，备存储节点响应查询请求，在存储的指标数据中查询满足查询请求的指标数据。

可选的，当采用存储节点的主备部署方案时，可以在数据监控系统中设置代理服务器，多个存储节点均和代理服务器连接。

代理服务器可以承接查询请求，然后根据主存储节点是否可用，将查询请求代理给主存储节点或者备存储节点处理。

具体的，在主存储节点响应查询请求，在存储的指标数据中查询满足查询请求的指标数据之前，还包括：

代理服务器确定主存储节点可用；

代理服务器将接收的查询请求发送给主存储节点，从而触发主存储节点按步骤S103处理查询请求。

同理，在备存储节点响应查询请求，在存储的指标数据中查询满足查询请求的指标数据之前，还包括：

代理服务器确定主存储节点不可用；

代理服务器将接收的查询请求发送给备存储节点，从而触发备存储节点按步骤S103处理查询请求。

示例性的，本实施例中代理服务器所采用技术框架可以是Nginx，当然，也可以是其他技术框架，本实施例不做限定。

当代理服务器采用Nginx框架时，代理服务器可以通过Upstream配置将查询请求代理到major存储（即主存储节点）。在主存储故障（即不可用）后可以自动将请求切换到minor存储（即备存储节点）中实现高可用。

作为一种示例，Upstream的配置可以如下：

upstream victoriaMetrics {

server {victoriaMetrics-major-ip}:8428;

server {victoriaMetrics-minor-ip}:8428 backup;}

其中第一个server对应主存储节点，第二个server对应备存储节点。

进一步可选的，代理服务器还可以在本发明的方案中承担查询请求的负载均衡。

可选的，当主存储节点的数量为多个时，查询请求的负载均衡方式具体可以是：

代理服务器确定每一个主存储节点的负载，每一个主存储节点的负载可以由代理服务器从主存储节点请求得到。

代理服务器将接收的查询请求发送给负载最低的主存储节点。

以上过程可以视为前述代理服务器将接收的查询请求发送给主存储节点步骤的一种具体实现方式。

可选的，存储节点存储采集节点采集的指标数据之前，还包括：

存储节点从采集节点采集的指标数据中筛除重复的指标数据。

本实施例中，存储节点可以采用多种方式筛除重复的指标数据，本实施例对具体的筛除方式不做限定。

作为一种示例，存储节点可以按如下方式筛除重复的指标数据：

预先设定一个去重时间段，其具体长度可按需设定，例如设定为n秒。

基于此，存储节点每收到一条指标数据，就在此后的去重时间段内识别是否收到和该指标数据重复的指标数据，如果收到，将后续收到的重复的指标数据删除。

示例性的，当存储节点具体为VictoriaMetrics时序数据库时，上述方案可以通过存储节点的-dedup.minScrapeInterval={n}s参数配置实现，通过前述参数配置，存储节点就可以在收重复的指标数据时拥有去重逻辑。在n秒时间内的数据收取中只保留最早的上报。从而解决了多个采集节点上报数据重复的问题。

示例性的，在某一时刻采集节点1至3都采集到了指标数据X，然后都向存储节点上报，其中采集节点1的指标数据X先传递到存储节点，由此触发前述去重逻辑，存储节点在收到采集节点1的指标数据X之后的n秒内，识别是否收到其他采集节点的指标数据X，通过识别发现收到采集节点2和3的指标数据X，然后存储节点将采集节点2和3的重复的指标数据X删除。

本申请提供一种微服务系统的数据监控方法，方法应用于由存储节点和多个采集节点组成的数据监控系统，方法包括：采集节点采集微服务系统的指标数据；每一条指标数据均被至少两个采集节点采集；存储节点存储采集的指标数据；存储节点响应查询请求，在存储的指标数据中查询满足查询请求的指标数据。现有部分时序数据库（例如Prometheus）重启后会自动向内存加载数据，导致重启后一段时间不可用。本方案将指标数据的采集和存储分给不同节点，且采集节点有多个，一方面避免采集节点重启后向内存加载数据，使采集节点重启后立即恢复采集，另一方面多个采集节点的数据互为备份，任一采集节点宕机也不影响指标数据的完整，提高了数据监控系统的可用性。

根据本申请实施例提供的微服务系统的数据监控方法，本申请实施例还提供一种微服务系统的数据监控系统，请参见图2，该系统包括采集节点201和存储节点202，采集节点201的数量为多个。

采集节点201用于采集微服务系统的指标数据。

其中，每一条指标数据均被系统中至少两个采集节点201采集。

存储节点202用于存储采集节点201采集的指标数据。

存储节点202用于响应查询请求，在存储的指标数据中查询满足查询请求的指标数据。

可选的，存储节点202的数量为多个，多个存储节点202中有至少一个主存储节点202和至少一个备存储节点202；

主存储节点202和备存储节点202均用于存储采集节点201采集的指标数据；

主存储节点202可用时，主存储节点202用于响应查询请求，在存储的指标数据中查询满足查询请求的指标数据；

主存储节点202不可用时，备存储节点202用于响应查询请求，在存储的指标数据中查询满足查询请求的指标数据。

可选的，系统还包括和多个存储节点202连接的代理服务器203；

代理服务器203用于：

确定主存储节点202可用；

将接收的查询请求发送给主存储节点202；

或者用于：

确定主存储节点202不可用；

将接收的查询请求发送给备存储节点202。

可选的，主存储节点202的数量为多个；

代理服务器203将接收的查询请求发送给主存储节点202时，具体用于：

代理服务器203确定每一个主存储节点202的负载；

代理服务器203将接收的查询请求发送给负载最低的主存储节点202。

可选的，存储节点202还用于：

从采集节点201采集的指标数据中筛除重复的指标数据。

可选的，本实施例的系统还可以包括可视化工具204，用于展示用户查询得到的指标数据。

本申请实施例所提供的微服务系统的数据监控系统，其具体工作原理可以参见本申请任一实施例提供的微服务系统的数据监控方法中的相关步骤，此处不再赘述。

本申请提供一种微服务系统的数据监控系统，数据监控系统由存储节点和多个采集节点组成，采集节点201采集微服务系统的指标数据；每一条指标数据均被多个采集节点重复采集；存储节点202存储采集的指标数据；存储节点202响应查询请求，在存储的指标数据中查询满足查询请求的指标数据。现有部分时序数据库（例如Prometheus）重启后会自动向内存加载数据，导致重启后一段时间不可用。本方案将指标数据的采集和存储分给不同节点，且采集节点有多个，一方面避免采集节点重启后向内存加载数据，使采集节点重启后立即恢复采集，另一方面多个采集节点的数据互为备份，任一采集节点宕机也不影响指标数据的完整，提高了数据监控系统的可用性。

请参见图3，为本申请实施例提供的一种微服务系统的数据监控系统的技术架构示意图。

从图3可以看出，本申请实施例的数据监控系统中，采集节点可以是采用Prometheus框架的节点，图3中的三个采集节点依次记为监控框架节点Prometheus-1至监控框架节点Prometheus-3。

存储节点可以采用VictoriaMetrics时序数据库，并且存储节点的部署方式可以采用VictoriaMetrics主备部署方案，图3中的两个存储节点分别记为高效时序数据库VictoriaMetrics-major（表示主存储节点），以及高效时序数据库VictoriaMetrics-minor（表示备存储节点）。

代理服务器可以采用Nginx框架，图3中代理服务器记为代理服务器Nginx。可视化工具则可以采用Grafana框架，图3中的可视化工具记为可视化工具Grafana。

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

需要注意，本发明中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。

专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (8)

1.一种微服务系统的数据监控方法，其特征在于，应用于数据监控系统，所述数据监控系统包括采集节点和存储节点，所述采集节点的数量为多个，所述方法包括：

各个所述采集节点分别采集对应类别的所述微服务系统的指标数据；其中，不同类别的指标数据的名称的开头字符不同；且每一类别的指标数据均被至少两个所述采集节点采集；

所述存储节点从采集节点采集的指标数据中筛除重复的指标数据，并存储去重后的指标数据；

所述存储节点响应查询请求，在存储的指标数据中查询满足所述查询请求的指标数据；

其中，所述从采集节点采集的指标数据中筛除重复的指标数据，包括：对于存储节点每接收到一条当前指标数据，识别所述指标数据在前n秒钟内是否存在重复的数据；若存在，则将所述当前指标数据删除；若未存在，将之后的n秒钟内收到的重复数据删除。

2.根据权利要求1所述的方法，其特征在于，所述存储节点的数量为多个，多个所述存储节点中有至少一个主存储节点和至少一个备存储节点；

所述存储节点存储所述采集节点采集的所述指标数据，包括：

所述主存储节点和所述备存储节点均存储所述采集节点采集的所述指标数据；

所述存储节点响应查询请求，在存储的指标数据中查询满足所述查询请求的指标数据，包括：

所述主存储节点可用时，所述主存储节点响应查询请求，在存储的指标数据中查询满足所述查询请求的指标数据；

所述主存储节点不可用时，所述备存储节点响应查询请求，在存储的指标数据中查询满足所述查询请求的指标数据。

3.根据权利要求2所述的方法，其特征在于，多个所述存储节点均和代理服务器连接；

所述主存储节点响应查询请求，在存储的指标数据中查询满足所述查询请求的指标数据之前，还包括：

所述代理服务器确定所述主存储节点可用；

所述代理服务器将接收的查询请求发送给所述主存储节点；

所述备存储节点响应查询请求，在存储的指标数据中查询满足所述查询请求的指标数据之前，还包括：

所述代理服务器确定所述主存储节点不可用；

所述代理服务器将接收的查询请求发送给所述备存储节点。

4.根据权利要求3所述的方法，其特征在于，所述主存储节点的数量为多个；

所述代理服务器将接收的查询请求发送给所述主存储节点，包括：

所述代理服务器确定每一个所述主存储节点的负载；

所述代理服务器将接收的查询请求发送给负载最低的所述主存储节点。

5.一种微服务系统的数据监控系统，其特征在于，包括采集节点和存储节点，所述采集节点的数量为多个；

各个所述采集节点用于分别采集对应类别的所述微服务系统的指标数据；其中，不同类别的指标数据的名称的开头字符不同；且每一类别的指标数据均被至少两个所述采集节点采集；

所述存储节点用于从采集节点采集的指标数据中筛除重复的指标数据，并存储去重后的指标数据；

所述存储节点用于响应查询请求，在存储的指标数据中查询满足所述查询请求的指标数据；

其中，所述从采集节点采集的指标数据中筛除重复的指标数据，包括：对于存储节点每接收到一条当前指标数据，识别所述指标数据在前n秒钟内是否存在重复的数据；若存在，则将所述当前指标数据删除；若未存在，将之后的n秒钟内收到的重复数据删除。

6.根据权利要求5所述的系统，其特征在于，所述存储节点的数量为多个，多个所述存储节点中有至少一个主存储节点和至少一个备存储节点；

所述主存储节点和所述备存储节点均用于存储所述采集节点采集的所述指标数据；

所述主存储节点可用时，所述主存储节点用于响应查询请求，在存储的指标数据中查询满足所述查询请求的指标数据；

所述主存储节点不可用时，所述备存储节点用于响应查询请求，在存储的指标数据中查询满足所述查询请求的指标数据。

7.根据权利要求6所述的系统，其特征在于，所述系统还包括和多个所述存储节点连接的代理服务器；

所述代理服务器用于：

确定所述主存储节点可用；

将接收的查询请求发送给所述主存储节点；

或者用于：

确定所述主存储节点不可用；

将接收的查询请求发送给所述备存储节点。

8.根据权利要求7所述的系统，其特征在于，所述主存储节点的数量为多个；

所述代理服务器将接收的查询请求发送给所述主存储节点时，具体用于：

所述代理服务器确定每一个所述主存储节点的负载；

所述代理服务器将接收的查询请求发送给负载最低的所述主存储节点。

Images