[Feature] 流量过滤聚合

[yuanyinyan]

Is there an existing issue for this?

• I had searched in the issues and found no similar issues.

Description

全量录制，按规则流量过滤聚合

Solution

可以全量录制写本地，走日志采集进Kafka，再接过滤聚合任务

Related issues

No response

Are you willing to submit a pull request to implement this on your own?

• Yes I am willing to submit a pull request on my own!

[1Windy]

1、读写接口回放的话，时效敏感的业务会产生大量失败，全量采集回放可能会噪声比较大，排查成本高；
2、按照接口力度回放，对于优惠交易类业务力度会太粗；

因此，希望可以根据接口入参或者响应的字段来进行打标，可以根据业务type标记进行流量过滤或者标记后，根据标记缩小采集流量范围，实现精准的流量采集和回归，降低噪声。

流量标记是否可完整的设计下，包括接口打标，入参响应字段打标，然后组合定向场景，可用于固化测试用例或者根据标记进行用例推荐，实现精准流量回放，这可能比常规的代码变动做用例推荐来实现的精准测试更容易在业务中落地，也便于开源。

[yuanyinyan]

全量录制的想法来自两个内部场景需求：

• 只想录制接口符合指定参数值的请求。包括指定请求参数，返回参数，中间动态方法的返回参数。
• 需要录制接口指定参数的全部参数值。保障用例覆盖完整。

现有的录制规则仅支持接口级别的黑白名单，录制的接口每分钟固定频率采样，不支持接口请求参数规则。
所以对于指定参数值，有可能会很久都采样不到。
录制的用例不支持按参数值检索，所以即使采样到了也无法快速查询。

总结下来主要是两个方面：

• 想录制的请求录不到
• 想查的录制用例查不到

因此，需要对录制规则做增强，细化到参数值，保证想录制的数据能被录到。录制规则和录制用例间需要有关联，方便查询和分类。

全量录制对于服务的影响确实不能忽略。并且生产也不可能所有实例全部录制，所以理论上一定有遗漏的。因此不必追求全量不遗漏，标题的全量录制就去掉了。

可以通过拉长录制时间来弥补参数值的不完整，录制时间越长，越能近似实现录制全量去重参数值。这种场景每个参数值只需要录制一条，可以录制规则限制仅录一条，也可以做自动固化用例工具，每种参数值取一条固化。 固化用例工具改动更小点。

可以率先增加的功能是 接口参数录制规则。返回参数和动态类参数规则情况比较复杂，可以先做请求参数规则，具体难点在后面分析。

录制规则增加接口参数规则

目的是保证想录制的参数值被录到。
详细的规则需求：

url规则：

1. http path
2. 参数规则（可选）

参数规则：

1. 规则生效位置：主入口，动态类
2. 参数位置：请求参数，返回参数
3. 参数类型：String，JSON，其他类型以及解析逻辑
4. 参数key
5. 参数value（支持正则）

避免规则冲突，和方便规则治理，需要对录制规则做一些限制：

• 黑名单的url可以先不支持参数规则。
• url规则不可重复添加，一个url规则可以添加多个参数规则。
• 动态类参数规则，返回参数规则，有可能会漏采主入口请求参数。先不支持。

下一步的录制规则需求：

• url规则增加 http method，方便区分rest api。
• 采样率绑定到具体规则，可以更灵活的控制录制数据量。现有的采样率可以作为应用默认采样率。采样率优先级：参数规则 > url规则 > 应用默认采样率。满足url规则 且 不满足参数规则 的请求，执行url规则采样率。

录制用例的查询

现在的用例只能通过url筛选查询，录制规则只有url一个属性，所以录制用例也就只有url一个分类属性。录制规则与用例之间天然通过url关联。
录制规则细化后，用例也会继承录制规则的属性，可以成为用例的筛选条件。
首先是规则id，可以支持用例溯源。其他的属性，比如key value，也很适合作为筛选条件。
对于用例的查询条件，可以进一步抽象为标签，再泛化一步，可以给规则打标，包括url规则标签，参数规则标签，key-value自动生成标签。
增加标签配置后的录制规则：

url规则：

1. http path
2. 参数规则（可选，支持多个）
3. 标签（支持多个）

参数规则：

1. 规则生效位置：主入口
2. 参数位置：请求参数
3. 参数类型：String，JSON，其他类型以及解析逻辑
4. 参数key
5. 参数value（支持正则）
6. 标签（支持多个）
7. key-value是否自动生成标签

返回参数录制规则难点分析

请求流程：主入口请求参数 -> 动态类请求参数 -> 动态类返回参数 -> 主入口返回参数。

需求就是要对这四个部分的参数做检查，满足条件的，保留整个请求的完整录制数据。各个部分的数据是各自独立上报。
难点在于后面的环节满足条件时，如何保证前面环节数据被采样。比如动态类参数满足条件时，主入口请求参数已经决策了是否采样，如何保证此时主入口请求参数已经被采样。
全链路录制采样也是一样的场景，各服务数据独立上报。采样模型与apm trace采样类似。

根据采样规则执行的位置，可以分为两类：头部采样和尾部采样。

• 头部采样，即在agent端就确定数据是否需要采样。录制频率，url黑白名单，都属于头部采样策略。
• 尾部采样，即数据上报之后再决定是否采样。常见做法是全量上报后再做过滤。

流量录制是需要保证链路数据的完整性，即采样连贯性。对于入口的采样规则，是天然保证连贯性的。返回参数规则保证连贯性就比较麻烦。

有两个思路：

• 头部连贯采样：因为请求参数和返回参数是分开独立上报的，所以无法保证连贯。解决方案就是将整个链路的数据攒到请求全部结束后再一起上报。但是这个方案对于全链路录制不通用，链路可能会经过很多服务，不可能等到全部结束再上报。头部连贯采样方案可以参考字节PostTrace方案。
• 尾部连贯采样：需要将这个url的数据全量上报，在存储后做过滤任务，或者进Kafka，通过延迟消费做连贯采样。

改动比较小的方案是整个链路的数据攒到请求全部结束后再一起上报。

[yuanyinyan]

关于标签

标签的结构：key:value

现有的标签：agent参数可以设置标签：-Darex.tags.xxx=xxx。
支持多个，作用范围是整个agent数据，最后会落到录制用例的tags属性，回放时可以做筛选。可以实现环境打标。

新加的标签：url录制规则标签，参数规则标签。作用范围分别时某个url和某个参数。可以实现更精准的流量打标。
所有的标签最后都是需要落到用例上，不同层次的标签可能会出现key相同的情况，所以有标签覆盖的逻辑：

标签的优先级：param标签 > url标签 > agent标签。优先级高的覆盖优先级低的，同级标签，后设置的覆盖先设置的。

录制用例有了标签之后，可以解决的事情：

• 根据标签搜索用例，解决用例查不到。
• 回放时选择用例标签，可以实现精准回放。
• 可以根据标签做用例推荐，比如每个标签取一条做用例固化。

[yuanyinyan]

需求总结：

• url白名单增加参数规则和标签配置。
• 录制用例增加关联字段：规则id。增加按标签查询用例。
• 回放增加标签过滤。
• 用例固化工具：每个标签取一条做固化或者导出

[yuanyinyan]

目前url白名单规则处理流程：

• 存储：表：RecordServiceConfig，字段：extendField，key：includeServiceOperations
• agent定时调storage接口查录制配置，录制时执行规则判断是否需要跳过。接口规则执行的方法 io.arex.inst.httpservlet.ServletAdviceHelper#shouldSkip。url白名单执行的方法io.arex.inst.runtime.util.IgnoreUtils#includeOperation

[yuanyinyan]

改动方案

1. 应用录制页面增加参数规则配置

录制详情增加tag筛选

2. url录制规则的存储
增加接口录制规则表：RecordUrlConfig，参数录制规则表：RecordParamConfig
字段示例：
RecordUrlConfig

{
　　"appId": "66edcf1843745adbac",       // app id
　　"urlRuleId": "88edcfa837bc5adbdd",   // url规则id
　　"httpPath": "/dbTest/mybatis",       // url
　　"tags": {                            // url tag
　　　　"tagKey1": "tagValue1"
　　}
}

RecordParamConfig

{
　　"appId": "66edcf1843745adbac",        // app id
　　"urlRuleId": "88edcfa837bc5adbdd",    // url规则id
　　"paramRuleId": "99edcfa837bc5adbdd",  // 参数规则id
　　"ruleTarget": "EntryPoint",  // 规则生效位置枚举：主入口:EntryPoint, 动态类:DynamicClass
　　"paramTarget": "Request",    // 参数位置枚举：请求参数:Request, 返回参数:Response
　　"paramType": "QueryString",  // 参数类型枚举：url末尾参数:QueryString, body参数JSON格式:JsonBody
　　"valueRuleList": [           // 参数值规则
　　　　{
　　　　　　"key": "keyA",       // 参数key
　　　　　　"value": "order.*"   // 参数value正则表达式
　　　　}
　　],
　　"tags": {                    // 参数规则tag
　　　　"tagKey2": "tagValue2"
　　},    
　　"autoKeyValueTag": true      // key-value是否自动生成标签
}　

3. url录制规则的查询
agent定时查询配置的接口，需要增加查询url录制规则。AgentRemoteConfigurationResponse增加字段：recordUrlConfiguration。
配置查询接口：com.arextest.storage.web.controller.config.AgentRemoteConfigurationController#load

tags可以不用传给agent，在用例存储前做关联查询即可。agent不需要关心规则标签。
录制规则需要保证向后兼容，需要将extendField的url规则拼装成RecordUrlConfig。

4. url录制规则的执行
agent接口规则执行的方法 io.arex.inst.httpservlet.ServletAdviceHelper#shouldSkip

现有规则是先执行url白名单规则，后执行黑名单规则。最好改下顺序，先执行黑名单，后执行白名单。
agent上报需要增加透传规则id，从request取出参数，遍历参数规则，符合采样规则的将urlRuleId和paramRuleId存上下文context，在整个链路的录制上报中都需要带上规则id。

采样率限制的RecordLimiter，key需要从path改为urlRuleId或paramRuleId。
执行采样率的方法：io.arex.inst.runtime.config.Config#invalidRecord

5. url录制规则与用例关联
agent上报的录制用例中带了规则id，落库前需要用规则id查出标签数据，或者按参数自动生成标签。所有产生的标签可以存redis，在录制详情页面供选择。
保存上报用例方法：com.arextest.storage.service.AgentWorkingService#saveRecord

录制详情列表、录制id列表都需要增加查询入参tags。实际调用的storage查询方法都是支持tags参数，所以只需要保证tags从页面请求一直传到storage即可。
录制详情的查询方法：

• com.arextest.web.api.service.controller.ReportQueryController#aggCountRecord
• com.arextest.web.api.service.controller.ReportQueryController#listRecord