CN115002205B - 一种基于表路由代理模式的Kapacitor集群方法 - Google Patents

Abstract

本发明公开了一种基于表路由代理模式的Kapacitor集群方法，包括以下步骤：提供协议的支持；通过外部数据写Kapacitor的服务请求；建立关联关系；通过标准接口把所有的任务下发到每个Kapacitor实例中；实时监控每个分组中的Kapacitor实例；解析出表与Kapacitor实例的绑定关系，查询信息数据，并将数据实时写入到具体的Kapacitor实例；完成任务配置，发现异常触发告警。本发明基于Kapacitor分布式集群的中间件代理模式，支持标准的行协议，对外完全透明与Kapacitor单节点使用方式保持一致，减轻接入压力。

Description

一种基于表路由代理模式的Kapacitor集群方法

技术领域

本发明涉及智慧运维领域，具体来说，涉及一种基于表路由代理模式的Kapacitor集群方法。

背景技术

随着云化、容器化、分布式微服务的技术和架构持续演进，物联网的持续进化；应用实例和各种被监控对象的数量都以指数级增长，现代应用系统的性能，可用性等KPI（KeyPerformance Indicator，关键性能指标）数据都具有两个明显的特征：

1、系统KPI的数据具备时序型数据特征。

2、指标量都是海量级别，为了能够对当前的应用系统架构来做更好的监控。

实现对海量指标的计算需求变得更加迫切，对海量指标处理系统的稳定性也提出了更大的挑战。

业界在流式计算这方面，比较流行的组件有spark和flink，但这两种组件都存在两个相同的问题，1、资源需求高，2、运维复杂度太大。在以项目化交付的场景中，系统规模差异过大，有的十多台主机，有的一万多台主机。负面影响过大。Kapacitor是InfluxData公司开发的一种支持监控告警，ETL的轻量化流式计算组件；而传统的Kapacitor方案，只支持单机模式。无法应对当前对海量指标处理的性能和稳定性需求。同时业界的一些基于任务拆分的分布式方案存在如下问题：1、计算和存储的强耦合无法隔离相互影响，告警的能力强依赖于指标存储服务InfluxDB。2、强依赖于InfluxDB的订阅服务，数据的流量被全量推送，无法做到精确控制，导致资源浪费。

针对相关技术中的问题，目前尚未提出有效的解决方案。

发明内容

针对相关技术中的问题，本发明提出一种基于表路由代理模式的Kapacitor集群方法，以克服现有相关技术所存在的上述技术问题。

为此，本发明采用的具体技术方案如下：

一种基于表路由代理模式的Kapacitor集群方法，该方法包括以下步骤：

S1、通过分布式中间件代理提供基于Kapacitor标准HTTP协议的支持；

S2、服务请求的接入，通过外部数据写Kapacitor的服务请求；

S3、在分布式路由管理的可视化界面进行路由信息配置，建立Kapacitor实例与表的关联关系；

S4、根据所述路由信息配置获取Kapacitor实例，并通过Kapacitor提供的标准http api接口把所有的任务下发到每个Kapacitor实例中；

S5、实时监控每个分组中的Kapacitor实例；

S6、当外部请求发起写操作时，解析出表与Kapacitor实例的绑定关系，查询Kapacitor实例信息数据，并将数据实时写入到具体的Kapacitor实例；

S7、针对用户的需求，完成任务配置，发现异常触发告警。

进一步的，所述通过分布式中间件代理提供基于Kapacitor标准HTTP协议的支持还包括提供统一资源定位符地址及请求服务地址，且所述请求服务地址为/write。

进一步的，所述服务请求的接入，通过外部数据写Kapacitor的服务请求还包括以下步骤：

在指标量较小的场景下，链接地址配置信息配置为分布式中间件代理提供的服务地址和端口，数据会被写入到分布式中间件代理提供的/write接口；

当面对海量指标数据时，分布式中间件代理为无状态可水平扩展的服务，分布式集群通过增加负载均衡器把外部请求转发到分布式中间件代理提供的/write请求地址上。

进一步的，所述在分布式路由管理的可视化界面进行路由信息配置，建立Kapacitor实例与表的关联关系还包括以下步骤：

在分布式路由管理的可视化界面，用户通过输入Kapacitor实例名称、实例地址、用户名密码、批量大小及批量周期来完成Kapacitor实例的配置；

在分布式路由管理的可视化界面，用户输入待路由管理的指标表名称和表的备注，完成指标表信息的配置；

在分布式路由管理的可视化界面，用户选择创建分组。

进一步的，所述在分布式路由管理的可视化界面，用户选择创建分组包括以下步骤：

输入分组名，选择是否默认分组；

用户选择配置的Kapacitor实例信息，并设置每个被选择实例的角色，一个组内只能有一个主角色，可有多个备角色；

用户选择配置的表信息，可以选择多个表，并完成Kapacitor实例与表的关联关系。

进一步的，所述根据所述路由信息配置获取Kapacitor实例，并通过Kapacitor提供的标准http api接口把所有的任务下发到每个Kapacitor实例中任务下发之前还包括以下步骤：

通过用户选择指标计算的周期、计算的函数、生效对象、以及判定是否告警的条件阈值信息，把可视化的结果转换为符合TICKscripts规范的Kapacitor任务。

进一步的，所述实时监控每个分组中的Kapacitor实例包括以下步骤：

若发现不可用的Kapacitor实例，如果是分组中的主节点Kapacitor实例不可用，将基于分组中各备节点的指标综合判断，选择最优的备节点设置为主节点，刷新路由信息。

进一步的，所述当外部请求发起写操作时，解析出表与Kapacitor实例的绑定关系，查询Kapacitor实例信息数据，并将数据实时写入到具体的Kapacitor实例包括以下步骤：

当外部请求发起写操作时，分布式中间件代理接收到InfluxData的标准行协议数据；

基于InfluxData行协议的规则，通过语法树解析出InfluxData的表信息；

根据解析出的表信息，查询表和表所在分组的配置关系。

进一步的，所述分布式中间件代理接收到InfluxData的标准行协议数据中标准行协议数据的格式为：

<measurement>[,<tag_key>=<tag_value>[,<tag_key>=<tag_value>]] <field_key>=<field_value>[,<field_key>=<field_value>] [<timestamp>]；

其中，measurement表示表名；

tag_key表示标签字段；

field_key表示值字段名称；

tag_value表示标签值；

field_value表示值字段值；

timestamp表示时间。

进一步的，所述根据解析出的表信息，查询表和表所在分组的配置关系包括以下步骤：

如果查询到表与分组的配置关系，返回此分组内Kapacitor主节点的实例；

如果未查询到，将返回默认分组内Kapacitor主节点的实例。

本发明的有益效果为：

1、本发明基于Kapacitor分布式集群的中间件代理模式，支持标准的行协议（line-protocol），即可按传统的InfluxDB订阅模式，InfluxDB主动推送数据到Kapacitor分布式集群，也可由外部写入，对外完全透明与Kapacitor单节点使用方式保持一致，减轻接入压力。

2、本发明基于Kapacitor分布式集群的中间件代理的模式，存储和计算可完全分离，不需要强依赖InfluxDB，而且因为InfluxDB仅支持单点模式，本身就存在稳定性和性能问题，本方案当存储节点发生故障时，数据流式计算可不受任何影响，能及时预警减少因为故障带来的损失，达到计算与存储分离高级别架构初衷。

3、本发明中考虑了单实例Kapacitor的故障情况，并实时监控Kapacitor的运行状态，将根据Kapacitor状态数据，动态刷新路由，实时下架故障主节点实例，上架健康实例为主节点，保证容灾的同时，因为每个分组中有且仅有一个Kapacitor主节点实例，防止了相同的表数据写入到多个Kapacitor实例，而每个Kapacitor运行相同的任务，进而导致相同数据生成多个告警的问题。

4、本发明中对原生Kapacitor任务编写存在非常高复杂度的问题，提供了可视化任务编写到TICKscripts任务脚本的自动化转换的能力，极大降低了Kapacitor任务配置的复杂度，使得非专业人员也可快速的配置出Kapacitor任务。

5、相对于传统的通过任务切分，建立与Kapacitor实例的关系构建分布式方案，因为InfluxDB的订阅维度是数据库+存储策略，所以数据流量的管理最小维度是数据库+存储策略，而基于表路由的模式，流量转发的模式控制更加精确。

附图说明

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

图1是根据本发明实施例的一种基于表路由代理模式的Kapacitor集群方法的流程图；

图2是表示原生Kapacitor主动订阅InfluxDB模式的数据流图；

图3是基于表路由分片引擎的Kapacitor分布式集群对接传统InfluxDB订阅模式的数据流图；

图4是存储和计算分离的表路由分片引擎的Kapacitor分布式集群数据流图；

图5是储表路由分片引擎的Kapacitor分布式集群的功能示框图。

具体实施方式

为进一步说明各实施例，本发明提供有附图，这些附图为本发明揭露内容的一部分，其主要用以说明实施例，并可配合说明书的相关描述来解释实施例的运作原理，配合参考这些内容，本领域普通技术人员应能理解其他可能的实施方式以及本发明的优点，图中的组件并未按比例绘制，而类似的组件符号通常用来表示类似的组件。

根据本发明的实施例，提供了一种基于表路由代理模式的Kapacitor集群方法。

现结合附图和具体实施方式对本发明进一步说明，如图1所示，根据本发明实施例的基于表路由代理模式的Kapacitor集群方法，该方法包括以下步骤：

S1、通过分布式中间件代理提供基于Kapacitor标准HTTP协议的支持；

其中，所述通过分布式中间件代理提供基于Kapacitor标准HTTP协议的支持还包括提供统一资源定位符地址及请求服务地址，且所述请求服务地址为/write。

S2、服务请求的接入，通过外部数据写Kapacitor的服务请求；

其中，所述服务请求的接入，通过外部数据写Kapacitor的服务请求还包括以下步骤：

在指标量较小的场景下，链接地址配置信息配置为分布式中间件代理提供的服务地址和端口，数据会被写入到分布式中间件代理提供的/write接口；

当面对海量指标数据时，分布式中间件代理为无状态可水平扩展的服务，分布式集群通过增加负载均衡器把外部请求转发到分布式中间件代理提供的/write请求地址上。

S3、在分布式路由管理的可视化界面进行路由信息配置，建立Kapacitor实例与表的关联关系；

其中，所述在分布式路由管理的可视化界面进行路由信息配置，建立Kapacitor实例与表的关联关系还包括以下步骤：

在分布式路由管理的可视化界面，用户通过输入Kapacitor实例名称、实例地址、用户名密码、批量大小及批量周期来完成Kapacitor实例的配置；

在分布式路由管理的可视化界面，用户输入待路由管理的指标表名称和表的备注，完成指标表信息的配置；

在分布式路由管理的可视化界面，用户选择创建分组；

具体的，分组是用来建立Kapacitor实例与表的关联关系，每个分组需配置角色，分为默认分组和普通分组，默认分组只能有一个，每个分组中可配置多个Kapacitor实例，预防单点故障，Kapacitor实例可指定主备角色，每个分组中多个Kapacitor实例，只能有一个主节点，其他均为备节点。

其中，所述在分布式路由管理的可视化界面，用户选择创建分组包括以下步骤：

输入分组名，选择是否默认分组；

用户选择配置的Kapacitor实例信息，并设置每个被选择实例的角色，一个组内只能有一个主角色，可有多个备角色；

用户选择配置的表信息，可以选择多个表，并完成Kapacitor实例与表的关联关系。

S4、根据所述路由信息配置获取Kapacitor实例，并通过Kapacitor提供的标准http api接口把所有的任务下发到每个Kapacitor实例中；

其中，所述根据所述路由信息配置获取Kapacitor实例，并通过Kapacitor提供的标准http api接口把所有的任务下发到每个Kapacitor实例中任务下发之前还包括以下步骤：

通过用户选择指标计算的周期、计算的函数、生效对象、以及判定是否告警的条件阈值信息，把可视化的结果转换为符合TICKscripts规范的Kapacitor任务，让每个Kapacitor实例运行的任务完全一致；

具体的，Kapacitor的任务需要符合TICKscripts的规范，有一定的难度；为了降低用户配置Kapacitor任务的复杂度，提供可视化的配置管理界面，

S5、实时监控每个分组中的Kapacitor实例；

其中，所述实时监控每个分组中的Kapacitor实例包括以下步骤：

若发现不可用的Kapacitor实例，如果是分组中的主节点Kapacitor实例不可用，将基于分组中各备节点的指标综合判断，选择最优的备节点设置为主节点，刷新路由信息。

S6、当外部请求发起写操作时，解析出表与Kapacitor实例的绑定关系，查询Kapacitor实例信息数据，并将数据实时写入到具体的Kapacitor实例；

其中，所述当外部请求发起写操作时，解析出表与Kapacitor实例的绑定关系，查询Kapacitor实例信息数据，并将数据实时写入到具体的Kapacitor实例包括以下步骤：

当外部请求发起写操作时，分布式中间件代理接收到InfluxData的标准行协议数据；

其中，所述分布式中间件代理接收到InfluxData的标准行协议数据中标准行协议数据的格式为：

<measurement>[,<tag_key>=<tag_value>[,<tag_key>=<tag_value>]] <field_key>=<field_value>[,<field_key>=<field_value>] [<timestamp>]；

其中，measurement表示表名；

tag_key表示标签字段；

field_key表示值字段名称；

tag_value表示标签值；

field_value表示值字段值；

timestamp表示时间。

数据举例：cpu,host=172.16.81.4,core_id=1 user=60 1556813523098000000

基于InfluxData行协议的规则，通过语法树解析出InfluxData的表信息；

根据解析出的表信息，查询表和表所在分组的配置关系；

所述根据解析出的表信息，查询表和表所在分组的配置关系包括以下步骤：

如果查询到表与分组的配置关系，返回此分组内Kapacitor主节点的实例；

如果未查询到，将返回默认分组内Kapacitor主节点的实例。

S7、针对用户的需求，完成任务配置，发现异常触发告警；

具体的，在数据指标流入到Kapacitor后，基于每个Kapacitor中都保有完整的Kapacitor任务列表，任务依赖于用户的告警规则配置进行计算判断，如用户配置了主机cpu系统使用率，5分钟内的平均值超过50%进行告警，当某台主机的cpu系统使用率指标，在5分钟内，平均值大于50%时，Kapacitor即可判断出异常推送告警；同时针对Kapacitor任务，用户可自定义时间窗口，如5分钟或者10分钟等，用户可选择聚合计算的函数，如平均值，最大值，最小值，均方差，中位数等算法函数，高级能力支持联合计算，滑动窗口设置，同比环比，指标中断等能力，最终针对用户的需求，完成任务配置，发现异常触发告警。

为了方便理解本发明的上述技术方案，下面结合附图和具体的实施方式对本申请中的存储和计算分离的表路由分片引擎的Kapacitor分布式集群实施作进一步的详细说明，如图2-5所示；

步骤一、本方案中，因为面对的是海量指标接入和处理，分布式路由组件需要具备可扩展的能力，分布式路由组件（zcm_audit组件），此组件应用为无状态应用，可水平伸缩，整个分布式集群可通过nginx，HAproxy，LVS这三种负载均衡软件来做统一接入和请求分发，因为zcm_aduit的无状态能力设计，对于nginx软件的负载均衡策略：轮询策略，权重，以及ip_hash，都可完美适配，此处仅列举nginx的负载均衡策略并解释，对于HAproxy和LVS同样适配。

轮询策略：每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除；

权重策略：指定轮询几率，权重和访问比率成正比，用于后端服务器性能不均的情况；

Ip_hash策略：每个请求按访问ip地址的哈希结果分配，这样每个访客固定访问一个后端服务器，可以解决状态保持的问题。

分布式集群方法整合nginx网关，以nginx网关地址192.168.10.100端口80为例，对外提供统计服务地址，代理负载均衡分布式路由中间件组件zcm_audit，实例启动4个（根据实际的压力来部署实例数）

upstream zcm_audit {

server xxx.xxx.80.1:5503；

server xxx.xxx.80.2:5504；

server xxx.xxx.80.3:5505；

server xxx.xxx.80.4:5506；

}

在nginx中配置Kapacitor的标准数据写入接口服务地址：

# zcm-metrics

location ^~ /write {

proxy_pass http://zcm_audit /write；

}

步骤二、Kapacitor实例以及表路由配置等信息，存在持久化介质mysql中，在分布式路由管理的可视化界面，用户通过输入Kapacitor实例名称，实例地址，用户名密码，批量大小，批量周期，来完成Kapacitor实例的配置。其中批量大小和批量周期是为了提高吞吐和性能，配置的结果如下表：

步骤三、在分布式路由管理的可视化界面，用户输入待路由管理的指标表名称和表的备注，完成指标表信息的配置，配置的结果如下表：

步骤四、在分布式路由管理的可视化界面，用户选择创建分组：

A、输入分组名，选择是否默认分组；

B、用户选择第二步配置的Kapacitor实例信息，可选择多个；并设置每个被选择实例的角色，一个组内只能有一个主角色，可有多个备角色；

C、用户选择第三步配置的表信息，可以选择多个表。

最终完成Kapacitor实例组与表的关联关系，配置的结果如下表：

步骤五、配置Kapacitor的任务，Kapacitor的任务编写方式需要符合TICKscripts（Kapacitor使用名为TICKscript的领域特定语言（DSL）来定义涉及数据提取、转换和加载的任务，此外还涉及跟踪任意更改和检测数据中的事件。一项常见任务是定义警报）规范，对用户使用来说有一定的复杂度。本分布式集群方案，提供Kapacitor任务管理的可视化配置界面，通过用户可视化配置，把可视化的结果转换为符合TICKscripts规范的Kapacitor任务。如配置cpu的用户使用率大于90%的告警，用户在界面选择指标组为cpu，指标为user，选择计算的周期为1分钟，选择计算的函数为平均值，选择条件大于50，选择对172.16.81.4主机生效。最终生成的Kapacitor任务脚本如下：

var db = 'host_metrics'

var rp = 'k2h_raw'

var measurement = 'cpu'

var groupBy = ['host']

var whereFilter = lambda: ("host" == '172.16.81.4')

var name = 'cpu大于90'

var idVar = name + ':{{.Group}}'

var message = 'cpu大于 {{index .Fields "value"| printf "%0.2f"}} 告警'

var idTag = 'alertID'

var levelTag = 'level'

var messageField = 'message'

var durationField = 'duration'

var outputDB = 'chronograf'

var outputRP = 'autogen'

var outputMeasurement = 'alerts'

var triggerType = 'threshold'

var period = 1m

var every = 30s

var crit = 50

var data = stream

|from()

.database(db)

.retentionPolicy(rp)

.measurement(measurement)

.groupBy(groupBy)

.where(whereFilter)

|window()

.period(period)

.every(every)

.align()

|mean('user')

.as('value')

|default()

.tag('AlarmCode', '10000')

.tag('ProjectId', '562441')

.tag('ProjectCode', 'monitor')

var trigger = data

|alert()

.crit(lambda: "value" > crit)

.message(message)

.id(idVar)

.idTag(idTag)

.levelTag(levelTag)

.messageField(messageField)

.durationField(durationField)

.post('http://10.10.183.18:32580/zcm-kapacitor/alarm')

Trigger

步骤六、基于步骤五配置Kapacitor的任务，步骤四中配置的所有Kapacitor实例。任务管理模块，循环每个任务，并循环每个Kapacitor实例，调用每个Kapacitor提供的httpapi接口/kapacitor/v1/tasks，去创建，修改，和删除Kapacitor中的任务。

步骤七、外部系统写入时序数据库指标的同时可以基于相同的http协议下的行协议数据，同时写一份到分布式集群中，地址为：nginx网关的地址，192.168.10.100，端口为：80。

步骤八、分布式组件zcm_audit，接收到数据后，最常见的行协议数据样例为：

cpu,host=172.16.17.82,core_id=1 idle=30,system=15,user=23,wait=13,other=19 1556813561098000000，基于字符串分词的方法，找到第一个“,”字符，然后切割出cpu字符串，最终解析出行协议数据的归属表为cpu。

步骤九，根据第二到第四步配置的表与实例的关系，解析出表与Kapacitor实例的绑定关系，如当前的行协议数据为：cpu,host=172.16.17.82,core_id=1 idle=30,system=15,user=23,wait=13,other=19 1556813561098000000.解析出表为cpu，路由的实例为：Audit-11。

步骤十、分布式路由组件zcm_audit将数据写入到Audit-11，Audit-11中基于此表的规则将自动执行并基于配置的条件生成告警。

步骤十一、当分组中某个主实例异常时，Kapacitor状态管理会自动把主节点下线，并修改分组中的角色，分布式集群中的路由管理，将刷新新的路由关系，下个阶段数据写入时，将按最新绑定关系，转发数据。

具体的，InfluxDB：InfluxDB时序数据库，提供指标存储的能力，同时支持通过行协议将指标实时推送给第三方的订阅者；

Kapacitor：Kapacitor流式计算框架，发起对InfluxDB的订阅请求，订阅成功后，InfluxDB会实时推送指标到Kapacitor中；

告警管理模块：对告警做进一步的管理如压缩，延迟通知等；

数据解析模块：基于InfluxData行协议的规则，通过语法树，解析出InfluxData的表（measurement）信息。

路由规则模块：提供可视化的表与Kapacitor实例分组的管理，以及基于表来路由查询Kapacitor实例分组，并基于Kapacitor实例监控模块，实时上下架Kapacitor实例分组。

Kapacitor实例监控模块：实时监控每个分组中的Kapacitor实例，实时发现不可用的Kapacitor实例，如果是分组中的主节点Kapacitor实例不可用，实例监控模块，将基于分组中各备节点的cpu，内存，网络流量等指标综合判断，选择最优的备节点设置为主节点，刷新路由信息。

Kapacitor任务管理模块：1、提供可视化配置界面，用户通过向导配置，把可视化的结果转换为符合TICKscripts规范的Kapacitor任务。2、下发和更新每个分布式集群下的Kapacitor实例的任务信息和版本。

综上所述，借助于本发明的上述技术方案，本发明基于Kapacitor分布式集群的中间件代理模式，支持标准的行协议（line-protocol），即可按传统的InfluxDB订阅模式，InfluxDB主动推送数据到Kapacitor分布式集群，也可由外部写入，对外完全透明与Kapacitor单节点使用方式保持一致，减轻接入压力；本发明基于Kapacitor分布式集群的中间件代理的模式，存储和计算可完全分离，不需要强依赖InfluxDB，而且因为InfluxDB仅支持单点模式，本身就存在稳定性和性能问题，本方案当存储节点发生故障时，数据流式计算可不受任何影响，能及时预警减少因为故障带来的损失，达到计算与存储分离高级别架构初衷；本发明中考虑了单实例Kapacitor的故障情况，并实时监控Kapacitor的运行状态，将根据Kapacitor状态数据，动态刷新路由，实时下架故障主节点实例，上架健康实例为主节点，保证容灾的同时，因为每个分组中有且仅有一个Kapacitor主节点实例，防止了相同的表数据写入到多个Kapacitor实例，而每个Kapacitor运行相同的任务，进而导致相同数据生成多个告警的问题；本发明中对原生Kapacitor任务编写存在非常高复杂度的问题，提供了可视化任务编写到TICKscripts任务脚本的自动化转换的能力，极大降低了Kapacitor任务配置的复杂度，使得非专业人员也可快速的配置出Kapacitor任务；相对于传统的通过任务切分，建立与Kapacitor实例的关系构建分布式方案，因为InfluxDB的订阅维度是数据库+存储策略，所以数据流量的管理最小维度是数据库+存储策略，而基于表路由的模式，流量转发的模式控制更加精确。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种基于表路由代理模式的Kapacitor集群方法，其特征在于，该方法包括以下步骤：

S1、通过分布式中间件代理提供基于Kapacitor标准HTTP协议的支持；

S2、服务请求的接入，通过外部数据写Kapacitor的服务请求；

S3、在分布式路由管理的可视化界面进行路由信息配置，建立Kapacitor实例与表的关联关系；

其中，所述在分布式路由管理的可视化界面进行路由信息配置，建立Kapacitor实例与表的关联关系还包括以下步骤：

在分布式路由管理的可视化界面，用户通过输入Kapacitor实例名称、实例地址、用户名密码、批量大小及批量周期来完成Kapacitor实例的配置；

在分布式路由管理的可视化界面，用户输入待路由管理的指标表名称和表的备注，完成指标表信息的配置；

在分布式路由管理的可视化界面，用户选择创建分组；

其中，所述在分布式路由管理的可视化界面，用户选择创建分组包括以下步骤：

输入分组名，选择是否默认分组；

用户选择配置的Kapacitor实例信息，并设置每个被选择实例的角色，一个组内只能有一个主角色，可有多个备角色；

用户选择配置的表信息，可以选择多个表，并完成Kapacitor实例与表的关联关系；

S4、根据所述路由信息配置获取Kapacitor实例，并通过Kapacitor提供的标准httpapi接口把所有的任务下发到每个Kapacitor实例中；

S5、实时监控每个分组中的Kapacitor实例；

S6、当外部请求发起写操作时，解析出表与Kapacitor实例的绑定关系，查询Kapacitor实例信息数据，并将数据实时写入到具体的Kapacitor实例；

S7、针对用户的需求，完成任务配置，发现异常触发告警。

2.根据权利要求1所述的一种基于表路由代理模式的Kapacitor集群方法，其特征在于，所述通过分布式中间件代理提供基于Kapacitor标准HTTP协议的支持还包括提供统一资源定位符地址及请求服务地址，且所述请求服务地址为/write。

3.根据权利要求1所述的一种基于表路由代理模式的Kapacitor集群方法，其特征在于，所述服务请求的接入，通过外部数据写Kapacitor的服务请求还包括以下步骤：

在指标量较小的场景下，链接地址配置信息配置为分布式中间件代理提供的服务地址和端口，数据会被写入到分布式中间件代理提供的/write接口；

当面对海量指标数据时，分布式中间件代理为无状态可水平扩展的服务，分布式集群通过增加负载均衡器把外部请求转发到分布式中间件代理提供的/write请求地址上。

4.根据权利要求1所述的一种基于表路由代理模式的Kapacitor集群方法，其特征在于，所述根据所述路由信息配置获取Kapacitor实例，并通过Kapacitor提供的标准httpapi接口把所有的任务下发到每个Kapacitor实例中任务下发之前还包括以下步骤：

通过用户选择指标计算的周期、计算的函数、生效对象、以及判定是否告警的条件阈值信息，把可视化的结果转换为符合TICKscripts规范的Kapacitor任务。

5.根据权利要求1所述的一种基于表路由代理模式的Kapacitor集群方法，其特征在于，所述实时监控每个分组中的Kapacitor实例包括以下步骤：

若发现不可用的Kapacitor实例，如果是分组中的主节点Kapacitor实例不可用，将基于分组中各备节点的指标综合判断，选择最优的备节点设置为主节点，刷新路由信息。

6.根据权利要求1所述的一种基于表路由代理模式的Kapacitor集群方法，其特征在于，所述当外部请求发起写操作时，解析出表与Kapacitor实例的绑定关系，查询Kapacitor实例信息数据，并将数据实时写入到具体的Kapacitor实例包括以下步骤：

当外部请求发起写操作时，分布式中间件代理接收到InfluxData的标准行协议数据；

基于InfluxData行协议的规则，通过语法树解析出InfluxData的表信息；

根据解析出的表信息，查询表和表所在分组的配置关系。

7.根据权利要求6所述的一种基于表路由代理模式的Kapacitor集群方法，其特征在于，所述分布式中间件代理接收到InfluxData的标准行协议数据中标准行协议数据的格式为：

<measurement>[,<tag_key>=<tag_value>[,<tag_key>=<tag_value>]] <field_key>=<field_value>[,<field_key>=<field_value>] [<timestamp>]；

其中，measurement表示表名；

tag_key表示标签字段；

field_key表示值字段名称；

tag_value表示标签值；

field_value表示值字段值；

timestamp表示时间。

8.根据权利要求6所述的一种基于表路由代理模式的Kapacitor集群方法，其特征在于，所述根据解析出的表信息，查询表和表所在分组的配置关系包括以下步骤：

如果查询到表与分组的配置关系，返回此分组内Kapacitor主节点的实例；

如果未查询到，将返回默认分组内Kapacitor主节点的实例。

Images