例如 GA ，神策等，服务端接入，在各个接口调用过程中埋点，什么样的实现方式比较好？
目前看同事们有的在业务代码中间插一脚开个异步线程，有的在方法头上加切面拦截，写的都很临时。
我现在新项目要接埋点了，springboot 项目，请问有什么好方式？
13 条回复 • 2024-06-28 16:59:41 +08:00
 |
1
pvcxy18 2 天前
方法切面拦截，或者配置 Filter 过滤吧。 如果还是觉得侵入性强，可以考虑加个中间层
|
 |
2
lxw520zxl 2 天前
后端埋点就是埋一些业务数据，比如一个发红包事件（红包 id, 红包金额，发红包人...等等信息），就是侵入业务的，没法完全独立出去的，一般来说就是定义好工具类，工具类上用 @Aysnc 注解来实现异步
|
 |
3
gl3081 2 天前
埋点需求的数据比较多，没办法做统一处理。
不过买点的数据对象，这边建议你考虑下 builder 模式，编辑器一般都有插件可以自动给 class 生成 builder 模式 |
 |
4
diagnostics 2 天前
APM 的话一般是 Agent ，也算埋点。。。
|
 |
5
xueling 2 天前  1
业务埋点其实不太能做到你期望的与业务完全解耦的状态，一般来说通过切面或注解能实现的都是一些相对固定的、标准化的埋点，而对于大多数自定义业务埋点，由于上报参数和上报时机差异太大，所以并不适合这种相对固定的上报形式。
1 、服务端埋点方案设计一般侧重在埋点规范的定义、公共参数和业务参数的区分、统一的埋点的上报和接收方案等方面，确保在埋点上报出现问题后不会影响正常的业务服务就可以了，其实不用太纠结与业务代码的耦合； 2 、埋点接收后将数据写入消息中间件，与数据平台服务解耦，写入消息中间件的数据是一份可以被共用的基础数据（包括实时或离线使用的形式）； 3 、围绕着服务端埋点，大多数的数据指标我建议采用通用型流式统计的方案来实现，接入简单，无 SQL ，不容易出错，针对一份埋点数据可以灵活的实现各种自定义指标，运算性能更加强悍，更容易实现指标之间的交叉验证，能够很方便的的在页面管理每个指标的执行状态，可以了解一下我的开源项目： https://github.com/xl-xueling/xl-lighthouse ； 相比于 OLAP 数据指标的实现方案其实有很多好处，服务端埋点可能会经常变动，包括埋点的上下线或参数的变更，但 OLAP 需要维护全部的埋点序列数据，性能并不高，而且容易产生脏数据。 |
 |
6
Breadykid OP |
 |
7
xuanbg 2 天前
没听说过过服务端埋点。。。看需求描述的话，统一日志方案例如 ELK ，可以在日志抓取规则中实现提取关键信息的功能。
|
 |
8
uselessVisitor 2 天前 via Android
pinpoint apm agent
https://github.com/pinpoint-apm/pinpoint |
 |
9
coderzhangsan 2 天前
说个题外话，服务端埋点，建议直接接第三方，不然后面一大堆埋点需求，这都不算什么，运营数据核对是个麻烦事。
|
|
10
diagnostics 2 天前
@Breadykid 和 elastic 没啥关系，你没了解过 Prometheus + Grafana 这一套吗？
|
|
11
Breadykid OP @diagnostics #10 目前接的神策埋点，接入了他们 sdk ，需要调用 sdk 的方法来上报数据，Prometheus + Grafana 用不了
@xuanbg 接三方埋点的话，例如 ga （调用接口），神策（调用 sdk ），走日志获取埋点信息再上报不合适了，要另开应用单独做了 @uselessVisitor @xueling 你俩的 repository 对于这个服务端只上报 1-2 个事件，5-6 个参数的场景，有点重了 |
|
12
diagnostics 1 天前
@Breadykid #11 你仔细去搜搜可观测性怎么干的，和埋点差不多。
APM 一般都是通用的接口、用 Labe 区分，所以可以一个框架套所有。 一般的做法，对代码侵入少由高到低 - AOP：算是运行时织入吧 - CTW：编译时织入 - LTW：加载时织入 LTW 就是我说的 agent ，要埋点的时候加个启动参数带上 jar 包就好 |
Select Language