【分布式】资源与事务：可观测性的基本二重性

西格曼：我叫本·西格曼。我是Lightstep的联合创始人兼首席执行官。我在这里讨论的是资源和事务，这是可观察性的一个基本的二元性。我职业生涯的大部分时间都在研究可观察性。在我职业生涯之初，我在谷歌工作了九年，致力于谷歌的分布式跟踪系统Dapper，以及他们的高可用性监控和度量系统Monar。然后，Lightstep当然也专注于可观察性。我花了很长时间才到这里。我想出了一种与过去不同的思考可观察性的方法，这就是这次演讲的内容。

什么是事务?在右边，您可以看到某个系统的示意图。我们将从这个银行账户服务的角度来讨论一些事情，它处于一些更大的微服务架构，一些云原生架构中。本演示文稿中的事务不一定像银行事务。它只是指从系统的一部分传播到另一部分的任何请求，而不是整个请求。这是它所做的所有工作，直到它回来并完成它试图完成的一切。事务是应用程序中实际上“为最终用户做点什么”的东西，不管最终用户是人，或者在某些情况下，如果是Twilio，或者类似的东西。也许Twilio的最终用户实际上只是另一个运行脚本的程序。事务为用户或客户提供价值。

现在，特别是对于原生云，事务是分布式的。它们不一定非得如此，但通常是这样。它们可以用许多不同的粒度来描述。我的意思是，同一个事务可以用非常粗的粒度来描述，就像整个最终用户工作流一样。比如，如果你是一个像Lyft、Uber之类的乘车共享应用程序，那么整个请求乘车的流程可能会被视为一个事务。这是您仅有的粒度级别。您可能希望更细粒度地考虑服务之间的单个请求，比如HTTP请求。您可能会认为这是您想要用来描述事物的粒度，或者您想要更详细地了解一些甚至所有本地函数调用。然后我假设，从理论上讲，您可以根据整个系统中为完成一个事务而发生的每个CPU指令来查看一个事务。这些都是建模事务的有效方法。当然，当我们记下这个列表时，在这个粒度级别记录东西的成本会越来越高。事实上，它可能会变得如此之高，以至于会产生大量的开销，并开始影响事务。理论上，这些是不同的粒度。用于描述事务的遥测通常是跟踪和结构化日志。结构化日志类似于文本日志语句，但具有明确的键值属性。这些事情在这里有说明。您可以看到银行帐户请求有一个请求大小属性、一些HTTP路径、状态代码、延迟等等。这些是此模型中事务片段的理论属性。

我还认为，跟踪最终将取代日志记录。这需要时间，但对于事务来说，跟踪将取代日志记录。现在，我将通过向您展示跟踪模型比简单的单进程日志记录灵活得多来激发这一点。这里我不谈论2021，但这更像是放大了可观测性。这是一个日志记录语句。第22行有一些伪代码。这些日志语句中的每一条都定义了自己的表。这里的结构定义了一系列键，请求大小、路径、状态、延迟都在这里反映出来。这些列将成为此表的列。然后是从本地状态或其他地方提取的值。这组值将成为表中的行。

跟踪只是跨事务的连接

为了阐明这一点并使之清楚，您有这个日志语句，因为生产中运行的代码填充了这个理论表。当然，我并不是建议我们将这些数据全部插入MySQL或类似的东西，甚至不一定要将其插入到Elastic、Splunk或类似的东西中。只是有一个由日志语句本身描述的理论表，您可以这样建模。在某些情况下，您可以使用工具对这些表运行查询。跟踪的酷之处在于，这些日志记录系统执行灵活连接非常困难或不可能，或者非常昂贵或不可能。分布式跟踪在整个系统中进行连接。同样，如果这是您的系统架构，我们将要做的是实现所有结构化事件的连接，无论您将它们称为日志还是跟踪范围，这其实并不重要。您仍在描述事务。我们将使用跟踪上下文将所有这些服务中的结构化事件连接到一个更大的表中。其中有一个表，其中包含来自这些不同服务的列，在这里用颜色编码，服务A、B和D也在其中连接。然后，每个分布式事务表示该表中的一行。

这是非常强大的，因为如果您能够在这个概念模型中思考问题，就可以运行各种分析来找出跨服务边界的列之间的相关性。这反过来允许您了解一个服务中的行为如何影响另一个服务中的某些行为。具体来说，您可能会在服务a中的堆栈顶部有一个customer ID字段，并且您可能会发现，当银行帐户服务的延迟较高时，某些客户参与的时间比例较高。然后这就给了你一些东西，比如，那个客户是如何改变他们的工作量的，或者你做了什么?这些类型的连接实际上是理解跨服务边界的因果关系的一种非常重要的机制。如果您一直想知道分布式跟踪的所有麻烦是什么，那么在这个模型中，分布式跟踪实际上是结构化日志语句的一个连接。然后是一系列语义和查询功能。这就是事务。

资源是什么?

接下来，我们将讨论资源。什么是资源?资源是事务为完成其工作而消耗的东西。这个定义的一个副作用是，根据定义，资源是有限的。你的亚马逊账单是一种资源。同样，许多不同的颗粒。通过Kafka主题的吞吐量，Kafka集群只能支持这么多负载。当你到了负载的末尾，并且你已经消耗了所有的负载，事情会很快变得非常糟糕。你最终会遇到很多推回，很高的延迟，请求被丢弃，诸如此类的事情。类似地，CPU使用率也完全正常，直到不正常为止。如果您使服务中的CPU饱和，所有您认为理所当然的事情都会中断。更糟糕的是，进程的内存使用率直接崩溃。例如，您还可以非常精细地讨论单个互斥锁。如果你在一个锁上有很多争用，你最终会得到一个读锁，这个读锁应该是180纳秒，如果一个锁有很多争用，可能需要一百万倍的时间。这也会带来问题。这些都是资源类型。资源之所以成为一种资源，是因为它们能够跨事务生存，并且能够跨事务共享。共享资源是非常重要的，因为如果你不共享资源，你的系统将非常昂贵。在多租户、多请求环境中运行的全部好处在于，您可以更好地利用资源，并在事务中共享资源。这就是资源。

为了让它更直观一点，我为一个微服务、一个Kafka集群和一个互斥锁绘制了这些框。这完全是说明问题的。我相信有更好的方法来衡量这些东西的健康状况。对于一种资源，您要考虑的是该资源在某种程度上的剩余量。它是资源消耗量的指标。您可以看到CPU使用率会急剧上升，RAM使用率会急剧上升。您可以看到，使用者延迟或生产者延迟是Kafka集群运行状况的指标，或者您必须等待获取互斥锁的时间是互斥锁运行状况的指标。任何资源都有一些健康指标。我想在这里强调的是，这些都不是单个事务成功或失败的指标。当然，当CPU和内存使用率达到峰值时，事务会出现问题。这意味着表明资源的健康状况。我会谈谈为什么这是相关的。然后资源也有一堆标签。这其实很重要。

在我看来，这些标签或属性的用途是多方面的。当然，你只是想理解和分解。如果您看到这样的峰值，您可能希望按区域分组，或按集群ID分组，或类似的方式。那很好。您应该能够在时间序列数据库中执行此操作。更重要的是，这些标签是沟通资源和事务的通用语言。理想情况下，当事务跨越资源时，该事务会以某种方式对该资源进行注释。它可以作为从事务数据连接到资源数据的一种方式，反之亦然。这是一个非常强大的东西。稍后，当我们进入一个实际的例子时，我将讨论这个问题。

资源也是一个层次结构

我说过有不同的粒度，也有层次结构。这对于事务来说是正确的，但我认为更重要的是在这里强调这一点。您可能有一个Kafka集群，它本身有许多微服务。在这些虚拟机中，有一堆虚拟机。在这些锁中，有一堆互斥锁。这些东西也会上下波动。在资源环境中有层次结构，以及这些健康指标。

我们已经谈过事务了。它们是客户真正关心的工作。我们已经讨论过资源，它们是使事务做一些事情并在事务之间共享的东西。这些是相互依存的。下面是这些资源的图表。这些绿色的曲线旨在说明流入或流出这些资源并执行其工作的事务。您可以看到，在本例中，事务将转到不同的HTTP端点。在这种情况下，我们将讨论不同的Kafka主题。在本例中，读卡器和写卡器试图对互斥锁执行锁定。有不同类型的事务，我们希望当事务跨越资源时，使用该资源的标识符对其进行注释。如果这个主题是Y请求，那么根据不同粒度级别的模式进行事务，如果您想要了解资源和事务是如何交互的，那么对于使用Kafka实例状态的区域和集群ID对事务进行注释是非常有价值的。或者，对于这个端点，对于要在跟踪中用诸如主机名或容器ID、服务名称、版本之类的东西注释的事务。同样，您可以使用资源中的标记清空事务，并充当这两个世界之间的映射。这就是一个例子。绿色的东西基本上是痕迹。然后在资源中，您通常使用度量遥测、时间序列统计来表示这些资源的运行状况。不总是，但通常是。

资源和事务是完全、完全相互依赖的。这是一个非常重要的问题。也就是说，如果您的资源不健康，那么事务将受到很大影响。如果事务数量过多，资源就会受到很大影响。事实上，作为一个主题，持续集成最让我感到困扰的一点是，在不知道工作负载的情况下，代码甚至可以是正确的或不正确的。我认为那完全是海市蜃楼。我觉得CI很棒。当然，我们在Lightstep中使用CI。至少对于系统软件或后端软件来说，您可以知道代码是否正确的唯一方法是在实际工作负载下运行代码。因为工作负载实际上是语义的一部分，所有关于资源如何配置，甚至资源如何设计和实现的调优都在很大程度上取决于事务的实际工作负载。这不仅仅是你可能需要更多的东西，而是你可能真的想要一个不同的东西。我不喜欢人们太讨厌MySQL。我之前有点讨厌某些类型的数据，但是如果你的数据可以很容易地放在一台机器上，而且你只需要关系语义，那就太完美了。除了一些复制问题之外，它其实没有什么错。类似地，如果你想要一个真正的行星规模和便宜的东西，你必须离开这个模型，做一些其他的事情。从设计的角度来看，或者从代码的角度来看，直到您考虑事务性工作负载时，资源也不能被认为是正确的或不正确的。可观察性是理解工作负载如何影响资源健康的最简单方法之一，反之亦然。

说到相互依赖，应用程序的客户只关心事务。我的意思是，如果你有一次停电，有人试图写一份报告，特别是为一个非技术性的最终用户写的，他们真的一点也不关心你的资源耗尽这一事实。这不是他们的问题。这是你的问题，不是他们的问题。他们只关心自己的事务是否正确，并在合理的时间内回来。正确性，也意味着这不是一个错误。正确性和延迟是客户或最终用户关心的两件事，而不是其他。如何做到这一点取决于你自己。对于运营者(operator)来说，你唯一能控制的就是你的资源。按运营者，包括DevOps、SRE。软件的全部意义在于，我们不是坐在那里从客户那里获取事实，然后填写一些东西，然后作为一个人做一些工作。我们正在编写自动化软件。那个软件是靠资源运行的。

总体而言，运营者主要关注资源，因为这实际上是他们拥有的控制点。最终用户只关心事务。最终用户和运营者也以这种方式相互依赖。如果最终用户改变行为太快，可能会给运营者带来资源问题。显然，如果运营者最终做了一些损害资源健康的事情，那么最终用户就会受到影响。最终用户、运营者、事务、资源都以这种方式相互依赖。他们之间有这种关系。最终用户和开发人员，或者开发人员或运营者也完全相互依赖。我认为这是一件非常有趣的事情，对我来说，无论如何，这是一件深刻的事情。最终用户和事务、运营者和资源，这是他们倾向于思考的，因为这是他们可以控制和处理的。它们实际上是在工作负载本身中相交的完全不同的平面。

DevOps工程师/SRE要做什么?

我们到底在做什么?这听起来像个问题。有必要能够在这两个方面之间进行转换，跨越遥测类型、度量和跟踪，通过标记进行聚合，并自动进行转换。这是一种方法，您可以通过资源和轴心来了解资源的稀缺性或健康问题，以了解事务是如何变化的。或者，您可以从事务非常慢或返回错误开始，找出与此相关的资源，因为高延迟几乎总是处于争用状态的资源，无论是您的数据库，还是Kafka队列，或者其他什么。然后，要想理解为什么会出现这种情况，就要弄清楚一些工作负载是如何变化的，比如有人推出了新代码，使数据库调用的数量增加了100倍，这就是为什么我们的数据库变得缓慢。这是一件有趣的事。您经常会在事务处理速度缓慢、找到处于争用状态的资源，然后意识到有人将负载增加了100倍的情况下切换。同样，从事务到资源再到资源，或者从事务到资源再到资源。这真的很难，因为现在人们在前端集成度量和跟踪，但实际上需要在数据层集成它们才能实现这一点。这是一个非常困难的数据工程问题，因为数据实际上看起来非常不同。度量通常表示为时间序列统计数据，跟踪通常表示为结构化事件，不管它是否跨越日志，不管怎样，它基本上是一组结构化事件数据，而不是统计数据。很难在它们之间转换。标签就是我们这样做的方式。

最后，我做这件事已经15年了，我一直在想这件事。没有人应该是这方面的专家才能使用它。它需要某种直观的东西，并在日常工作流程中为人们带来这些见解。如果我们不能做到这一点，那么我们基本上没有成功地解决相互依赖问题。

服务级别目标(SLOs)

SLOs是一个有用的工具。我只想在资源和事务的上下文中简要介绍一下SLO。SLO是一个热门话题。我认为SLO就是目标。它们是关于一组范围限定为一组资源的事务的目标。资源和事务是思考SLO的一种非常好的方式。我认为“服务水平目标”一词，人们通常认为，服务意味着微服务。不是真的。如果你像我一样老了，你拿起电话，听到拨号音，服务水平是99.99%的时间都是这样，或者别的什么。它不一定是一个微型服务。服务级别只是说，事务有多可靠?这是否意味着他们不会经常出错，或者他们很快，或者你做了什么。您希望在某组资源的上下文中检查该服务级别。这实际上就是微服务的用武之地。你也可以为其他事情设置SLO，同样，Kafka队列，数据库，诸如此类的东西。通过这种方式，SLO可以表示这两种双重性之间的契约，一方是事务和资源，另一方是运营者和最终用户。我认为这是一种优雅的方式来思考为什么SLO在连接这两个不同世界方面如此重要和重要。

这在实践中是什么样子的?

我知道我到目前为止所说的都是理论上的。我决定用这些术语展示一个生产系统中真实事件的工作示例。它确实显示了一些产品截图的东西，但这不是演示或类似的东西。这只是为了帮助从概念上说明这在实践中是如何发挥作用的，特别是在Kafka停机期间。

下面是仪表板中的一张图表，显示消费者对Kafka队列的延迟，实际上是在Lightstep自己的内部系统中。这不像是一次需要发生事故或对客户有明显影响的停机，但这肯定是人们争先恐后地想弄清楚到底发生了什么。你可以看到，10点45分，一切都很好。然后他们变得不好了。经典的情况是，Kafka本身就是一个分布式系统。它是一种资源，显然出了问题，因为作为消费者，它做任何事情都变得非常缓慢。您必须等待很长时间才能从Kafka队列中获取任何数据。你想做什么?我认为一种选择是尝试分组，并以各种方式对其进行过滤。我们真正想做的就是说，这个资源发生了什么变化?这个资源有很多事务要处理，很多事务实际上就在这里。另外，一笔事务就在这里进行。本期与本期之间的事务发生了哪些变化?这就是我作为一个操作员想要知道的，因为这可能会给我一个线索，因为Kafka的代码没有改变。工作量发生了变化。怎样你应该可以点击这个东西。在这里，您可以看到查询。

您应该能够单击此更改，然后说，是什么导致了此更改?然后进入一个UI，我们说，好吧，这里是队列不满意的异常情况。这是它正常工作的基线。再次，我们只是放大看看这两个时期是什么样子。那么我们真正想做的是，从统计学上理解，这里的事务和那里的事务有什么不同?我们试图理解的不仅仅是Kafka不开心，还有这里和这里的工作量有什么不同。美妙之处在于有标签。Kafka队列有一个名称。有关的主持人都有名字。通过Kafka队列的跟踪也使用这些标记进行注释。我们实际上可以从这个资源加入到工作负载中，并回答这个问题。回到我刚才提到的那些大型SQL表，我们可以说，让我们看看通过这个特定Kafka队列的跟踪，因为这是大型表中的一列。让我们看看在这两个不同的时间窗口中通过特定队列的跟踪，并了解与此回归相关的其他因素。

我们看到的是，在这个拥有许多不同客户的多租户系统中，有一个客户的产品ID为1753，从占所有跟踪的0.8%增加到几乎占所有跟踪的16%。这在基线和回归之间大约增加了20倍。这真的很有趣。一些客户显著地改变了他们的工作量，而这正是我想要的。问题是，客户标签的位置太高了。Kafka队列中甚至没有。只有通过从资源转向分布式事务跟踪，我们才能自动理解在这个回归中涉及到一个特定的客户ID。我们通过扩展得到更多的细节，比如说，好的，我们又增加了大约20倍。然后，如果您愿意，我们可以查看样本跟踪，以明确了解该客户正在做什么。

我想说明的是，不需要写任何查询，就可以从这种感觉转到这种感觉。您不需要成为专家就可以从资源转向事务。现在，实际上很难做到这一点。总之，总的来说。我认为我对可观察性的看法是，我们不再将度量、日志和跟踪作为可观察性的重点。这只是原始数据。相反，我们允许运营者了解其应用程序在SLO方面的运行状况，了解其资源的运行状况，就像他们今天所做的那样。然后自然地在这两件事之间切换，而不必编写查询。了解事务工作负载如何影响资源，以及资源健康状况如何影响事务工作负载，而无需举手或做任何实际工作。

事务遍历系统，使用资源。用户不关心您的资源。类似地，DevOps不能对单个事务做任何事情。他们只能对自己的资源进行操作，至少不能手动操作。我们必须能够使用自然连接资源和事务的系统和提供者，以解决可观察性中最重要的问题，即是什么导致了这种变化?无论是我事务的变化，还是我资源的变化。在这个资源和事务的框架内，这就是我认为可观察性的真正方向。

但是，你提到了存储数据的成本。我认为，对于人们来说，这总是一次非常棘手的谈话。你在进行这些对话时有什么一般性的建议，这样你可以最小化成本，同时最大限度地提高观察力?

西格曼：现在肯定是个问题。关于这个话题，我有很多话要说。首先，我们想到的是，我们谈论的是事务还是资源?也就是说，我们是在谈论跟踪和日志之类的东西，还是更像是统计时间序列数据，比如度量?因为我认为这两类遥测的对话是不同的。我们发现，至少在我在谷歌工作的时候，还有Lightstep，它不仅仅是一个二进制的东西。你保存数据还是不保存?这就像，你一开始就做样品吗?你能把它从主机上取下来吗?您是否将其集中在广域网上?你储存多长时间?您存储它的粒度是多少?在精度方面，它是如何随时间降低的?当你看到组织在这方面变得非常成熟时，他们实际上在整个遥测生命周期中有不同的答案。我认为这是一个非常具有挑战性的问题，因为它取决于您所谈论的粒度。

我想说的主要一点是，如果一个组织没有能力在整个生命周期(包括网络)中分析其遥测成本，而网络实际上是生命周期成本中最大的组成部分之一，那么发送数据就是了。就像任何优化问题一样，你必须从这里开始。坦率地说，我认为很多组织都无法对其进行分析。您不能说应用程序的哪一部分导致了最长期的遥测成本。在你做到这一点之前，没有办法优化它。我从那里开始。那么对于已经这样做的人来说，我认为主要的事情是能够控制单个开发人员的成本，比如添加一行代码会给度量增加太多的基数。如果你做错了，每年可能要花费数十万美元。能够在中心位置纠正这一点，我认为是下一个重点。确保单个仪表线不能为平台团队带来无限的成本。

但是，我真的很喜欢你最后的例子，你经历了一个已经发生的事件，并在屏幕上分享。Ben提到了Lightstep，所以你可以看到它是如何工作的。我自己也用过。我觉得你能以如此快的速度找到一个真正的特定客户做某个动作并引发一个事件，这真是太令人惊讶了。我自己也知道，在我从事生产系统的职业生涯中，这种情况已经发生过很多次了，能够以极快的速度达到非常小的粒度级别是非常有效的。

在给定的两个时间间隔内，能够输出重要差异的web界面是什么?你想谈谈这个吗?你对此的想法，比如不同的界面如何帮助人们做得更好?这是件大事。

西格曼：这是一篇社论。我犹豫了一下，不想表现出来。我不知道还有什么其他的方式来表现它。如果我不展示一些东西，我觉得这太抽象了。要回答字面上的问题，那是Lightstep的产品。如果可以在数据层进行集成，那么就没有理由不能在其他地方进行集成。我认为在实践中很难做到的是，资源度量数据和事务跟踪数据之间的集成必须在数据层完成。你不能仅仅通过超链接来实现。我所描述的连接实际上是一个连接。您必须能够从度量中的标记连接到数千条记录道组上的标记。要做到这一点，需要在平台级别进行一些数据工程。事实上，我很想看到开源世界中有更多的解决方案朝着这个方向发展。事件解决的最短路径当然是能够通过时间序列数据和事务数据之间的标记进行透视。如果您必须从一个筒仓式度量解决方案和一个筒仓式跟踪解决方案(如web UI)开始，那么这实际上是一个困难的问题，因为集成必须在数据层进行。从产品的角度来看，这就是为什么它如此棘手的原因。

但是，我看到一些平台是在我工作过的地方内部创建的，但是要让它正常工作需要很多年和大量的迭代，所以一点也不容易。还有一件有趣的事，比如说，当你访问到这样的系统时，比如说，你有一个客户突然改变了他们的模式，但也许这很好。也许他们已经接触了所有这些新用户，并且正在进行一系列令人惊叹的工作，这意味着你可以对其他团队，比如公司的业务部门说，“看起来这个客户的工作真的很棒。你应该知道。你知道我们正在这样做吗?”它使工程团队能够更好地与真正有趣和有洞察力的数据进行对话，我认为这也很好。建议使用哪些工具进行跟踪?它始终是一个服务网格或类似的东西，还是在系统内部单独执行更好?

西格曼：是的。事实上，我在2017年在KubeCon做了一次关于服务网格和跟踪的演讲。服务网格是有帮助的，但它绝对不能解决问题。服务网格真正做的就是为您提供服务之间调用的遥测。跟踪最困难的部分始终是成功地将此跟踪ID上下文从服务的入口通过函数调用传播到该服务的出口。服务网格与此无关。服务网格只处理服务之间的调用。它在服务中，是跟踪中最困难的部分。这真的没用。您最终会得到一组带有服务网格的点对点数据，但要真正成功地解决上下文传播问题，我唯一的建议是转向OpenTelemetry。这实际上是试图以一种相当全面的方式解决这个问题，并使上下文传播成为一种内置功能。OpenTelemetry还将与服务网格集成。服务网格的部分优势在于它解决了跟踪问题，但事实并非如此。它添加了用于跟踪的数据，但没有解决上下文传播问题，而上下文传播问题实际上是分布式跟踪的核心。

但是，我看到一些平台是在我工作过的地方内部创建的，但是要让它正常工作需要很多年和大量的迭代，所以一点也不容易。还有一件有趣的事，比如说，当你访问到这样的系统时，比如说，你有一个客户突然改变了他们的模式，但也许这很好。也许他们已经接触了所有这些新用户，并且正在进行一系列令人惊叹的工作，这意味着你可以对其他团队，比如公司的业务部门说，“看起来这个客户的工作真的很棒。你应该知道。你知道我们正在这样做吗?”它使工程团队能够更好地与真正有趣和有洞察力的数据进行对话，我认为这也很好。建议使用哪些工具进行跟踪?它始终是一个服务网格或类似的东西，还是在系统内部单独执行更好?

西格曼：是的。事实上，我在2017年在KubeCon做了一次关于服务网格和跟踪的演讲。服务网格是有帮助的，但它绝对不能解决问题。服务网格真正做的就是为您提供服务之间调用的遥测。跟踪最困难的部分始终是成功地将此跟踪ID上下文从服务的入口通过函数调用传播到该服务的出口。服务网格与此无关。服务网格只处理服务之间的调用。它在服务中，是跟踪中最困难的部分。这真的没用。您最终会得到一组带有服务网格的点对点数据，但要真正成功地解决上下文传播问题，我唯一的建议是转向OpenTelemetry。这实际上是试图以一种相当全面的方式解决这个问题，并使上下文传播成为一种内置功能。OpenTelemetry还将与服务网格集成。服务网格的部分优势在于它解决了跟踪问题，但事实并非如此。它添加了用于跟踪的数据，但没有解决上下文传播问题，而上下文传播问题实际上是分布式跟踪的核心。

但是，关于OpenTelemetry还有一个问题。你的想法是什么?

西格曼：我是管理委员会的成员，是这个项目的共同创立者，我对此极有偏见。从拥有众多贡献者的角度来看，这确实是一个非常成功的项目。我认为仅在上个月我们就有1000名投稿人。每个主要的供应商和云提供商都已经购买了该项目，并且正在为该项目配备人员等等。OpenTelemetry的唯一问题是它有太多的活动，以至于我们在维护项目时遇到了一些困难。我认为它之所以如此成功，是因为它使许多方面受益。对于主要的基础设施提供商、云提供商、可观测性供应商，尤其是最终用户来说，这是一个双赢的局面，因为您最终可以获得高质量的遥测，而无需与任何特定的供应商或提供商绑定。这种便携性是一件非常吸引人的事情。我认为，长期以来，可观测性解决方案一直受到它们所能收集的遥测数据质量的限制。OpenTelemetry真的将掀起这股浪潮，然后您将看到解决方案的改进。OpenTelemetry，是的，这是一个非常激动人心的项目。我认为我们唯一真正需要的就是能够在项目中说一点不，这样我们就能达到我们的里程碑。在某种程度上，它是自身成功的牺牲品。它肯定有一个光明的未来。

但是，对于今年刚刚结束的OpenTelemetry的路线图，你有什么要分享的吗?有什么让你兴奋的事情吗?

西格曼：跟踪、度量和日志这三大支柱对于可观察性来说没有任何意义。我会坚持我的观点。它们对遥测技术来说绝对有意义，所以这三个方面。我们从追踪开始。到目前为止基本上都是这样。指标很快就要出来了。然后日志记录将在稍后出现。我认为从标准和API集成的角度来看，这实际上是OpenTelemetry要解决的三个问题中最不重要的一个。我很高兴指标能够超过这一点。我们还与普罗米修斯社区进行了大量的合作，以确保普罗米修斯和OpenTelemetry之间的互操作，这样您就不会被迫做出选择。我认为这也是一件非常好的事情，看到今年夏天稳定下来。

但是，关于分布式跟踪的性能成本，还有一个常见的问题。你的想法是什么?

Sigelman：从延迟的角度来看，分布式跟踪不需要任何开销。在占用资源的意义上，存在一些最小的边际吞吐量开销。通常，人们可以采取一些抽样来解决这个问题。我在谷歌帮助撰写的这篇短小精悍的论文详细描述了我们对绩效的衡量。从统计噪音的角度看，这是难以察觉的，Dapper 100%的时间都在运行100%的谷歌服务，并且已经运行了15年。如果做得正确，这绝对不是一件高开销的事情。这就是它的魅力之一。

本文转载自微信公众号「超级架构师」，可以通过以下二维码关注。转载本文请联系超级架构师公众号。