Edgar：Netflix分布式系统的可视化问题诊断平台实践

Edgar通过对请求追踪（tracing）、日志（logs）、分析（analysis）和元数据（metadata）的总结展示，帮助Netflix团队有效地对分布式系统进行故障诊断。

每个人都喜欢未解之谜。总有人看起来像是罪魁祸首。有一个明确的动机，一个完美的机会和一个遗留下来的犯罪痕迹。然而，这是个未解之谜！事情从来没有这么简单。无论是电视机后面的一张神秘的便条，还是关键时刻来自未知号码的神秘电话，这些片段很少能完美地结合在一起。作为神秘爱好者，我们想回答一个古老的问题：侦探小说；我们想了解到底发生了什么。

对于工程师来说，问题往往是“什么失败了，为什么失败了？“，一旦出现问题，我们就戴上侦探帽，通过收集证据开始破案过程。系统越复杂，寻找线索的地方就越多。一个工程师可以发现自己在挖掘日志，仔细研究痕迹，盯着几十个仪表盘。

所有这些来源都使我们很难知道从何处开始，并增加找出问题所在的时间。尽管如此丰富的仪表盘和信息并非Netflix独有，但在我们的微服务体系结构中确实如此。每一个微服务可能很容易理解和单独调试，但是当组合到一个请求中时会怎样呢？寻找关键证据就像是大海捞针。

Edgar中的调用图示例

在某些情况下，我们要回答的问题是："现在发生了什么？"，问题没有解决的每一秒钟都会带来沉重的代价。我们希望尽快解决这个问题，这样我们的网站会员就可以恢复享受他们最喜欢的电影和节目。

对于构建可观察性工具的团队来说，问题是：我们如何让理解一个系统的行为变得快速、易消化？快速解析，即使你对该系统的内部运作和复杂程度不是很熟悉，也能轻松地指出哪里出了问题？

在Netflix，我们已经用一套可观察性工具回答了这个问题。在之前的一篇博文中，我们讨论了Telltale，我们的健康监测系统。

Telltale可以告诉我们一个应用程序何时不健康，但有时我们需要更精细的洞察力。我们需要知道为什么一个特定的请求会失败，以及失败的原因。

我们构建Edgar就是为了减轻这种负担，通过对请求跟踪、日志、分析和元数据的汇总展示，让我们的用户能够高效地排除分布式系统的故障。

Edgar是什么？

Edgar是一个用于分布式系统故障排除的自助服务工具，它建立在请求跟踪的基础上，并在上面添加了额外的上下文。通过请求跟踪和来自日志、事件、元数据和分析的额外数据，Edgar能够显示请求在我们的分布式系统中的流程：哪些服务被调用中，哪些信息从一个服务传递到下一个服务，在这个服务内部发生了什么，花了多长时间，发出了什么状态，并突出显示可能发生问题的地方。如果你熟悉Zipkin或OpenTelemetry等平台，这可能听起来很熟悉。但是，在Edgar如何处理其数据和用户方面，有一些实质性的差异：

• 虽然Edgar是建立在请求跟踪（tracing）之上的，但它也使用跟踪（tracing）作为线程，将额外的上下文联系在一起。正如Cindy Sridharan在这篇博文中所阐述的那样，仅仅从跟踪数据中获取有意义的价值是很有挑战性的。除了跟踪（tracing）数据，Edgar还从日志、事件和元数据中提取额外的上下文，通过筛选来确定有价值的相关信息，这样Edgar就可以直观地突出错误发生的位置，并提供详细的上下文。

• Edgar可以100%捕捉到有趣的痕迹，而不是抽取固定比例的小流量。这种差异在技术上有很大的影响，从对有趣的传输内容进行分类，到成本效益的存储（请关注Netflix技术博客后面涉及这些主题的文章）。

• Edgar为工程师和非工程师都提供了强大的、可消费的用户体验。如果你接受了存储大量痕迹的成本和复杂性，你就会希望从这种成本中获得最大的价值。有了Edgar，我们发现我们可以通过为其他团队（如客户服务运营）策划体验来利用这种价值，我们已经接受了建立一个产品的挑战，使跟踪数据易于访问，易于搜索，并易于获得多个用户角色的洞察力。

Tracing 是基础

日志、度量和追踪（tracing）是可观察性的三大支柱：

• 度量指标在宏观上传达正在发生的事情
• 追踪（tracing）说明了一个孤立请求的生态系统
• 而日志则提供了一个细节丰富的服务内部发生的快照

这些支柱具有巨大的价值，业界围绕每个支柱投入大量资金构建令人印象深刻的仪表盘和工具也就不足为奇了。缺点是，我们有这么多的仪表盘。在一个请求中只打十个服务，可能有十个不同的分析仪表板和十个不同的日志存储。但是，一个请求有它自己独特的跟踪标识符，它是把这个请求的所有部分联系在一起的共同线。Tracing ID通常是在接收请求的第一个服务处生成，然后作为头值从一个服务传递到另一个服务。这使得Tracing 成为一个很好的起点，可以将这些数据统一在一个集中的位置：

• Tracing是一组段，代表整个系统中单个请求的每一步。分布式Tracing是在分布式系统中生成、传输、存储和检索Tracing的过程。当一个请求在服务之间流动时，每一个不同的工作单元都被记录为一个跨度。一个Tracing是由许多跨度组成的，这些跨度用一个跟踪ID组合在一起，形成一个单一的、端到端的保护伞。一个跨度。
• 代表一个工作单位，如一个服务到另一个服务的网络调用（客户机/服务器关系）或一个纯粹的内部操作（如启动和结束一个方法）。
• 通过父/子关系与其他跨度相关。
• 包含一组称为标签的键值对，服务所有者可以在其中附加有用的值，如 urls、版本号、区域、相应的 ID 和错误。标签可以与错误或警告相关联，Edgar可以在请求的图上直观地显示。

Tracing 有一个开始时间和结束时间，由于有了这些时间戳，用户就可以快速看到操作的时间。Tracing以及它的底层跨度)允许我们按时间顺序用图形展示请求。

基于Jaegar UI的时间线视图的跟踪时间线视图示例。

在Tracing中添加上下文

仅仅通过分布式跟踪，Edgar就能够画出请求流经不同系统时的路径。这种集中式的视图对于确定哪些服务被攻击以及何时被攻击非常有帮助，但它缺乏细微的差别。一个标签可能表明有一个错误，但并不能完全回答发生了什么问题。在图片中添加日志可以提供很大的帮助。有了日志，用户可以看到服务本身对出错的情况有什么说法。如果一个数据获取器失败了，日志可以告诉你它运行的是什么查询，到底是什么ID或字段导致了失败。光是这一点就可以给工程师提供重现问题所需的知识。在Edgar中，我们对日志进行解析，寻找错误或警告值。我们将这些错误和警告添加到我们的UI中，在我们的调用图中高亮显示它们，并将它们与一个给定的服务清晰地关联起来，使用户可以轻松地查看我们发现的任何错误。

有了Tracing和来自日志的额外上下文来说明问题，下一个问题可能是这个单独的Tracing如何与每个服务的整体健康和行为相匹配。这是一个异常还是我们在处理一个模式？为了帮助回答这个问题，Edgar从合作伙伴Telltale应用中引入了异常检测。Telltale为Edgar提供了延迟基准，它表明了单个Tracing的延迟对于这个给定的服务是否是异常的。单单一个Tracing就可以告诉你，一个服务需要500ms的响应时间，但是需要深入了解某个服务的典型行为，才能判断这个响应时间是否是异常值。Telltale的异常分析可以查看历史行为，并能评估这个Tracing所经历的延迟是否异常。有了这些知识，Edgar就可以直观地警告服务中发生了什么事情，导致其延迟超出了正常范围。

Edgar应该减负，而不是增加负担

在一个界面中呈现所有这些数据，减少了工程师发现每个源的工作量。然而，发现只是解决路径的一部分。有了所有的证据，并由Edgar总结，工程师可能会知道什么地方出了问题，哪里出了问题。这是向解决方法迈出的一大步，但还不值得庆祝。根源可能已经确定，但谁是问题服务的主人？很多时候，找到正确的联系人需要跳到Slack或公司目录中，这需要花费更多的时间。在Edgar中，我们已经整合了我们的服务，在应用中提供这些信息以及追踪的细节。对于任何配置了所有者和支持渠道的服务，Edgar提供了服务的联系邮件和他们的Slack渠道的链接，使一方与另一方的交接更加顺畅。如果工程师确实需要将一个问题传递给另一个团队或人员，Edgar的请求详情页包含了所有的上下文：跟踪、日志、分析，并且很容易共享，无需编写详细的描述或提供一系列的链接来沟通问题。

Edgar的一个重要使命是将用户和服务所有者的负担降到最低。有了所有的数据源，数据的数量可能会变得不堪重负。对于Edgar来说，保持一个优先级的界面是非常重要的，它可以向用户突出显示错误和异常，并协助用户进行下一步的解决。随着我们UI的发展，在如何处理新的数据源时，重要的是要有鉴别力和判断力，将它们编织到我们现有的错误和警告模型中，以最大限度地减少干扰并促进快速理解。我们非常重视焦点小组和用户反馈，以确保紧密的反馈循环，从而使Edgar能够随着用户服务和用例的发展而不断满足他们的需求。

随着服务的发展，他们可能会改变他们的日志格式或使用新的标签来指示错误。我们建立了一个管理页面，给我们的服务所有者提供这种可配置性，并使我们的产品与深入的服务知识脱钩。服务所有者可以配置他们的日志存储的基本细节，例如他们的日志在哪里，以及他们对跟踪ID和跨度ID使用什么字段。了解他们的跟踪ID和跨度ID，才能使Edgar将跟踪和日志关联起来。不过除此之外，他们的日志有什么特殊性呢？有些字段可能是不相关的，或者是已经废弃的，团队希望默认隐藏它们。或者，有些字段包含了最重要的信息，通过在Edgar UI中推广这些字段，他们能够更快地查看这些字段。这种自助服务配置有助于减轻服务所有者的负担。

Edgar的初始日志配置

使用Edgar

为了让用户在时间紧迫的情况下求助于Edgar，用户需要能够信任Edgar。特别是，他们需要能够指望Edgar拥有关于他们问题的数据。许多分布式追踪的方法涉及到设置一个采样率，比如5%，然后只追踪这个百分比的请求流量。而Edgar的任务是捕捉100%的有趣请求，而不是固定的采样率。因此，当发生错误时，Edgar的用户可以确信他们能够找到错误。这是Edgar定位为可靠来源的关键。Edgar的方法是做出了一个承诺，即拥有关于某个问题的所有的数据。

除了存储所有请求的跟踪数据外，Edgar还实现了一个功能，可以根据用户的决定，针对给定的标准按需收集额外的细节。当这种细粒度的追踪功能开启时，Edgar会捕获请求和响应的有效载荷，以及与用户标准相匹配的请求头。这就更清楚地说明了哪些数据是通过请求路径从服务传递到服务的。虽然这种粒度水平对于所有请求流量来说是不可持续的，但在有针对性的用例中，它是一个强大的工具，特别是对于那些被证明具有挑战性的重现错误。

正如你可以想象的那样，这带来了非常真实的存储成本。虽然Edgar团队已经尽力有效地管理这些成本，并优化我们的存储，但成本并不小。加强我们投资回报率的一个方法是成为整个软件开发生命周期的关键工具。Edgar是运营和维护生产服务的重要工具，缩短恢复时间对客户有直接影响。工程师们在整个开发和测试过程中也依赖我们的工具，他们使用Edgar请求页面在团队间交流问题。

通过向多组用户提供我们的工具，我们能够更有效地利用我们的成本。Edgar已经不仅仅是工程师的工具，而是成为Netflix任何需要排除服务故障的人的工具。在Edgar早期，当我们努力在痕迹数据之上建立有价值的抽象时，Edgar团队首先瞄准了流媒体视频用例。我们为流媒体视频建立了一个精心策划的体验，将请求分组到播放会话中，通过开始和停止播放给定的资产进行标记。我们发现这种体验对于客服运营以及工程团队来说都是非常强大的。我们的团队听取了客服运营的意见，了解哪些常见的问题造成了过多的支持痛苦，这样我们就可以在UI中总结这些问题。这使客服运营以及工程师能够以最少的挖掘来快速了解会员问题。通过对痕迹进行逻辑分组，并在更高层次上总结行为，痕迹数据在回答诸如为什么会员没有收到某个标题的4k视频或为什么会员无法观看某些内容等问题时变得非常有用。

在Edgar中查看回放会话的一个错误示例。

为Studio扩展Edgar

随着Netflix工作室方面的发展，我们意识到我们的电影和节目制作支持将从类似的用户活动汇总中受益。我们的电影和节目制作支持可能需要回答为什么制作组的某个人无法登录或访问他们的某个项目的材料。当我们努力为这个新的用户群体服务时，我们试图了解我们的制作支持最需要回答的问题，然后将各种数据源联系在一起，在Edgar中回答这些问题。

Edgar团队建立了一个满足这一需求的体验，用跟踪数据建立了另一个抽象；这一次，重点是解决与生产相关的用例和应用的问题，而不是流媒体视频会话。Edgar为我们的生产支持提供了通过姓名或电子邮件搜索某个承包商、供应商或生产人员成员的能力。在找到这个人之后，Edgar会进入许多日志存储中寻找他们的用户ID，然后将他们的登录历史、角色访问变更日志以及最近从生产相关应用程序中发出的痕迹汇总在一起。

Edgar在这些数据中扫描出错误和警告，然后将这些错误直接呈现在前面。也许某个供应商试图用错误的密码登录太多次，或者他们在生产中被分配了一个错误的角色。在这个新的领域中，Edgar通过将信息捆绑在一起，并将用户指向下一步的解决方法，来解决同样的多仪表板问题。

一个与生产相关的用户的错误示例

Edgar是什么，不是什么

Edgar的目标不是要成为万能的工具，也不是要成为万能的工具。相反，我们的目标是作为一个故障排除的向导：Edgar应该能够快速引导用户理解一个问题，并将他们带到下一个位置，在那里他们可以补救这个问题。 比方说，一个生产供应商由于角色/权限分配不正确而无法访问他们生产的材料，这个生产供应商向支持部门求助，要求协助排除故障。当支持用户搜索到这个供应商时，Edgar应该能够指出这个供应商最近有一个角色变化，并总结这个角色变化是什么。他们没有被分配到《死神给我》第二季，而是被分配到了第一季。 在这种情况下，Edgar的目标是帮助支持用户得出这个结论，并快速引导他们到合适的角色哪儿，去快速纠正解决问题，而不是掌握整个解决方案。

在Netflix的使用情况

虽然Edgar是围绕Netflix的核心流媒体视频使用案例而创建的，但后来它已经发展到涵盖了广泛的应用。虽然Netflix流媒体视频被数百万会员使用，但一些使用Edgar的应用可能以每分钟的请求量而不是每秒的请求量来衡量，而且可能只有几十个或几百个用户，而不是数百万。虽然我们一开始是通过策划的方式来解决从事流媒体视频工作的工程师和支持的痛点，但我们发现这个痛点是与规模无关的。对于所有工程师来说，无论他们是在构建一个由30人大量使用的预算预测应用，还是一个由数百万人使用的SVOD应用，找到问题的根源都是昂贵的。

今天，Netflix的许多应用和服务，涵盖了广泛的类型和规模，发布的跟踪数据可以在Edgar中访问，从服务所有者到客户服务运营的团队都依赖于Edgar的洞察力。从流媒体到工作室，Edgar利用其丰富的知识，以相同的基本方法，总结请求跟踪、日志、分析和元数据，加快跨应用程序的故障排除。

当你坐在沙发上观看一集新的《未解之谜》时，你可能会发现自己的问题比答案还多。为什么受害者会突然离开家？嫌疑人怎么会凭空消失？等等，有多少人看到了那个UFO？不幸的是，Edgar无法在那里帮助你（相信我，我们也很失望）。但是，如果你的休闲夜晚被故障停机而打断，Edgar会在幕后帮助Netflix工程师解决手头的谜团。

保持服务的正常运行，让Netflix能够与全球的会员分享故事。在每一次中断和故障的背后，都有一个故事要讲，而讲这个故事需要强大的可观察性工具。如果你对可观察性充满热情，那就来和我们聊聊吧。

原文

https://netflixtechblog.com/edgar-solving-mysteries-faster-with-observability-e1a76302c71f