分布式追踪:概念、挑战与解决方案
1. 分布式追踪的起源与早期困境
在过去很长一段时间里,人们理解生产软件主要依赖于两种遥测数据:日志数据和时间序列统计(即指标)。指标能让我们知道计算机内部“出了问题”,而日志数据运气好的话能让我们明确具体问题所在。
然而,随着软件发展,情况发生了巨大变化。软件不再仅依赖一台计算机,而是被拆分成众多独立运行的微服务,分布在全球的数据中心的数百万台计算机上。每个终端用户请求都涉及众多进程,单台机器的日志和统计数据只能反映部分情况,这让我们在监控和理解软件运行时如同“盲人飞行”。
2005 年初,有人开始接触分布式追踪。当时在谷歌 AdWords 后端基础设施团队工作,面临着巨大的外部负载压力,且很多基础设施都需自行开发。一次偶然机会,遇到了 Sharon Perl,了解到她参与的 Dapper 项目,这是一个分布式追踪系统。当时 Dapper 还只是一个原型,通过在谷歌内部 RPC 子系统和控制流包中传播几个 GUID 来追踪请求在不同服务间的流转。虽然尚未完全投入使用,但早期的概念验证表明其基本原理是可行的,普通谷歌工程师首次有希望了解一个网页请求在接触数百甚至数千个不同微服务的 150 毫秒内发生了什么。
经过一两年的努力,团队成功将 Dapper 部署到谷歌所有后端软件中,这是首次有组织在生产系统中大规模持续运行分布式追踪。但起初,Dapper 的使用情况并不理想,很难让人们使用并从中受益。后来,通过将相关 Dapper 追踪链接集成到谷歌工程师日常使用的工具中,才提高了其使用率和组织价值。
2. 分布式追踪的定义与作用
分布式追踪(也称为分布式请求追踪)是一种关联日志记录方式,
超级会员免费看
订阅专栏 解锁全文
6万+

被折叠的 条评论
为什么被折叠?



