自研实时计算模块介绍及运维数据应用场景实施
点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！
随着现场生产业务的不断壮大和发展，信息化系统建设的不断推进，业务链条越来越长，所涉及到的业务处理环节也越来越多。各类运营数据、运维数据都呈爆炸式增长。对于我们运维团队来说，以往通过将各类运维状态数据或性能数据通过各种自动化运维工具采集并存放到数据库，然后通过定时任务跑存储过程，或者通过程序捞取一定周期的数据来进行统计分析的方式，在当前环境下已是捉襟见肘。再加上现场构建运维分析场景的需要，为了更好的分析系统运行状态和更深入的多维运维分析，又纳管了云环境指标数据、业务数据、各类日志数据、业务链路数据等等都接入并进行关联分析，原有的离线（批量）计算模式已经完全不再适用了。为了解决上述运维分析的困境，我们自研了一套实时计算模块，在各类运维数据采集后、入库前实现对数据的加工、关联、统计、告警等计算操作。一方面避免在数据入库之后再捞出，减少对数据存储组件的依赖和压力，另一方面也大大增加运维数据分析的时效性，提升运维团队对系统异常状况的感知能力。值得一提的是，该自研实时计算模块的功能，并未与数据的业务场景做任何绑定，也并不是只能用于运维数据的加工和分析场景。通过对接任何格式的流式数据，均可实现各类数据的加工、统计、规则判断、关联、复合统计等等处理逻辑，满足不同的使用场景需求。
自研实时计算模块（以下简称DOMP模块）基于FLINK开源框架构建。与市面上多数的基于FLINK的通用实时计算有所不同，DOMP模块在单个计算任务中可配置对多个指标的计算。这种架构模式的建立，来源于现场运维资源分配一般是偏小的。由于运维的价值输出不像业务系统或经营分析系统这样明显和受到领导重视（虽然发生异常或故障时带来的损失巨大……），所以我们需要考虑在有限的资源下支撑尽可能多的运维数据加工（分析），减少数据入库后的再处理量。基于上述的背景及需求考虑，我们主要构建了以下功能模块：
该子模块用于管理平台所使用到的各类PAAS层组件，包括FLINK、Kafka、Redis、mysql、ES、Oracle等。
这个功能模块实现对FLINK集群的界面话管理功能，支持对后台FLINK集群的新增、参数配置维护、删除等白屏化操作管理。（本期建设中尚未实现对后台FLINK集群的自动创建，需要在后台建好集群后，在前台配置将集群的属性进行维护，用于在集群中操作创建任务，后续会考虑支持自动化方式实现集群的创建场景，并通过前台管理对接）创建或修改FLINK集群属性时，可以设定部署路径、日志路径、节点地址、checkpoint等信息。这些信息用于创建或启动任务时的通用配置读取。1.2 Kafka集群管理
Kafka集群管理实现将后台搭建好的kafka集群及topic主题纳入到平台管理，记录集群及通道的版本、zookeeper连接、broker连接、分区、副本等信息。Kafka信息用于在flink任务配置时指定接入数据源及输出数据源配置。1.3 数据组件管理
与kafka集群管理的功能一样，将flink任务配置时需要指定的入库或入redis等数据组件的参数配置进行统一管理，方便任务配置时使用，一方面方便管理，另一方面也有利于在任务配置时根据数据组件配置的逻辑语义来选择。目前平台支持mysql、oracle、redis、es等数据组件的配置及使用。
2.1 数据类型管理
正如前述所说，运维使用的资源偏小，所以很多场景下都会存在资源复用，不同类型的数据时常会使用同一个数据管道来进行传输。并且数据打标的工作，上游也不一定会配合实现。由此，对于平台来说，如果在同一个接入源（kafka-topic）中包含有多类不同的数据，如何让不同的数据支持不同的计算规则就成为一个难题。数据类型的作用是为了在后续的数据加工、指标计算等场景中区分标识不同的数据，通过设定数据中的识别关键字的方式来实现。需要说明的是，对于平台自己通过采集获取到的数据，会在采集或分词时设定好数据类型标识，只需要通过“导入日志模板”方式即可自动生成数据类型定义。而对于第三方平台推送来的数据，需要配置两次数据类型，第一次用于标识源数据中的识别关键字，第二次定义一个数据类型标识，然后通过“数据加工”计算的方式来完成由源数据类型到带标识的数据类型的转换输出，这样在后续的指标计算中即可使用带数据类型标识的数据了，可以更好的提升指标计算的效率。数据类型配置时，支持从日志模板导入，也支持从kafka-topic中捞取样例数据来提取关键字及属性字段进行快速配置。2.2 计算规则管理
DOMP模块包含加工规则、指标规则、告警规则这三类实时计算规则。2.2.1 加工规则
加工规则是指针对原始数据的基于原始的字符串状态的加工处理，因此所有的字符串类型数据都可做加工规则配置。包含分词规则和数据加工两种。1）分词规则
分词规则在日志采集时需要配置分词，所以将计算规则的配置合并到日志采集模板配置流程中了，使其更符合场景使用流程。需要说明的是，由于分词规则是在FLINK平台上实现的，与数据的采集无关。因此是可以在不中断采集的情况下修改分词配置并生效的。另外，通过jdbc方式采集的数据，默认会自动在采集时按sql语句输出的字段做分词处理，不需要通过FLINK平台来做分词计算。但是，基于一些场景的需求，需要将数据库中某一些字段提取其中的关键信息生成新的分词信息用于后续的统计分析，则需要配置二次分词规则。而二次分词是需要通过FLINK实时计算的，在具体的场景实施时要根据需求来灵活应用。分词计算模块支持对原始数据及分词出来的数据做脱敏处理。对于需要脱敏的原始数据，必须配置分词，并在分词配置中勾选脱敏动作。分词计算后输出的结果数据中，不论是原始的日志数据还是分离出的关键字段数据，都会脱敏，且转换值规则具有统一性，以保障数据的可关联查询。2）数据加工
数据加工是对于原始数据所做的加工处理，使其满足后续的指标计算规则的格式需求或业务表达需求。数据加工功能实现的是两种数据类型之间的转换。即从数据类型A转换到数据类型B，所以转换前后的数据类型均需在数据类型管理中先行配置。数据加工的配置及处理过程中支持对原始数据（分词后）中的字段做过滤，即满足条件才做加工。
基于数据集加工规则
数据加工处理过程中，往往会碰到一种场景，即需要根据数据中的某个信息扩展关联其他的信息并添加到数据中，以方便后续的统计分析。例如原始数据中存在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）简单指标计算
简单指标是面向原始数据类型的统计计算，这个模块的设计思路是以数据类型为表，以数据类型中的属性字段为表字段，选择数据类型中的属性字段作为指标key字段，实现类似sql语句的group by的分组统计逻辑。简单指标计算在配置时需要指定统计周期，目前能支持到1,2,3,4,5,10,15,30（分钟）的统计周期，统计是按规整时间输出的，而不是任务的启动时间开始计时，这样是为了方便数据使用时的时间具有一致性。例如3分钟的统计周期，其输出的时间点就是按每个小时的0分，3分，6分，9分……51分，54分，57分，如此反复。另外，基于不同需求的统计口径要求不同，还将统计输出规整时间分为后向（默认）和前向（非默认）两种，支持对统计输出的时间归属向前或向后规整。例如按1分钟周期做指标统计时，如果是后向（默认）统计规则，则被统计数据中08:00:03这个时间点的归属统计时间是08:01:00，但如果是前向统计规则，那归属时间点则是08:00:00，需要现场按照各自的业务规则来进行选择。目前模块中实现的简单指标计算的分组统计规则包括以下几种：
等于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）复合指标计算
复合指标计算是区别于简单指标计算而言的，是指对同模板源指标数据（告警数据）基于同一时间戳的二次统计，或对异构源指标数据（告警数据）基于同一时间戳的二次统计。计算的源数据是经由DOMP实时计算所产生的指标数据（满足平台制订的指标数据格式，可以是简单指标计算的输出结果，也可以是复合指标计算的结果），或基于指标的告警规则所生成的告警数据（符合平台制订的告警数据格式）。复合指标计算适配的场景包括以下几种：
基于打分规则的转换
原始采集到的源数据中的性能值或简单指标计算输出的指标值，是贴近原始状态的。例如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）加工指标计算
加工指标的场景和数据加工的场景是类似的，但数据加工的对象是数据类型，而加工指标的对象是指标类型。在指标已经生成后，再根据指标所包含的关键信息字段进行转换或增加key规则中的关键信息字段。例如通过部署在主机上的agent采集到的cpu、内存等性能数据，通过简单指标计算生成了相应的性能指标，但如果要输出告警，还需要将指标里加入其归属的业务系统或责任人信息，这就需要与CMDB的配置数据库进行关联，为指标数据做信息扩展。另一个常见的场景是根据维表中定义的关系，将指标值进行转换，例如“-1”转换为“失败”，“1”转换为“成功”等加工，使输出的信息具有更好的可读性。加工指标计算的配置逻辑和数据加工是类似的，在此不再赘述。为什么我们有了数据加工，还需要做加工指标呢？这里有对计算资源消耗的考虑有关。相对来说，原始数据做加工要处理的数据量是巨大的。而指标是基于原始数据按某规则的统计输出，数据量只有原始数据的几分之一甚至几百分之一。所以在指标数据的基础上去做加工，计算量会小很多，需要分配的计算资源也可以小很多。在实际的数据加工分析场景中，也应尽量遵循少数据加工而多指标加工的方式来实现需求。2.2.3 告警规则
指标告警计算是针对前述简单指标、复合指标、加工指标等模块所生成的指标的告警规则配置及后台实现。在告警配置时，需要指定该规则所作用的对象指标，如果配置界面是由指标配置界面进入时，会自动填入对应的指标信息。告警信息以指标key和value中包含的各关键字段信息作为变量来配置告警的内容，具备灵活配置告警输出信息的能力。告警规则配置是以指标key和value中包含的各关键字段信息作为规则判断对象，告警规则支持配置多个条件，各条件的满足是与的关系，即必须所有条件都满足，才会产生告警。1）等于value值
判断指标对象字段的值与判断条件值是否相等，是常见的判断场景。例如判断某个接口调用的结果是否成功，通过条件判断result_code是否等于1即可。2）包含value值（多个值以逗号分隔）
判断指标对象字段的值在判断条件值的列表中是否存在。此类判断规则多用于指标的某个字段值存在多个的情形。例如某个告警需要针对3类业务编码进行设置，判断busi_code为10,11,12三种，如果每种配置一条告警规则，对于后台来说是会增加相应的计算量的。如果使用该包含value值配置，则可通过一条规则来实现配置逻辑。在这个示例中，如果指标字段busi_code的值是10，则满足条件要求，如果是13则不满足条件要求。包含value值规则是或的关系，即指标字段的值满足该配置的多个value值中的一个即满足该条件。3）不包含value值（多个值以逗号分隔）
判断指标对象字段的值在判断条件值的列表中是否不存在。该规则与上面的包含value值规则应用场景类似，用于判断指标字段的值不在规则配置的value值列表范围内。不包含value值规则中的多个值是与的关系，即指标字段的值与value值列表中的任一个都不相等。4）大于等于value值
判断指标对象字段的值是否大于等于判断条件值，是常见的判断场景。例如判断某个主机的cpu使用率大于95%时需要告警，通过条件判断该指标的value值是否大于等于95%即可。5）小于等于value值
判断指标对象字段的值是否小于等于判断条件值，是常见的判断场景。例如判断某个主机目录的磁盘空闲容量小于等于30MB时需要告警，通过条件判断该指标的value值是否小于等于30MB即可。6）不等于value值
判断指标对象字段的值是否不等于判断条件值，是常见的判断场景。例如判断某个应用的接口调用结果存在1，-1，-2，-3等不同的值，只有为1时才代表接口正常，如果要在该接口调用结果不正常时告警，则可选择该规则，判断该指标的value值是否不等于1即可。7）时间范围内
判断指标对象字段（必须是时间格式）的值是否在某几个时间范围内。该规则常用于对业务上的高峰时段、工作时段、非工作时段之类的限制。例如在非工作时间和工作时间需要设置不同阈值的告警类型，则可通过该规则将时段进行划分，按时间段做不同的告警条件判断。需要说明的是，时间范围内的判断是可能存在多个时段的，例如非工作时间的判断，可能是晚上20点到早上8点，但实际配置时是需要配置为20:00:00-23:59:59，0:00:00-08:00:00这两段的。另外也可根据提示以小时范围或只到分钟范围的精度来进行配置。当存在多段时间时是或的关系，即指标中的时间字段符合其中一个时间段条件即代表该规则项条件成立。8）时间范围外
判断指标对象字段（必须是时间格式）的值是否不在某几个时间范围内。该规则常用于对业务上的高峰时段、工作时段、非工作时段之类的限制。需要注意的是，当规则中存在多个时间段时，各段时间是与的关系，即指标的时间字段必须全都不满足这些时间范围，该规则项才条件成立。9）以…字符串开始
判断指标对象字段（必须是字符串）的值是否以某个字符串开始的。该判断条件场景比较少见，是对日志类数据进行指标化后，对其中某段信息进行判断的一种逻辑，属于偏项目化的场景。例如日志中的oracle数据库报错（或某个应用的业务报错），同一个大类的报错类型往往是以相同的字符串开头的，但后面的内容不一样，在日志分段分词时会把该报错类型作为一个字段，如果要对所有相同类型的报错都进行告警（或用于指标计算统计中的过滤条件规则），则可使用这种规则逻辑。10）非以…字符串开始
判断指标对象字段（必须是字符串）的值是否不是以某个字符串开始的。使用场景与上述的“以…字符串开始”类似，不再赘述。11）以…字符串结束
判断指标对象字段（必须是字符串）的值是否是以某个字符串结束的。使用场景与上述的“以…字符串开始”类似，不再赘述。12）非以…字符串结束
判断指标对象字段（必须是字符串）的值是否不是以某个字符串结束的。使用场景与上述的“以…字符串开始”类似，不再赘述。2.3 计算任务管理
对于已纳管的FLINK集群，支持在平台上创建计算任务、选择任务类型（主函数入口）、设定任务参数、输入输出流配置、数据存储组件配置等。FLINK的任务配置中有允许延时时间的配置，即当前任务在时间窗口统计时，允许延后多长时间来关闭窗口来等待延迟的数据，这个配置一般在指标计算中使用，减少因前端数据延迟对统计准确性带来的影响。但配置延迟时间又会造成指标延时输出，影响指标应用的实时性，因此延时是把双刃剑，需要根据不同场景的需要以及资源的情况来酌情调整。FLINK的任务支持在前台界面控制任务的启停，以及对任务所加载的计算规则的加载或下线等操作，保障在不中断任务运行的前提下上线或下线规则，或变更计算规则。在任务执行过程中，可以进入组件规则详情页查看当前任务所加载的规则列表，并可通过是否加载、规则刷新时间、指标最后生成时间（针对指标计算任务）等信息来了解规则的运行状态。点击规则列表操作栏中的“加载（下线）”按钮可控制任务是否执行该规则计算。对于指标计算类的任务规则，点击规则列表操作栏中的“详情”按钮，可查看当前规则计算所生成的最近指标数据，并可通过规则的关键属性信息进行检索。2.3.1 实时计算任务类型
目前DOMP支持的主要数据加工（分析）处理任务类型包括：1）日志数据分割分词任务
日志数据分割分词任务是针对现场自有的日志管理平台所配置采集（文件、syslog等方式）的日志数据的分词处理。一个任务中可以加载多个分词模板的的处理，对于一个企业中所含的成百上千种类型的日志，可以按照重要程度或流量大小拆分到不同的分词任务中执行，使运维管理更加有方便。下图为一个分词模板的示例：2）第三方数据分割分词任务
第三方数据分割分词任务的功能与日志数据分割分词任务基本相同，是对其他平台通过kafka-topic传递的第三方平台吐出的数据做分割分词处理。与自有平台采集日志数据的处理逻辑不同的是，自采集的日志数据会带有基于flume采集终端附加的日志属性信息，而第三方平台是没有这些信息的。所以在任务处理环节前部会有一个预处理环节，对数据做格式化转换，使其适配后续的分词加工流程。3）数据加工计算任务
数据加工计算功能针对需要对源数据做加工处理的场景，实现数据的实时加工，并输出加工后的数据。数据加工支持的规则已在“计算规则管理”一节中介绍，这里不做赘述。与分词任务相同，数据加工计算同样支持多任务执行，每个任务可以按分组管理的需要加载不同的加工规则。以下其它任务也具备相同的多任务管理和任务中多规则加载处理的能力，不再逐一说明。4）简单指标计算任务
数据加工计算功能针对需要对某一数据类型的源数据做分组统计的场景，实现数据的过滤及分组统计。简单指标计算支持的规则已在“计算规则管理”一节中介绍。5）复合指标计算任务
数据加工计算功能适用于需要对一种源数据指标或多种源数据指标，或基于指标的告警数据做复合统计的场景，实现数据的过滤、统计、四则运算等处理。复合指标计算支持的规则已在“计算规则管理”一节中介绍。6）指标加工计算任务
数据加工计算功能适用于需要源数据指标进行加工处理的场景，实现指标中关键字段信息、值信息的转换处理。指标加工计算支持的规则已在“计算规则管理”一节中介绍。7）复合指标关联计算任务
复合指标关联计算功能是多指标计算中的一类特定场景，基于两类不同的指标数据中的某一个属性字段相同的特性，实现对两条指标数据的组合生成一条新指标数据。复合指标关联计算支持的规则已在“计算规则管理”一节中介绍。8）告警计算任务
告警计算功能针对指标数据的值做阈值判断、动态基线判断、同环比判断等规则计算，并输出判断结果告警信息。告警计算支持的规则已在“计算规则配置”一节中介绍。2.3.2 实时计算任务运维支撑
在任务执行过程中，平台提供了一些方便运维的细节功能，在此说明其使用场景。1）上下游kafka主题
在任务管理界面中，各记录中会展示该任务的上游kafka和下游kafka的topic名称，通过该名称可以清晰的看出数据的流向。当运维需要检查任务是否正常运行时，可以通过对下游kafka数据的检查或监控来实现。如果某个实时计算任务没有按预期在下游的kafka获取到相应的输出时，除了检查任务是否正在运行，也可以通过到上游的kafka-topic按关键字捞取源数据来确认是否有符合条件的数据流入。2）规则更新
在任务管理界面中，每条记录的操作栏中有“规则更新”按钮，这个的作用是在任务不中断的状态下动态重新加载规则内容。由于一个任务中往往加载了多个计算规则（例如多个指标的计算、多个日志分词等等）。如果任意一个规则需要修改都要启停任务的话，会影响其他跑在同一个任务中的规则执行。所以，通过这个规则更新按钮，可以将规则重新加载到缓存中，使更新上线的规则或新增的规则生效，也可使下线规则失效，不再起作用。3）规则刷新时间
从任务管理界面，选择一条记录，点击“组件规则”按钮进入规则列表页时，可以看到每条规则都有个规则刷新时间。这个时间是指该规则重新被加载到缓存的时间。由于实时计算的后台程序是定时到缓存中获取规则的更新（5分钟一次），所以根据该刷新时间可以推导出该规则是否已在后台生效，并结合下游kafka-topic的数据输出、指标最后生成时间等信息来判断该规则是否已正常执行。4）指标上下线
在指标规则列表页中，每条规则都有“是否加载”的字段，以及在操作列中有“上线”、“下线”的按钮。这个功能用于实现将同一个任务中的部分规则暂时下线或重新上线的操作。运维过程中，如果需要对某个指标的配置规则进行修改，则需要先将该规则下线，修改后再重新上线生效。另外，在任务执行压力大的时候，也可以将部分规则先暂时下线，以保障更重要的规则执行的，降低时延。5）指标最后生成时间
与规则刷新时间一样，指标最后生成时间也在规则列表页中的每一条规则记录中展示。与规则刷新时间不同的是，只有指标计算类的任务（简单指标计算、复合指标计算、加工指标计算）才有该字段展示，用于标识该规则的最后一条生成指标数据的时间戳。结合这个字段中的时间，与本地时间的偏差，即可快速发现该指标计算规则是否存在延时现象。特别是对于配置为1分钟统计周期的指标，由于对实时性要求很高，所以一旦出现该字段与当前时间偏差稍大，就要快速介入运维。此处需要注意的是，不同的指标有统计周期的区别，例如30分钟统计周期的指标，在每个半小时的整点进行统计，如果时间偏差在30分钟内都是正常的。6）指标数据详情查询
如果是指标类的任务（简单指标计算、复合指标计算、指标加工计算），在规则列表页中，点击规则记录后面的“详情”按钮，会在下方展示该规则最近生成的指标数据。由于指标规则模板在一个统计周期中可能生成的实际指标数据量会非常庞大，所以展示所有数据是不现实的，也不应该展示所有数据，所以前台限制了只会查询展示200个指标实例的数据。可以通过对指标中不同关键字段的条件限制来对指标实例进行过滤，只展示运维需要检查的数据即可。通过查看指标生成的数据详情，可以对指标规则中特定目标数据的运行结果进行检查和监测。由于实时指标数据往往用于实时大屏的展示，当大屏中相应的指标数据未正常展示时，可以通过该功能检查相应的指标数据是否正常生成。当然，这个功能不是检查指标数据的唯一方法。如果指标规则在定义时选择了入库的配置，则可以通过在相应的指标数据表中进行查找并确认（但该方法只能在事后检查出是否生成了指标数据，无法在尽可能实时的时间里进行检测）。2.3.3 计算任务实施注意事项
在项目实施过程中，无论是日志分词任务，还是指标计算任务，最开始由于没考虑任务的划分问题，所有的规则都混在一起。这就导致出现高数据流量的规则拖累其他规则一起延时的状况。后来通过将开发任务分组功能，按不同的管理需要划分开，才较好的解决该问题。经过前期多个项目实施，我们积累了一些使用DOMP模块来满足现场运维数据应用场景的经验，供其他项目团队或后续使用该模块的同学参考。在做规则分组时，可以按同类归并原则，重点保障原则、数据分流原则来处理划分逻辑，尽量减少后期的调整。1）同类归并原则
运维场景所包含的数据加工需求是可能由不同的发起方（科室、项目、对口客户）提出的。建议能将规则做一定原则的划分，将同类（相同项目、相同客户、相同科室等）规则合并到同一个任务或一组任务执行。通过将场景规则分组后通过不同任务执行，并且以任务为单位来分配计算资源，实现较好的管理。2）重点保障原则
运维数据应用场景中有部分指标的需求对实时性要求非常高，例如用于实时大屏展示的需求，或用于实时监控告警的需求。这类数据计算需求应该尽量多带带任务通道执行，或将具有同样计算输出场景的规则合并到一组任务来执行，避免被其他计算规则的数据量影响造成延时。3）数据分流原则
划分到同一组任务的源端数据，可能存在数据量过大，在一个任务中仍会处理不及时的情况，这时候需要使用数据分流方式来处理。通过将源端数据在采集时就分配到不同的kafka-topic中，可以按不同源端数据源的流量规划各个通道的数据流量大小，并以对应的任务分配资源来处理数据，以保证数据处理的及时性。DOMP自采集的日志数据可以通过采集客户端、采集服务端的分组功能来实现数据分流场景，如果是对接外部系统的kafka-topic数据，也可以使用DOMP的第三方数据采集功能，将同一个topic中的数据按不同的采集口径做二次采集分流后，再对接到下游的指标计算任务。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/129096.html
