网易云音乐全链路跟踪系统实践-CSDN博客

本文链接：https://blog.csdn.net/weixin_42032431/article/details/107692087

本文详细介绍了网易云音乐全链路跟踪系统的设计与实践，包括调用栈与监控、服务梳理、全局质量定位以及平台、业务和数据的整合。系统旨在提供低消耗、应用透明的实时监控，通过多维度分析实现快速问题定位。文章涵盖了从目标设定到系统架构、功能特性的逐步实现，以及未来的发展规划。

摘要由CSDN通过智能技术生成

昨天的分享会，听我们公司技术大佬分享。收获超多！

经过大佬允许后上传，除了大佬的独家干货，还有我自己的小见解。

欢迎一起讨论~~

本文全面讲述了云音乐全链路跟踪系统的设计思想，实践路线，以及在技术选择与功能迭代方面上思考总结。全文包含五个章节，每个章节完整表达了迭代周期的主要目标及所要解决的问题与思路。

导言

为什么我们在三年前要立项做这个系统？当然是我们遇到了服务问题。当时最明显的问题就是，随着我们的服务化拆分越来越多，服务间调用关系越来越复杂，我们已经完全无法跟踪系统的调用关系，某个链路出了问题，我们无法追溯，甚至那时候我们也没有一个统一的日志查询平台，我们需要不断的登录到不同的主机上去查询日志，可以想见当时的开发人员的生存环境是多么的恶劣。所以，我们迫切的需要一个全链路跟踪的系统，我们认为有了全链路跟踪，我们就能快速进行问题定位，异常排查，错误处理，性能优化了。

在系统建立之初，我们总体上有两个大的方向，一个方向是全局视图，即从整体上知道全局服务的依赖关系拓扑。第二个方向是能查询任一请求的具体调用链路。

我总共分五章来阐述全链路跟踪系统的整个发展历程。每个章节包含了我们的目标及反思，以及我们对于为什么这么做系统设计的原由。

第一章调用栈与监控

首先第一章，调用栈与监控。

基于我们初期对链路系统的理解，调用栈和基础监控指标是必须的，因为只有有了调用栈关系，才能解决我们上下游调用无法串连跟踪的问题。基础监控是我们发现问题的底层保障。所以，我们就朝这个目标开干了。

一、开源APM比较

在这里插入图片描述

在做之前，我们评估了当前世面上的大部分开源APM。这些系统大致情况如上，各有优劣，但后续我们还是走了了自研的道路。

为什么走上这条道路？这与我们的目标、我自身的认识、我的期望有莫大关系，同时，也与云音乐的一贯风格有一点关系。

最后一栏Pylon，即云音乐全链路监控系统，这个是我们目前已经选择的方案及达到的能力，一并参与比较出来。

二、定义目标：低消耗、应用透明、实时监控、多维度分析

首先，我们做这个系统的底线是什么？即链路系统消耗要低，不能对业务系统产生过多影响，链路系统是锦上添花的事情，绝不能成为业务的包袱。在云音乐当前的用户体量下，trace日志量一定是巨大的，所以，实时的异步上传trace日志一定会消耗大量网络带宽，同时，链路collector端的稳定性也会对业务系统产生一定影响。要保证轻量级，保证可控，那本地异步输出日志是最切实的保证。所以，我们就采用了写本地日志并由DS收集，最终写入Kafka的方案来进行trace收集，从而摒弃掉了业务端直接上报的方案。当然，对于这种决策有重大影响的是另外一个系统的支持，即阿里的鹰眼。我们认为云音乐的体量已经不再适合直接上传trace日志了。

我们将所有的trace采集集成在中间件（包括RPC及各种存储系统）这一层，来屏蔽掉对业务方的耦合。我们定义了我们自己的私有协议。当然，最近大部分开源APM系统都支持了opentracing协议。后续如果有必要，我们也会考虑支持上。支持的好处在于，我们可以使用开源的采集客户端来丰富化、多样化我们对各种组件的trace支持，同时使用自己的后端处理系统来提供强大的数据分析能力。

当然，我们基于应用名、链路名、主机IP等多维数据查询需求，使我们选择了ES作为底层存储系统。为了获得实时的数据聚合能力，我们首次提出使用Flink来解决流式处理问题。

这样，所有组件都齐备了，现在就需要考虑如何设计我们的系统了。