FinOps中的可观测性：将分布式跟踪超越监视

分布式跟踪作为研究微服务系统中性能问题的主要工具越来越受欢迎。我们最近的DevOps Pulse调查显示，组织跟踪的使用比去年增加了38%。此外，在尚未使用追踪的受访者中，64%表示计划在未来两年内采用追踪。
然而，许多组织还没有意识到分布式跟踪有多大的潜力。事实是，一旦您的应用程序被检测出来，它就为包括开发人员经验、业务和Finops在内的许多过程打开了一个全新的可观察性世界。
许多文章讨论开发人员用例。在本文中，我想冒险探索业务和FinOps领域中较少讨论的用例以及相关的含义。

上下文传播：追踪背后的秘密

分布式跟踪的核心是“跟踪上下文”的概念及其在系统中的传播。这个概念在W3C跟踪上下文规范中被形式化，并在OpenTelemetry上下文传播、OpenTracing和其他行业标准中发挥核心作用。让我们回顾一下主要概念：

什么是跟踪上下文

跟踪上下文是跨服务边界移动跟踪信息所需的数据。它是一组全局唯一的标识符，表示唯一的请求，其中存在每个span（span是组成该请求的全部执行流的单个操作）。
跟踪上下文的一个重要方面是它不绑定到预定义的数据集。这实际上意味着您可以捕获任何额外的用户定义属性，您希望从应用程序中监视这些属性（使用正确的检测），以提供许多类型的可观察性。这种用户定义的数据有时称为行李，可以是HTTP请求的URL、数据库查询的SQL语句，也可以是几乎任何东西。

什么是上下文传播

上下文传播（有时称为分布式上下文传播）是通过分布式应用程序跨线程、组件、进程和服务捆绑和传输上下文的过程。这通常是通过HTTP头来完成的，遵循W3C跟踪上下文规范。检测库或自动检测代理通常在幕后负责上下文传播。
其优点在于，一旦在应用程序中传播上下文，就会打开一个额外上下文的整个世界，您可以收集这些上下文来支持更复杂的可观察性。为了充实这一点，让我们回顾一些来自business和FinOps领域的有趣用例。

FinOps的分布式跟踪和遵从性

生活在当今云原生世界的公司越来越多地使用共享资源和基础设施来运营他们的业务。这些资源可以包括计算、存储、网络或许多其他资源。这些组织面临的一个相关挑战是跟踪相关的资源利用，并将其归因于各自的业务单位或产品线。资源归属是有效的FinOps的关键，因为它决定了业务单位的成本结构。
此外，在当今的许多SaaS业务模型中，操作多租户系统需要将资源成本归因于租户的能力。此外，SaaS业务通常对每个租户采用速率限制，以避免影响在共享资源上运行的其他租户的服务可用性水平。例如，限制速率的多租户存储据说每年为云供应商节省数亿美元。
不幸的是，虽然后端组件知道低层资源信息，如CPU和内存利用率，但它们通常缺乏关于触发请求的业务或租户的高层上下文。然而，通过注册分布式跟踪，该业务单元、产品或租户的唯一标识符(ID)可以向下传播到后端和基础结构。然后，这只是一个通过该ID聚合资源利用率数据的问题，以获得每个产品（或其他业务实体）的利用率。

资源归属也有助于内部能力规划过程。了解给定的产品或业务线消耗了多少资源可以帮助规划所涉及的基础结构的任何必要扩展，使其与相关的业务增长目标保持一致。
数据隐私遵从是组织面临的另一个常见问题，特别是根据GDPR和CCPA。和以前一样，经常出现的问题是低层存储通常不知道用户上下文。分布式跟踪可以将用户ID从前端层向下游传播到后端和数据存储层，这样就可以根据它来验证数据访问，以实施数据隐私策略。

从共同基础设施到共同实践

随着越来越多的组织为了监视目的而对其应用程序进行检测，上下文传播正在成为一种常见的基础设施。
这一演变的下一步是从作为通用基础结构使用转向作为通用实践采用。这一运动不仅受到开发人员和DevOps团队的影响，还受到对业务和FinOps进行监督的利益相关者的影响。这反过来将为组织内部的跟踪创造更多的倡导者，总体而言，这将加快所涉及系统的其他部分的采用和检测工作，并使用更多样化的数据集。
一旦这种实践变得更加普遍，我们可能会达到这样一个地步，即超越今天监控实践的激励可能会驱使组织冒险进入分布式跟踪–这些激励会对公司的最高或底线产生直接影响。