随着Uber的业务飞速增长，软件架构的复杂度也与日俱增。大概一年多前，2015年秋季，我们有大约500个微服务，2017年初这一数量已增长至超过2000个。这样的增幅部分是由于业务该功能的增加，例如面向用户的 UberEATS 和 UberRUSH 等功能，以及类似欺诈检测、数据挖掘、地图处理等内部功能的增加。此外随着我们从 大规模整体式应用程序 向着分布式微服务架构迁移，也造成了复杂度的增加。
迁移到微服务生态总是会遇到独特的挑战。例如丧失对系统的能见度，服务之间开始产生复杂的交互等。 Uber工程团队 很清楚，我们的技术会对大家的生活产生直接影响，系统的可靠性至关重要，但这一切都离不开“可观测性”这一前提。传统的 监视工具 ，例如度量值和分布式日志依然发挥着自己的作用，但这类工具往往无法提供跨越不同服务的能见度。分布式追踪应运而生。
Uber最初广泛使用的追踪系统叫做Merckx，这一名称源自 全球速度最快的自行车骑行选手 。Merckx很快就帮助我们了解了有关Uber基于Python的整体式后端的很多问题。我们可以查询诸如“查找已登录用户的请求，并且请求的处理时间超过2秒钟，并且使用了某一数据库来处理，并且事务维持打开状态的时间超过500ms”这样的问题。所有待查询的数据被组织成树状块，每个块代表某一操作或某个远程调用，这种组织方式类似于 OpenTracing API 中“Span”这个概念。用户可以在 Kafka 中使用命令行工具针对数据流执行即席查询，也可以使用Web界面查看预定义的摘要，这些信息均从API端点的高级别行为和 Celery 任务中摘要汇总而来。
