Linux_google_trace_dapper
Author 晓兵
weixin: ssbandjl
公众号: 云原生云
title
另一个设计目标是跟踪数据在生成后可快速用于分析:最好是在一分钟内。 尽管对数小时前的数据运行的跟踪分析系统仍然非常有价值,但可用的最新信息可以更快地对生产异常做出反应。 真正的应用程序级透明性,可能是我们最具挑战性的设计目标,是通过将 Dapper 的核心跟踪工具限制在一个包含无处不在的线程、控制流和 RPC 库代码的小型语料库中实现的。 使用自适应采样有助于使系统可扩展并降低性能开销,这将在第 4.4 节中进行描述。 生成的系统还包括用于收集痕迹的代码、可视化它们的工具,以及用于分析大量痕迹集合的库和 API(应用程序编程接口)。 尽管 Dapper 有时足以让开发人员识别性能异常的来源,但它无意取代所有其他工具。 我们发现 Dapper 的全系统数据往往会专注于性能调查,以便可以在本地应用其他工具
图 1:代表用户请求 X 通过简单服务系统的路径。字母标记的节点代表分布式系统中的进程。
形式上,我们使用树、跨度和注释对 Dapper 跟踪进行建模
为了重建单个分布式跟踪中各个跨度之间的因果关系。 在没有父 ID 的情况下创建的跨度称为根跨度。 与特定跟踪关联的所有跨度也共享一个公共跟踪 ID(图中未显示)。 所有这些 id 都是概率上唯一的 64 位整数。 在典型的 Dapper 跟踪中,我们希望为每个 RPC 找到一个跨度,并且基础设施的每个额外层都会为跟踪树增加一个额外的深度级别
当线程处理跟踪控制路径时,Dapper 将跟踪上下文附加到线程本地存储。 跟踪上下文是一个小型且易于复制的跨度属性容器,例如跟踪和跨度 ID。 • 当计算被推迟或异步时,大多数谷歌开发人员使用一个通用的控制流库来构造回调并将它们安排在线程池或其他执行器中。 Dapper 确保所有此类回调存储其创建者的跟踪上下文,并且在调用回调时此跟踪上下文与适当的线程相关联。 这样,用于跟踪重建的 Dapper id 能够透明地遵循异步控制路径
除了简单的文本注释外,Dapper 还支持键值注释映射,为开发人员提供更多跟踪能力,例如维护计数器、记录二进制消息以及在进程内传输任意用户定义数据以及跟踪请求。 这些键值注释用于在分布式跟踪的上下文中定义特定于应用程序的等价类
- 原文作者:晓兵
- 原文链接:https://logread.cn/post/linux/trace/linux_google_trace_dapper/
- 版权声明:本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可,非商业转载请注明出处(作者,原文链接),商业转载请联系作者获得授权。