InfoQ Geekathon 大模型技术应用创新大赛 了解详情
写点什么

有赞埋点质量保障

  • 2019-09-06
  • 本文字数:3265 字

    阅读完需:约 11 分钟

有赞埋点质量保障

一、常见问题

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


  • 事件重复 &丢失。重复是由于 SDK 自身或者前端开发疏忽的问题,导致相同事件重复发送;丢失可能是设备、网络原因,或者是开发者漏埋导致。

  • 事件参数错误。常见的情况有:”必传而未传“、”非空而为空“、”值类型不对“、”值内容不对”等。

  • 前端常见错误。比如值为“undefined”、“null”,通常是前端代码 bug 导致的值错误。

  • 事件断流。这种 case 经常发生,前端在做改造升级的时候,可能导致事件上报不规范,或者误下线。

二、保障机制

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


2.1 准确登记

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


  • 页面/组件类型,登记该元素的业务标识,以及是否有业务 ID。日志上报时,会有对应的字段记录该信息。

  • 事件信息,事件的名称/标识/描述,所属页面/组件,以及所处状态等信息。

  • 事件参数,属于该事件的一系列业务参数,比如一个点击事件的参数可能是被点击的商品的 ID。对于参数的登记,我们支持标识/类型/是否必传/参数结构的设置。其中类型支持 int/string/float/list/map,用于申明值内容结构;参数结构支持对复杂的数据类型,进一步定义其细节。


2.2 实时校验

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



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

2.2.1 完备性/扩展性

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


通过分析校验规则,抽象语义,我们设定以下语法(示例)


{    "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 指的是整体上,会有个最严重的状态汇总。



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


{    "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":""}
复制代码


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

2.3 定时监控

除了上线前的把关,事后的监控也是很有必要的。从质量角度,关心规范的实际约束情况;从流量角度,特别关注事件断流和异常波动情况;另外,业务上有很多约束,也需要去做监控。



基于实时校验结果,我们做到分钟级的质量和流量监控,在业务层面,会有小时级的个性化监控。


监控的“低误报”是一个很重要的考虑点,泛滥的监控等于没监控,在这点上,我们对监控做了一系列优化,如设定流量门槛、结合历史流量饱和度判定断流等。

2.4 专项优化

发现问题是手段,解决问题才是目的。


对于质量问题,会反馈到业务方去整改;除了业务上,还有许多基础 SDK 或开发上的通病问题,需要单独去做分析,成立专项,集中整改。比如 SDK 的重复率和丢失率问题,需要具体分析问题,推动底层优化。


这类工作主要是:问题分析>追根溯源>确定解法>持续跟踪。这里边涉及到许多特定场景的细节问题,就不展开讲了。

2.5 评估模型

如何去评估质量状态,是一个值得深思的问题。如果不能正确评价,就会摸不清重点,不知道如何优化,以及状态是在改善还是恶化。我们的衡量维度目前是这样的:



需要注意的是,各维度的权重,不应该是一成不变的,而要随着问题的重点而调整;甚至考虑的问题,也要不断去做优化,加入新的考量点。


有了一套这样的评估模型,质量的状态就可以以“分数”的形式直观地呈现。对于问题的关键点,也可以有重点有方向地去解决。

2.6 质量中心

日常的质量问题,需要统一的呈现和管理,便于业务方有整体的感知,集中解决。



此外,对于汇总信息,也会以日报/周报的形式提醒到。

三、现状 &规划

在以上介绍的一整套体系化的质量保障工作下,有赞的埋点质量有了大幅度提升。从状态未知到数字化的衡量;从缺少管理到集中化的呈现,并能提供优化辅助功能;从“不及格”的低质量到绝大部分问题被解决,质量问题已经不是业务分析的绊脚石。


我们的质量保障工作已经取得不错的成果,并形成良性的循环。但是还有许多可以优化的点:


  • 支持更丰富的校验功能,将复杂的校验配置可视化

  • 结合流量预测做监控告警,优化误报率

  • 评估模型优化,结合现状,调整维度和权重

  • 更完善的质量中心,集成快捷的优化操作

  • 明确奖惩机制,推动业务方主动关心和优化质量问题,让前文提到的闭环,顺畅运行通过这些方向的努力,相信有赞的埋点质量会持续保持高质量状态,更有力地为业务分析保驾护航。


本文转载自公众号有赞 coder(ID:youzan_coder)


原文链接


https://mp.weixin.qq.com/s?__biz=MzAxOTY5MDMxNA==&mid=2455759980&idx=1&sn=f3ba532ad6a3be84e82db6416f858733&chksm=8c686a49bb1fe35f501d98318a5fb23c3d6315b9e0945b7a92f13db18f76fcf93175be21e91e&scene=27#wechat_redirect


活动推荐:

2023年9月3-5日,「QCon全球软件开发大会·北京站」 将在北京•富力万丽酒店举办。此次大会以「启航·AIGC软件工程变革」为主题,策划了大前端融合提效、大模型应用落地、面向 AI 的存储、AIGC 浪潮下的研发效能提升、LLMOps、异构算力、微服务架构治理、业务安全技术、构建未来软件的编程语言、FinOps 等近30个精彩专题。咨询购票可联系票务经理 18514549229(微信同手机号)。

2019-09-06 08:002475

评论

发布
暂无评论
发现更多内容

🏆「作者推荐」【JVM性能分析】精心准备了一套JVM分析工具的锦囊(上部)

洛神灬殇

JVM 性能分析 jvm调优 7月日更

phpExcel:Excel数据导入导出最佳实战

devpoint

php Excel thinkphp 7月日更

禾木之变:2021我们该如何持续拥抱AI?

脑极体

Redisson 分布式锁源码 08:MultiLock 加锁与锁释放

程序员小航

Java 源码 分布式锁 redisson redison

使用 Open Policy Agent 实现可信镜像仓库检查

张晓辉

Kubernetes 安全 OPA

架构实战营 - 模块 8- 作业

泄矢的呼啦圈

架构实战营

架构实战营模块8作业

Geek_649372

架构实战营

数字政府建设如火如荼 区块链保证数据真实安全

CECBC

在线ASCII艺术字生成工具,SpringBoot banner生成工具

入门小站

工具

模块一作业

君子意如何

「架构师训练营第 1 期」

利用 Vector 从日志创建指标来提高系统的可观测性

哈德韦

日志 可观测性 Prometheus SRE vector

PowerShell 哈希表

耳东@Erdong

PowerShell 7月日更

设计消息队列存储消息数据的MySQL表格

Vincent

架构训练营

话题讨论| 帮朋友拼多多助力会导致银行卡被盗刷?

石云升

拼多多 话题讨论 7月日更

Apollo配置中心如何实现配置热发布

慕枫技术笔记

微服务 后端 配置中心

external-attacher源码分析(2)-核心处理逻辑分析

良凯尔

Kubernetes 源码分析 Ceph CSI Kubernetes Plugin

免费分享Java Web 开发的优秀图书

Java入门到架构

Java Java书籍推荐

5分钟速读之Rust权威指南(三十九)unsafe

wzx

rust

都说数仓是面向主题建设的,那数仓的主题和主题域又应该怎么划分呢?

白程序员的自习室

数仓 7月日更 数仓主题 主题域 数仓建设

Linux之find xargs

入门小站

Linux

jTDS 驱动导致 cpu 100%

顾五木

cpu占用100% 线上程序问题

【Flutter 专题】91图解 Dart 单线程实现异步处理之 Future (二)

阿策小和尚

Flutter 小菜 0 基础学习 Flutter Android 小菜鸟 7月日更

学习总结 IoT方向的小项目

万里无云万里天

学习 IoT

推荐系统的价值观(三十二)

数据与智能

价值观 推荐系统

区块链技术在“三资”监管领域的应用

CECBC

解读区块链在制药和物流管理中具备的优势

CECBC

数据仓库的基本要求

奔向架构师

数据仓库 数据架构 7月日更

吃药吗?AI造的!

脑极体

【得物技术】常用注册中心原理及比较

得物技术

zookeeper nacos Consul Eureka 注册中心

幸福来敲门

卢卡多多

幸福 7月日更

为什么搞一个副业项目如此之难?

张理查

  • 扫码添加小助手
    领取最新资料包
有赞埋点质量保障_技术管理_见风_InfoQ精选文章