一次基于日志服务(SLS)进行前端业务埋点的实现过程

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 一次基于日志服务(SLS)进行前端业务埋点的实现过程

项目背景

从阿里云官网上可以看出,日志服务(SLS)出现的初衷是为分布式系统的数据采集和分析来设计,所以对端上的支持并不是特别完善,不如其它面向端的采集平台那样做到开箱即用,向页面流向、性能指标都需要自己开发进行采集。本文分享一下项目上,端上业务封装的方案设计思路。

实现思路

首先要清楚的问题是我们需要进行什么分析?是着重分析业务功能的使用情况还是只需要了解基础的PV、UV数据?需不需要进行性能分析?需不需要进行链路分析?

明白数据采集的需求之后就是把需求拆解成指标,也就是最小采集单位。比如对于功能的使用情况这个需求,就可以通过公式 渗透率 = 功能使用人数 / 活跃用户数 把它拆解成2个指标。

有了指标之后我们再考虑该怎么通过(尽可能少的)埋点来采集这些指标

业务指标一般是产品经给出,然后技术同学来考虑怎么优雅、高效地实现。

下面以“某核心功能使用率”这个需求为例进行说明。

具体步骤

1 明确需求

某核心功能使用率(以下简称“使用率”)的可以通过公式计算得到:

使用率 = 100% * 使用该功能的用户数 / 使用产品的用户数

由于使用率只是一个数值,简单统计报表即可用来展示它的值。

但结合业务场景来看,我们很可能需要分析的是某次发布之后,使用率是否有明显变化,然后进行相关分析。比如 UI 交互优化后使用率是否有提升来验证改版的有效性,或者是否因为 bug 导致使用率下降等。

所以需要在时间维度上进行对比分析,折线图更加合适。

2 拆解指标

通过上面的公式看到使用率涉及2个指标:使用该功能用户数使用产品用户数

使用产品的用户数和我们可以通过统计用户 ID 来实现,也就是我们常说的 UV 指标。

使用该功能的用户数可以通过交互事件或者HTTP请求来统计,两者的区别在于,如果该功能比较复杂,涉及多个操作步骤或者多个请求,可以考虑通过进入功能的交互事件来统计,否则可以通过判断 HTTP 请求路径来进行统计。

3 规范埋点数据

虽然不同端的埋点方式不同,但是能在统一的报表上进行分析,所以需要事先定义好埋点规范,核心内容就是需要收集的字段(对应日志库的索引)

这里我们采用通用字段+业务字段结合的方式,以事件的形式进行上报。

其中通用字段包括但不限于事件名称、浏览器UA信息、代码版本、用户ID。。。

业务字段则根据具体埋点指标自行扩展,比如对于页面进入事件会收集页面路径,页面退出事件会收集页面路径和访问时间。

4 编码实现

由于我们项目存在跨端场景(web端和桌面端),所以编写了一个公共库,一方面是对 SLS 的 sdk 以及自行编写的客户端 sdk 进行了封装,让公共库来管理 sdk 的实例。另一方面以基类的方式规范了提供的事件函数。

除开上面两个原因,还有一些隐藏好处:

  1. 可以对一些原子事件进行更高层级的封装,比如进出页面事件、进出应用事件可以封装成一个。
  2. 可以随时替换底层实现,比如自行实现的 sdk,甚至是 SLS 的 sdk。

5 报表配置

最后一步就是配置报表了,虽然文档比较详细,也配有最佳实践,但还其实还是存在不少技巧的。比如:

1、建议优先在日志库提供的默认查询页面编写 SQL 进行查询分析,不光是为了调试,更重要的是系统会自image.png行推荐匹配的图表


2、折线图如果想绘制多条线,可以试试数据转换功能。

3、管道符“|”的过滤优先级要高于 where 子句。

......

总结

使用 SLS 进行业务埋点概括起来可以三步走:先需求文档,后代码实现,最后报表配置。

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
打赏
0
1
1
0
12
分享
相关文章
前端埋点校验工具:数据驱动的最后一道防线
数据埋点是企业决策的关键基础,但常面临覆盖率低、数据不准和故障难排查三大难题。本文深入剖析了这些问题的成因与影响,并提出“三维校验矩阵”解决方案:提升覆盖率至99.8%、降低错误率至0.3%、提速故障定位5倍。同时对比Split.io、Tealium、Sentry、板栗看板等工具优劣,为企业选型提供参考。迈向高质量数据治理,从精准埋点开始。
什么是Apache日志?为什么Apache日志分析很重要?
Apache是全球广泛使用的Web服务器软件,支持超过30%的活跃网站。它通过接收和处理HTTP请求,与后端服务器通信,返回响应并记录日志,确保网页请求的快速准确处理。Apache日志分为访问日志和错误日志,对提升用户体验、保障安全及优化性能至关重要。EventLog Analyzer等工具可有效管理和分析这些日志,增强Web服务的安全性和可靠性。
206 9
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
本文介绍了Java日志框架的基本概念和使用方法,重点讨论了SLF4J、Log4j、Logback和Log4j2之间的关系及其性能对比。SLF4J作为一个日志抽象层,允许开发者使用统一的日志接口,而Log4j、Logback和Log4j2则是具体的日志实现框架。Log4j2在性能上优于Logback,推荐在新项目中使用。文章还详细说明了如何在Spring Boot项目中配置Log4j2和Logback,以及如何使用Lombok简化日志记录。最后,提供了一些日志配置的最佳实践,包括滚动日志、统一日志格式和提高日志性能的方法。
2505 31
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
|
9月前
|
Logback 与 log4j2 性能对比:谁才是日志框架的性能王者?
【10月更文挑战第5天】在Java开发中,日志框架是不可或缺的工具,它们帮助我们记录系统运行时的信息、警告和错误,对于开发人员来说至关重要。在众多日志框架中,Logback和log4j2以其卓越的性能和丰富的功能脱颖而出,成为开发者们的首选。本文将深入探讨Logback与log4j2在性能方面的对比,通过详细的分析和实例,帮助大家理解两者之间的性能差异,以便在实际项目中做出更明智的选择。
865 3
Tomcat log日志解析
理解和解析Tomcat日志文件对于诊断和解决Web应用中的问题至关重要。通过分析 `catalina.out`、`localhost.log`、`localhost_access_log.*.txt`、`manager.log`和 `host-manager.log`等日志文件,可以快速定位和解决问题,确保Tomcat服务器的稳定运行。掌握这些日志解析技巧,可以显著提高运维和开发效率。
277 13
简单聊聊MySQL的三大日志(Redo Log、Binlog和Undo Log)各有什么区别
在MySQL数据库管理中,理解Redo Log(重做日志)、Binlog(二进制日志)和Undo Log(回滚日志)至关重要。Redo Log确保数据持久性和崩溃恢复;Binlog用于主从复制和数据恢复,记录逻辑操作;Undo Log支持事务的原子性和隔离性,实现回滚与MVCC。三者协同工作,保障事务ACID特性。文章还详细解析了日志写入流程及可能的异常情况,帮助深入理解数据库日志机制。
404 0
图解MySQL【日志】——Redo Log
Redo Log(重做日志)是数据库中用于记录数据页修改的物理日志,确保事务的持久性和一致性。其主要作用包括崩溃恢复、提高性能和保证事务一致性。Redo Log 通过先写日志的方式,在内存中缓存修改操作,并在适当时候刷入磁盘,减少随机写入带来的性能损耗。WAL(Write-Ahead Logging)技术的核心思想是先将修改操作记录到日志文件中,再择机写入磁盘,从而实现高效且安全的数据持久化。Redo Log 的持久化过程涉及 Redo Log Buffer 和不同刷盘时机的控制参数(如 `innodb_flush_log_at_trx_commit`),以平衡性能与数据安全性。
187 5
图解MySQL【日志】——Redo Log
图解MySQL【日志】——Undo Log
Undo Log(回滚日志)是 MySQL 中用于实现事务原子性和一致性的关键机制。在默认的自动提交模式下,MySQL 隐式开启事务,每条增删改语句都会记录到 Undo Log 中。其主要作用包括:
193 0
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log、原理、写入过程;binlog与redolog区别、update语句的执行流程、两阶段提交、主从复制、三种日志的使用场景;查询日志、慢查询日志、错误日志等其他几类日志
438 35
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log

相关产品

  • 日志服务
  • AI助理

    你好,我是AI助理

    可以解答问题、推荐解决方案等

    登录插画

    登录以查看您的控制台资源

    管理云资源
    状态一览
    快捷访问