请问服务端埋点，设计成什么样的实现方式比较好？

方法切面拦截，或者配置 Filter 过滤吧。 如果还是觉得侵入性强，可以考虑加个中间层

后端埋点就是埋一些业务数据，比如一个发红包事件（红包 id, 红包金额，发红包人...等等信息），就是侵入业务的，没法完全独立出去的，一般来说就是定义好工具类，工具类上用 @Aysnc 注解来实现异步

埋点需求的数据比较多，没办法做统一处理。
不过买点的数据对象，这边建议你考虑下 builder 模式，编辑器一般都有插件可以自动给 class 生成 builder 模式

APM 的话一般是 Agent ，也算埋点。。。

业务埋点其实不太能做到你期望的与业务完全解耦的状态，一般来说通过切面或注解能实现的都是一些相对固定的、标准化的埋点，而对于大多数自定义业务埋点，由于上报参数和上报时机差异太大，所以并不适合这种相对固定的上报形式。

1 、服务端埋点方案设计一般侧重在埋点规范的定义、公共参数和业务参数的区分、统一的埋点的上报和接收方案等方面，确保在埋点上报出现问题后不会影响正常的业务服务就可以了，其实不用太纠结与业务代码的耦合；
2 、埋点接收后将数据写入消息中间件，与数据平台服务解耦，写入消息中间件的数据是一份可以被共用的基础数据（包括实时或离线使用的形式）；
3 、围绕着服务端埋点，大多数的数据指标我建议采用通用型流式统计的方案来实现，接入简单，无 SQL ，不容易出错，针对一份埋点数据可以灵活的实现各种自定义指标，运算性能更加强悍，更容易实现指标之间的交叉验证，能够很方便的的在页面管理每个指标的执行状态，可以了解一下我的开源项目： https://github.com/xl-xueling/xl-lighthouse ；
相比于 OLAP 数据指标的实现方案其实有很多好处，服务端埋点可能会经常变动，包括埋点的上下线或参数的变更，但 OLAP 需要维护全部的埋点序列数据，性能并不高，而且容易产生脏数据。

@pvcxy18
@lxw520zxl
@gl3081 看来都是异步或拦截，我封装下试试

@diagnostics elastic apm 有点重了，只是上报几个功能的数据，量不大

没听说过过服务端埋点。。。看需求描述的话，统一日志方案例如 ELK ，可以在日志抓取规则中实现提取关键信息的功能。

pinpoint apm agent
https://github.com/pinpoint-apm/pinpoint

说个题外话，服务端埋点，建议直接接第三方，不然后面一大堆埋点需求，这都不算什么，运营数据核对是个麻烦事。

@Breadykid 和 elastic 没啥关系，你没了解过 Prometheus + Grafana 这一套吗？

@diagnostics #10 目前接的神策埋点，接入了他们 sdk ，需要调用 sdk 的方法来上报数据，Prometheus + Grafana 用不了

@xuanbg 接三方埋点的话，例如 ga （调用接口），神策（调用 sdk ），走日志获取埋点信息再上报不合适了，要另开应用单独做了

@uselessVisitor
@xueling
你俩的 repository 对于这个服务端只上报 1-2 个事件，5-6 个参数的场景，有点重了

@Breadykid #11 你仔细去搜搜可观测性怎么干的，和埋点差不多。

APM 一般都是通用的接口、用 Labe 区分，所以可以一个框架套所有。

一般的做法，对代码侵入少由高到低

- AOP：算是运行时织入吧
- CTW：编译时织入
- LTW：加载时织入

LTW 就是我说的 agent ，要埋点的时候加个启动参数带上 jar 包就好

@Breadykid 我的项目其实不重，有单机版本，可以不用集群版本那一套，一键部署，只是你没有用过，感觉上会重而已。我的项目优势是核心的统计运算方面的功能比神策强多了，不管是承载的数据量、计算性能、能够支撑的数据指标的数量、还是实时统计方面操作的便捷性。当然，如果你确实数据需求较少，也已经部署神策了，而且他们能满足需求，那就忽略吧~~

@diagnostics #12 我学习下，谢谢