2025年后端埋点的例子（后端埋点方案）

大家好，我是讯享网，很高兴认识大家。

本文简单对后端埋点方案做了分析，但是还有很多未涉及的方面。主要用于学习交流和分享个人的经验

基本路线：filebeat + logstash 日志埋点分析

后端埋点的基本框架是通过filebeat+ logstash读取日志文件进行日志分析处理，这种方案是代码侵入比较低的一种方案。

使用的原因：

filebeat是一款开源的轻量级日志采集工具，主要用于整合各个路径下的各种不同的日志文件，并且统一输出到指定的输出点。

对于filebeat的配置较为简单，而filebeat提供的功能也十分有限，只能进行简单的日志采集工作，所以需要和logstash配和使用

logstash相对filebeat更强大，但是占用的系统资源也较多

首先配置指定的日志文件的路径供filebeat读取。

配置好 logstash 的过滤规则，input 及 output 方式，将 filebeat 和 logstash 对接到一起。

最后启动 filebeat 和 logstash ，开始进行日志文件的数据读取和写入。

后端埋点的优点在于，可以在采集需求发生变化时，修改服务端代码就可发立刻发布生效。能够有效地应对各种需求变化。相对地，前端埋点可能会遇到上线流程慢，用户不更新最新版本所导致的数据不准确。

但是后端埋点的缺点在于，只能收集前端请求后端的业务行为，而无法对前端存在业务意义的一些交互行为进行信息的采集。

对于产生日志的这一过程，又有几种不同的思路可以讨论：

目前基本上所有后端服务器接受的请求都要经过nginx转发，通过nginx的access.log日志，可以获取大部分最基本的请求信息。

同时可以通过配置中的来自定义日志输出的内容和格式：

优点：

缺点：

改进方案：

对于token , 请求body，请求参数这些信息，可以通过lua脚本，或者在logstash处理，或者抽取到数据库中2次加工，来解析其中的内容，提取更多有效的信息。

通过使用logback，log4j，slf4j 等日志框架在后端对应的业务请求接口进行日志信息的输出。需要对后端服务的java代码进行修改，但是修改量相对不大。

日志埋点的规范有一些文章可以参考：

优点：

缺点：

改进方案：

可以进行一些简单的封装，抽象出一些常用的类和方法，提高代码的复用性，和后续的可扩展性。可能延长开发周期。

使用神策的开源sdk进行后端的埋点，其基本思路和过程和日志埋点十分类似。要在项目中引入神策的javasdk，并对后端的代码进行修改，在其中使用sdk中提供的方法。

优点：

缺点：