值得一提的是，该自研实时计算模块的功能，并未与数据的业务场景做任何绑定，也并不是只能用于运维数据的加工和分析场景。通过对接任何格式的流式数据，均可实现各类数据的加工、统计、规则判断、关联、复合统计等等处理逻辑，满足不同的使用场景需求。

1.2 Kafka集群管理

1.3 数据组件管理

2.1 数据类型管理

2.2 计算规则管理

2.2.1 加工规则

1）分词规则

2）数据加工

• 基于数据集加工规则

  数据加工处理过程中，往往会碰到一种场景，即需要根据数据中的某个信息扩展关联其他的信息并添加到数据中，以方便后续的统计分析。例如原始数据中存在ip地址信息，需要根据这个ip地址信息关联到其所属的业务系统名称或管理部门、管理人等信息，用于相应的业务逻辑统计。

  基于上述的业务场景需求，模块实现了这种基于数据集的加工规则。通过配置一条sql语句从数据库中查询维表数据并加载到缓存中，当源数据类型的数据流匹配到该加工规则时，根据维表所建立的字段映射关系，将目标字段值生成添加到目标数据类型的数据中。

  维表的映射关系支持两种过滤关系：

  一种是维表字段与源数据类型中字段的“等于”关系，即当A(维表).x（字段）=B（源数据）.y（字段）时，满足条件。

  另一种是维表字段与源数据类型中字段的“包含于”关系，即维表中的字段是包含多个字符串的，判断A(维表).x（字段）in B（源数据）.y（字段）时，满足条件。其中A(维表).x（字段）中是可以包含多个字符串的，以竖线分隔，该规则用于判断在源数据中是否同时满足包含多个字符串。

  在现场使用该功能的过程中，还添加了一类特定的场景规则，即需要判断某个sql语句中是否包含某些特定字符串（如特定的业务表或特定的操作关键字），由于sql语句中某些表名或字段名存在相似性，导致使用“包含于”规则无法正确匹配，所以我们增加了一类 “包含于（SQL专用）”规则，在匹配字段时需要额外判断前后的空格字符，以此来区分该字符串是一个表名（或字段名、关键字），而不是某个其他相似字符串的一部分。

  需要特别注意的是，在一个数据集加工规则中如果包含多个判断（过滤）条件，需要先配置“等于”规则，再配置“包含于”规则。多个“等于”规则的情况下，也优先配置能过滤掉更多数据的判断条件。这与数据库的查询相同，尽量减轻后面判断逻辑的压力。

• 基于源数据的转换规则

  在对源数据类型的转化需求里，我们总结了一些特定但具备共性的转换需求，如时间格式化转换、ip地址归属地域等，并将这些规则的实现固化到数据加工模块里。“时间规整到分钟”是由于原始数据在上游采集时出现数秒的延迟，而统计需要按分钟整点进行规整。

  日志里的时间格式不统一，有些有毫秒、有些只到秒，有些是linux的基于毫秒的时间戳，有些是基于秒的时间戳，需要统一按yyyy-MM-dd HH24:mm:ss来规整。

  而对于ip地址，在一些安全相关的场景中，需要识别该公网ip地址归属的国家或地区，并在后续的统计分析中基于其归属地进行分类统计，因此模块中增加了一个“ip转归属”的特定规则，实现对公网ip地址的自动关联生成其归属国家或地区。

  数据转换的规则是在现场使用过程中，基于业务场景逐渐添加的，后续也将不断扩展。

• 添加时间字段的加工规则

  某些从其他平台传入的源数据类型，可能并不包含时间信息，而指标计算往往是需要依据时间来进行统计的，所以需要一个数据加工规则，将数据中增加一个时间字段，目前是以实时计算程序接收到数据的时间作为其数据时间。

• 自动复制未配置规则的同名字段

  在数据加工配置过程中，从数据类型A到数据类型B的配置转换，除了少数字段会需要使用 “基于数据集加工规则”、“基于源数据的转换规则”、“添加时间字段的加工规则”方式来配置数据字段的加工处理，其他字段都需要沿用源数据类型的同名字段，因此增加了这个配置功能，自动完成同名字段的配置。在实际的使用过程中，应该先执行“自动复制未配置规则的同名字段”的配置动作，将可以复制的字段全部生成出来，再根据需要将其中的某些字段配置进行修改。（后续会将此配置功能实现自动化，当新增A数据类型到B数据类型的数据加工规则项时，自动复制同名字段的配置规则）

2.2.2 指标规则

1）简单指标计算

目前模块中实现的简单指标计算的分组统计规则包括以下几种：

• 等于value值

  等于value值准确来说不是一种统计逻辑，其作用的场景是针对每一条数据生成一个指标，用于实现对原始数据的指标化（格式化）。
  在运维场景中，从后台主机采集到的性能数据，或从第三方平台传输过来的性能数据，格式各不相同，通过“等于value值”的计算逻辑，根据业务场景的需要提取原始数据中的关键字段作为指标key值，以及获取原始数据中的性能数据值作为value值，生成统一格式的指标，用于下游的应用场景。
  需要特别注意的是，如果数据中根据分组逻辑存在一个分组中多条数据的情况，是不适用于这种规则的。因此必须根据原始数据中各属性字段的逻辑，在选择分组字段时必须控制保证每个分组只会包含一条数据。举例来说，对于一台主机上的磁盘空间使用率的采集数据，如果分组字段只选择了ip地址的话，使用该统计规则是无法正确生成每个磁盘的使用率的（只会获取到第一条数据生成指标），必须在分组时选择ip（主机ip）和dataspace_name（磁盘分区名）两个字段，才能正确生成每一个磁盘空间的使用率指标。

  另一种适配使用的场景，是配合数据的过滤条件规则，获取到某个最值数据所对应的数据的指定属性信息。同样举个例子，对于获取到的一个时间周期内某个应用集群下的所有主机的cpu使用率，如果需求是要获取到其中cpu使用率最高的ip地址信息，则可以通过此规则配置key的分组字段是时间字段（默认自动会按时间分组，无需配置）及应用集群名（app_name），配置value字段是ip地址字段（ip），统计规则是“等于value值”，同时在数据过滤规则中，配置为cpu使用率字段（cpu_use）的操作符为“等于最大值”。

• 等于最大（最小）value值

  最值统计是一类常用的统计规则，即按分组规则统计组内的数据某个字段的最大（最小）值。例如统计一定时间周期内各个接口调用的最大耗时，就是一个典型的最值统计场景。根据业务统计的需要配置指标的key字段为应用集群名（app_name）和接口名（intf_name），指标value字段配置为获取耗时字段（cost），统计规则是“等于最大value值”。

• 等于value平均值

  均值统计是一类常用的统计规则，即按分组规则统计组内的数据某个字段的均值。例如统计一定时间周期内接口调用的平均耗时，就是一个典型的均值统计场景。根据业务统计的需要配置指标的key字段为应用集群名（app_name）和接口名（intf_name），指标value字段配置为获取耗时字段（cost），统计规则是“等于value平均值”。

• 累加value值

  累加value值是对原始数据某个字段数据的累加统计。

  例如某个应用集群包含多个应用实例，每个实例在每分钟都会输出服务调用请求量数据，而我们所需要展示的是这个应用集群的总服务调用请求量时，就可以使用这种规则。配置统计分组key字段是应用集群名（app_name），value字段是调用请求量（call_count）,统计规则为“累加value值”。

• 去重获取所有value值

  去重获取所有value值是对原始数据某个字段中的字符串信息的整合获取。

  例如在运维分析场景中，要获取实时（1分钟内）接口调用耗时超过15秒的所有接口名称，可以使用该规则。配置统计分组key字段是应用集群名（app_name），配置数据过滤条件是接口调用耗时（cost）大于15000（毫秒），value字段是接口名（intf_name），规则是“去重获取所有的value值”。该规则会将所有调用超过15秒的接口名称去重后形成逗号分隔的清单作为指标值输出。

• 去重获取value值数量

  与去重获取所有value值类似，去重获取所有value值同样是对原始数据某个字段中的字符串信息的整合获取。源于需求中需要统计的是数量，而不是明细清单。在运维分析中时长会存在同一个对象在周期时间（1分钟内）多次输出信息的场景。
  例如基于接口调用日志的数据统计分析，高频的接口往往高达成百上千甚至上万次，当我们需要知道一个应用集群中到底有多少个接口存在调用失败时，需要对接口名称去重来统计数量。

  上述的场景可以配置统计分组key字段是应用集群名（app_name），配置数据过滤条件是接口调用结果（result）为-1，value字段是接口名（intf_name），规则是“去重获取value值数量”。该规则会将所有调用失败的接口名称去重后统计数量作为指标值输出。

• 统计数量

  统计数量是最常用的一类统计规则。根据业务需要调整指标key的分组字段，可以按不同的分组逻辑来对原始数据做各种维度的统计分析，结合原始数据的过滤条件，达到绝大多数统计目的。

• 统计比率

  统计比率也是常见的数据统计需求，模块支持按原始数据的某个字段的枚举值，自动生成各值所占比率的指标。
  例如接口调用成功率的计算指标就是个很典型的例子。配置原始数据中接口名（intf_name），调用结果（result）为key的分组字段，value字段是调用结果（result），统计规则是“统计比率”。按照这个配置，会自动根据调用结果（result）的成功（0）和失败（-1）自动生成分别的占比情况。
  根据上述的场景描述，相信很多人会发现，这个指标的配置实际上是会根据枚举值的不同生成两条指标的，而不是只生成了“成功率”这一条指标，“失败率”这个指标就成了一个副产品输出了。优点是在场景需求有需要时可以同时满足，但其实缺点更明显，会占用更多的存储资源……
  需要注意的是，在使用“统计比率”规则时，不要（也无需）通过数据过滤来去除不想统计的枚举值。例如只想统计成功率，于是想通过数据过滤的方式将调用结果（result）为失败（-1）的数据给过滤掉，那其实是把总数减去了失败数，统计成功比率就成100%了，失去了统计的意义。
  另一个需要提前考虑的点是，这种统计比率在字段枚举值相对固定时是可控的，但如果字段可能的值会非常多的情况下，每个统计生成的指标数量是与枚举值的数量一样多的，也就是可能会产生海量指标数据，对实时计算和下游的传输、最后的存储都带来巨大压力。所以在使用时需要特别慎重考虑，提前规划。

  举个例子，统计一个应用集群中的服务调用的分别占比的指标，如果这个应用集群中有1000个服务，那么理论上在一个统计周期最多就会生成1000条记录每个服务调用次数占比的指标数据，如果再加上调用成功率的占比的话，按调用结果为成功或不成功两类，就会有2000条指标生成。其他如统计数量等指标也类似，一定要提前预估好可能生成的指标数，避免出现不可控的“指标风暴”。

• TopN

  在发现上述统计比率或统计数量的方式可能存在海量指标生成的风险后，以前直接按所有枚举值统计数量或比率，再从表中捞取前10这样的实现方式就不太好用了。例如统计并展示调用失败率最高的10个接口这样的需求，如果接口数量高达数千个，那生成的指标的数量也必然是海量的，于是我们新增了TopN这样的统计规则。
  这个规则在配置key分组字段和过滤条件时与其他指标规则是类似的，但在配置value字段时有较大区别。TopN的计算对象属性字段（value）需要配置3段内容，分别是“统计对象字段”、“展示字段”、“TopN条数”，用#分隔。
  举个例子，假设要统计一个应用集群的服务调用耗时top10数据指标，可以配置key的分组字段是应用集群名称（app_name），统计规则是TopN，计算对象属性字段即value字段是“耗时字段”#“服务名字段”#10（cost#servie_name#10）,这样配置会输出10条指标数据，分别对应调用耗时top10的服务名。
  需要说明的是，TopN的指标规则并不适用于对周期时间内的先统计再排序的场景。例如一分钟内按接口名统计调用次数（或调用成功率），再根据调用次数（或调用成功率）进行TopN排序的需求，无法用该规则来实现。目前的实现这种场景的方式暂时只能是先按调用次数（或调用成功率）来对接口做分组统计，然后再利用入库后的数据，使用sql语句捞取，用order by进行排序。

  相对来说，上述的场景实现会比较难保证实时性和效率，入库数据量也会大很多。这也是我们为什么在大力推动计算分析过程实时化的主要原因。对于上述的这个场景，后续我们也将实现相应的通用规则来满足实时化计算的支撑。

• 指标数据过滤规则

  在上述指标计算的计算规则中有提到对数据的过滤规则。数据过滤规则是指在同一种数据类型中，只针对某一类数据按指标规则进行计算，其他同类型的数据并不参与统计。这个过滤规则类似于sql语句的where条件，通过对各个字段的条件判断将数据过滤到业务逻辑所需要的范围。
  需要注意的是，应优先配置能过滤掉更多数据的判断条件。这与数据库的查询相同，尽量减轻后面判断逻辑的压力。
  数据过滤的规则项，与指标告警计算的规则项基本相同，放到指标告警计算中一并介绍，如需要了解的请跳转到对应章节即可。

2）复合指标计算

复合指标计算适配的场景包括以下几种：

• 基于打分规则的转换

  原始采集到的源数据中的性能值或简单指标计算输出的指标值，是贴近原始状态的。例如cpu使用率的百分比值，接口调用成功率的百分比值，服务调用总量的值等，都是相对真实信息的记录。但在很多分析场景中，需要对这些值进行转换处理。
  例如cpu使用率低于50%记为10分，使用率每提高10%则降2分，如果使用率大于95%则记为0分，这就需要对源指标的值做转换操作了。
  上述的这个逻辑我们可以通过一个打分规则配置来实现：
  
  
  平台支持配置多种打分规则，同一个打分规则可以用在不同的复合指标计算中。例如在上图的配置中，0<值<40的会被转换为10分，40<值<80的会被转换为20分。操作符可以有大于，大于等于、小于、小于等于等判断规则，对值的上下区间门限进行判断。
  需要注意的是，打分规则有执行顺序的判断，对于一个指标的值，会将所有规则按顺序执行一遍，最后输出分值转换结果。如果打分规则存在对值区间的重叠，则会以最后一条符合条件的规则来输出转换结果。
  配置好的打分规则在复合指标添加源指标时选用：
  

  这样在进行指标复合计算时，该指标的值会被按打分规则转换后再进入复合计算逻辑。

• 对异构源指标的组合统计

  在一些分析场景中，我们需要对多种不同的指标组合来完成统计分析。计算某个对象的健康度是一个典型场景。
  健康度的计算往往是基于多个黄金（核心）指标项，通过加权计算的方式来实现的（虽然加权计算这种方式存在太多主观思维，有拍脑袋的嫌疑，但在实际的场景构建中仍难以避免）。
  常见的健康度计算方式，是基于一个总分，按不同指标对目标业务影响程度的比重不同来设定权重值，然后对这些指标加权累加得到一个分值，用来代表当前评分对象的健康度。
  其中在设定各个指标的分值时会用到上面所说的“基于打分规则的转换”逻辑，实现从指标值到分数值的转换，不再赘述。针对每个复合计算用到的指标，可以设定一个别名，别名的定义包含字母和数字（如A1,A2,B3,C4等），在选择自定义规则后可以使用例如A1*0.2+B1*0.3+C1*0.5这样的四则运算公式来实现按权重的指标复合计算规则。
  复合指标的计算周期必须大于或等于源指标周期。例如需要对两个源指标配置复合，一个源指标的生成周期是5分钟，另一个是10分钟，那么复合指标周期必须大于等于10分钟，否则会出现在一个计算周期中源指标不满足条件的情况。
  在选择计算复合所需要使用的指标模板后，除了对指标值做分值转换，也可以对各源指标的字段取值做固定值限制。比如根据源指标模板（主机cpu使用率）生成了所有分析对象指标，但在复合计算时只需要对其中的某一个对象（某一台主机或某一个集群）进行复合计算，则可以在变量取值规则处限定需要过滤的字段取值。
  

  另外，由于一个源指标模板在不同的维度上存在多个指标值的情况，例如一个应用集群中包含多个主机对象，又或者复合计算的统计周期包含多个源指标的统计周期（例如：源指标统计1分钟一次，复合指标统计30分钟一次），那么对于这个集群（或更大事件周期）的统计分析来说是会包含有多个同源指标值的，根据需要可以使用使用指标规则获取“最大值”、“最小值”、“平均值”、“求和”、“求数量”等逻辑计算，将计算的结果代入复合计算逻辑。

• 对指标告警数据的统计

  在实际运维数据分析场景中，我们会用到对于告警数量的统计，并基于这个统计生成一个指标。
  举个例子，我们会需要获取一个应用集群中接口调用成功率低于85%的接口的数量，这里面就涉及到两次的统计规则。一次是计算得到每个接口的调用成功率，另一个是统计调用成功率低于85%的接口数量。
  实现这个需求场景，需要先配置一个简单指标，使用统计比率规则，就可以得到各个接口的调用成功率。对于接口成功率低于85%的指标，可以配置生成一条阈值告警规则，这样我们就可以得到了“某接口1分钟调用成功率低于85%”的告警数据。通过将告警数据输出到复合计算的前置kafka-topic中，配置一个基于告警的复合指标，规则是统计某个集群中这类告警的数量，则可以得到该应用集群里接口成功率低于85%的接口数量。当然，我们也可以在此对该指标配置一个告警，例如当符合条件的接口的数量大于10个时，应该才产生一条升级的告警（无限套娃，哈哈）。
  还有一种场景是基于不同维度的复合指标统计。例如在一个应用集群中包含很多的主机，一台主机有多个黄金（核心）指标项，例如cpu使用率、内存使用率、磁盘空间使用率等等。一台主机可能同时会触发多个告警（例如cpu和内存同时告警，又或者多个磁盘空间产生告警），而对于应用集群维度的管理需求，是需要知道这个应用集群里有多少台主机在当前正在告警。所以在统计应用集群维度的告警主机数量时，要按主机维度做告警信息的去重统计数量。而在统计应用集群维度的告警总数时，是不应该去重统计的。

  上述的不同需求场景，都能在复合指标计算模块的配置中找到对应的规则选项进行支撑。

• 两种指标数据的关联合并

  在使用关系型数据库时，常见的一个数据使用场景是根据两张表中的某些字段相等关系，对于两张表做关联查询，这样能输出一个包含两张表中字段的数据视图。
  在实时数据计算的场景中，我们同样会面临这样的需求。例如一个用户行为分析的场景，当某个连接使用VPN登录企业内网获得一个内网地址，再通过内网的防火墙访问某个DCN的设备时，我们能分别从VPN设备日志、DCN网的防火墙日志中分别获取到两段数据，即数据A（外网IP、外网端口、内网IP、内网端口），以及数据B（内网IP、内网端口，DCN设备IP，DCN设备端口），原始日志数据如下（已脱敏）：
  
  在安全防护运维工作中，经常面临的一个分析场景，是需要根据异常的DCN设备的访问行为，去反向查找这个访问的来源，再判断是否要将该外网地址在VPN设备端进行封堵。以前的做法是把两个日志数据关键字段提取后分别入库到两张表，再按表关联查询的方式来获取到访问来源外网地址。
  但这两个日志的数据量都是海量的，表关联查询的效率难以保证，因此我们在实时计算中实现了一类复合关联计算的逻辑。通过源数据中内网ip和内网端口这两个关键字段的一致性，将外网地址与DCN网设备直接建立关联输出为一条指标数据，这样在后续分析查询时可以更高效地完成检索工作。
  配置方式可以参考下面截图：

3）加工指标计算

2.2.3 告警规则

1）等于value值

2）包含value值（多个值以逗号分隔）

3）不包含value值（多个值以逗号分隔）

4）大于等于value值

5）小于等于value值

6）不等于value值

7）时间范围内

8）时间范围外

9）以…字符串开始

10）非以…字符串开始

11）以…字符串结束

12）非以…字符串结束

2.3 计算任务管理

2.3.1 实时计算任务类型

1）日志数据分割分词任务

2）第三方数据分割分词任务

3）数据加工计算任务

4）简单指标计算任务

5）复合指标计算任务

6）指标加工计算任务

7）复合指标关联计算任务

8）告警计算任务

2.3.2 实时计算任务运维支撑

1）上下游kafka主题

2）规则更新

3）规则刷新时间

4）指标上下线

5）指标最后生成时间

6）指标数据详情查询

2.3.3 计算任务实施注意事项

1）同类归并原则

2）重点保障原则

3）数据分流原则