11、分布式追踪：从开发到测试的全流程实践

分布式追踪：从开发到测试的全流程实践

1. 追踪的资源成本与平衡

在追踪过程中，最大的资源成本并非创建和发送跨度（span）的服务级成本。从大小上看，单个跨度很可能只是任何给定远程过程调用（RPC）中处理数据的一小部分。为了在性能和追踪所需的信息价值之间找到正确的平衡，你应该对创建的跨度、添加到跨度的数据量以及创建跨度的速率进行实验。

2. 追踪驱动开发的背景

当讨论将追踪作为应用程序或服务的一部分时，人们往往会“推迟”实施。在服务开发过程中，通常会有一个监控的层次结构。一开始可能没有任何监控，然后会迅速在代码中添加日志语句，以便查看特定方法的执行情况或传递的参数。在新服务即将发布之前，才会回去确定一些关心的指标（如错误率）并进行记录，然后将整个项目部署到生产环境中。

2.1 开发中不及时进行监控的原因

• 代码变化频繁 ：在开发过程中，代码不断变化，添加、删除或重构代码行的速度很快，编写监控代码变得非常困难，除非团队有很强的可观测性实践。
• 不清楚监控内容 ：在服务开发初期，不清楚应该监控什么。像错误率这类已知要关注的指标，通过代理或 API 网关等其他来源也能观察到；而机器级指标（如进程的内存消耗）通常由其他组件监控，而非应用程序本身。
• 日志和指标的局限性 ：日志和指标在捕捉服务开发初期已知的信息（如应该与哪些服务通信、如何在内部调用函数）方面表现不佳。

2.2 追踪的优势

追踪提供了一种选择，允许在开发