本文简单对后端埋点方案做了分析，但是还有很多未涉及的方面。主要用于学习交流和分享个人的经验
基本路线：filebeat + logstash 日志埋点分析
后端埋点的基本框架是通过filebeat+ logstash读取日志文件进行日志分析处理，这种方案是代码侵入比较低的一种方案。
使用的原因：
- 这两者都是开源免费使用的框架
- 这种日志采集方案发展到现在已经十分成熟，有大量的文档和社区实践分享。覆盖的数据处理技能很丰富，处理效果也十分不错。
- 并且在这些年已经有许多的使用案例，像是神策数据的文档中也有使用到该种方案进行数据的对接工作。
filebeat是一款开源的轻量级日志采集工具，主要用于整合各个路径下的各种不同的日志文件，并且统一输出到指定的输出点。
对于filebeat的配置较为简单，而filebeat提供的功能也十分有限，只能进行简单的日志采集工作，所以需要和logstash配和使用
logstash相对filebeat更强大，但是占用的系统资源也较多
首先配置指定的日志文件的路径供filebeat读取。
配置好 logstash 的过滤规则，input 及 output 方式，将 filebeat 和 logstash 对接到一起。
最后启动 filebeat 和 logstash ，开始进行日志文件的数据读取和写入。
后端埋点的优点在于，可以在采集需求发生变化时，修改服务端代码就可发立刻发布生效。能够有效地应对各种需求变化。相对地，前端埋点可能会遇到上线流程慢，用户不更新最新版本所导致的数据不准确。
但是后端埋点的缺点在于，只能收集前端请求后端的业务行为，而无法对前端存在业务意义的一些交互行为进行信息的采集。
对于产生日志的这一过程，又有几种不同的思路可以讨论：
目前基本上所有后端服务器接受的请求都要经过nginx转发，通过nginx的access.log日志，可以获取大部分最基本的请求信息。
同时可以通过配置中的来自定义日志输出的内容和格式：
优点：
- 后端不需要修改代码
- 只需要对一个日志文件进行分析，不会漏掉或忽略部分内容
缺点：
- 信息较单一，只能记录一些http信息，如果想要获取更多的信息，需要前端在请求头中提供。如果需要分析前端目前没有提供的的信息，可能涉及到前端的修改
- 可能会出现干扰性的数据，比如一些静态资源的获取，或者当nginx同时进行2个服务的转发。需要进行数据的过滤
- 对于前端没有传入的信息，可能出现缺失部分
改进方案：
对于token , 请求body，请求参数这些信息，可以通过lua脚本，或者在logstash处理，或者抽取到数据库中2次加工，来解析其中的内容，提取更多有效的信息。
通过使用logback，log4j，slf4j 等日志框架在后端对应的业务请求接口进行日志信息的输出。需要对后端服务的java代码进行修改，但是修改量相对不大。
日志埋点的规范有一些文章可以参考：
- 阿里云官方日志埋点的规范：https://help.aliyun.com/document_detail/54477.html
优点：
- 可以自定义日志输出的内容和格式，比如一些业务信息和数据，比nginx日志的信息更全面
缺点：
- 要修改后端代码
改进方案：
可以进行一些简单的封装，抽象出一些常用的类和方法，提高代码的复用性，和后续的可扩展性。可能延长开发周期。
使用神策的开源sdk进行后端的埋点，其基本思路和过程和日志埋点十分类似。要在项目中引入神策的javasdk，并对后端的代码进行修改，在其中使用sdk中提供的方法。
优点：
- 无需封装一套框架，可以直接使用
缺点：
- 需要修改后端代码
- 后续框架扩展性不高
- 商业问题？
版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/bcyy/44675.html