有赞埋点质量保障

一、常见问题

我们收集日志，目的还是为了分析用户行为，挖掘潜在价值，最终能优化产品体验。因此，“高质量”是最基本要求，这是保证分析效果准确性的基石。那么，常见的质量问题有哪些呢？

事件重复&丢失。重复是由于SDK自身或者前端开发疏忽的问题，导致相同事件重复发送；丢失可能是设备、网络原因，或者是开发者漏埋导致。
事件参数错误。常见的情况有：”必传而未传“、”非空而为空“、”值类型不对“、”值内容不对”等。
前端常见错误。比如值为“undefined”、“null”，通常是前端代码bug导致的值错误。
事件断流。这种case经常发生，前端在做改造升级的时候，可能导致事件上报不规范，或者误下线。

二、保障机制

针对埋点质量问题，我们尝试以下的保障机制，去解决。从业务开发的过程出发，在不同阶段提供服务支持，形成一个解决问题的闭环，保障日志处于高质量状态。

2.1 准确登记

业务需要根据“埋点规范”，规划好页面、组件和事件，并且在埋点平台上准确地登记。登记的信息越全，内容越细，越有利于自动化判定日志的准确性。目前我们登记的要素有：

页面/组件类型，登记该元素的业务标识，以及是否有业务ID。日志上报时，会有对应的字段记录该信息。
事件信息，事件的名称/标识/描述，所属页面/组件，以及所处状态等信息。
事件参数，属于该事件的一系列业务参数，比如一个点击事件的参数可能是被点击的商品的ID。对于参数的登记，我们支持标识/类型/是否必传/参数结构的设置。其中类型支持int/string/float/list/map，用于申明值内容结构；参数结构支持对复杂的数据类型，进一步定义其细节。

2.2 实时校验

做好了埋点的登记工作，开发就可以按照埋点方案做相应的开发了。如何快速验证上报日志的准确性，以及如何及时发现线上问题，是我们面临的直接问题。因此，我们做了实时校验。除了实时外，校验还需要考虑更新及时性/完备性/扩展性，避免规范或校验点的变更，带来频繁的修改代码或重启任务。另外，对于校验结果，还需要要做到可解释/可沉淀/可分析。

对于实时性，我们采用Flink开发校验模块，实现秒级日志校验；校验规则更新的及时性上，每分钟从埋点平台同步；可沉淀，校验结果除了推送给测试工具外，还会落到druid，用于后续分析。这些点的思路比较直接，就不赘述了。下面着重介绍下其他考虑点：

2.2.1 完备性/扩展性

完备性比较好理解，校验需要支持的，除了底层的埋点规范外，还有分业务的页面/组件的合法性、事件关联页面/组件的情况、事件参数格式内容等；扩展性的考虑点在于，校验点会持续不断完善，如何“以不变应万变”。这点上，主要思路有两个：

通过分析校验规则，抽象语义，我们设定以下语法（示例）：

代码语言：javascript复制

{
    "compare":"length",
    "condition":[
        "sdk_type",
        "in",
        [
            "iOS",
            "Android",
            "js"
        ]
    ],
    "assert":"true",
    "assert_fail":"ERROR",
    "value":36,
    "key":"uuid",
    "fail_msg":"did/uuid invalid",
    "require":1
}

本示例的含义：在sdk_type为iOS、Android或js的情况下，检查uuid参数，保证其是必传的字符串，且长度是36，如果不是则是ERROR级错误，错误信息为“did/uuid invalid”。具体字段说明：

key：参数名
value_type：参数值类型，默认为string，可指定int
compare：参数值检查方式，支持：
in：在一系列值内
length：对于字符串类型，指定长度
regex：对字符串类型，指定正则
value：参数值约束，对于compare=in是一个list；对于compare=length是一个数值；对于compare=regex是一个正则字符串
assert：检查结果需符合的值，true或false
assertfail：检查失败给出的异常等级，WARNING、ERROR、TESTWARNING
fail_msg：检查失败给出的错误信息
condition：检查前置条件，符合该条件才进行检查。
require：该参数是否必须，非必需情况下，若为空则不检查

开关&配置化

不同时期，校验关注的点可能是不一样的，不同阶段，校验的逻辑也会有所区别。比如初期在问题重灾区，我们对未登记的事件，没有直接发送异常告警，但后期会；在新校验点试验阶段，其校验登记会设定为WARNING或TEST_WARNING，而上线稳定后，可能会改成ERROR。因此，在实现中，就特别注意使用开关或配置，达到功能点的可定制。

2.2.2 可解释/可分析

校验发现了问题，是为了解决问题。因此对结果，要求是可解释的：在哪个层次，哪个参数发生什么样的错误，原因是啥；可分析的：分析不同级别、不同维度组合的异常分布、走势，便于集中定位和解决问题。

实现上，我们会对校验的层次、范围、结果等级作区分，对于每条日志可能产出多条校验结果（1 n）。其中的n，是指不同层次和字段，可能会有ERROR/WARNING/TEST_WARNING状态；1指的是整体上，会有个最严重的状态汇总。

简化后的校验结果格式，是这样的（包含多个关键维度，维度所处层级，问题字段、级别等）：

代码语言：javascript复制

{
    "log_id":"571531737e29586094318d3bf64e9407",
    "timestamp":1556174577000,
    "event_type":"click",
    "sdk_version":"0.7.7",
    "sdk_type":"js",
    "display_url":"url",
    "scope":"OVERALL",
    "field1":"",
    "field2":"",
    "status":"SUCCESS",
    "value":""
}

有了这样的校验结果，可以做很多事：埋点错误重灾区、错误趋势、原因分布等，实现可解释和可分析。