Edgar：借助可观察性更快地解开谜团

　　Edgar通过对请求跟踪，日志，分析和元数据的汇总介绍，帮助Netflix团队有效地对分布式系统进行故障排除。

　　伊丽莎白·卡雷托（Elizabeth Carretto）

　　我们的团队-Kevin Lew，Maulik Pandey，Narayanan Arunachalam，Dustin Haffner，Andrei Ushakov，Seth Katz，Greg Burrell，Ram Vaithilingam，Mike Smith和Elizabeth Carretto

　　

　　每个人都喜欢未解之谜。 总会有一个人看起来像是犯规的罪魁祸首。 有明确的动机，完美的机会和难以捉摸的足迹。 然而，这是未解之谜！ 从来没有那么简单。 无论是电视后面的神秘音符，还是关键时刻来自未知号码的神秘电话，这些片段都很难完美地融合在一起。 作为神秘的爱好者，我们想回答wodunit这个古老的问题。 我们想了解真正发生了什么。

　　对于工程师而言，问题通常是"什么失败以及为什么？"，而不是工程师。 发生问题时，我们戴上侦探帽，并通过收集证据开始解决神秘的过程。 系统越复杂，寻找线索的地方就越多。 工程师可以发现自己正在挖掘日志，仔细研究痕迹并盯着数十个仪表板。

　　所有这些来源都使得知道从哪里开始以及增加找出错误原因所花费的时间变得颇具挑战性。 尽管丰富的仪表板和信息绝不是Netflix独有的，但在我们的微服务体系结构中确实如此。 每个微服务可能易于理解和单独调试，但是当组合成一个命中数十个或数百个微服务的请求时又会如何呢？ 搜索关键证据变得像在大海捞针中挖针。

　　

　　> Example call graph in Edgar

　　在某些情况下，我们要回答的问题是"现在正在发生什么？？"没有解决方案的每一秒钟都会带来沉重的成本。我们希望尽快解决问题，以便我们的成员可以继续欣赏自己喜欢的电影和节目。对于构建可观察性工具的团队来说，问题是：如何使我们的行为快速且易于理解？即使您不十分熟悉该系统的内部工作原理和复杂性，它也可以快速解析，并易于找出问题出在哪里？在Netflix，我们已经通过一套可观察性工具回答了这个问题。在较早的博客文章中，我们讨论了我们的健康监控系统Telltale。 Telltale告诉我们应用程序何时不正常，但有时我们需要更详尽的了解。我们需要知道为什么特定请求失败以及在哪里。我们构建了Edgar来减轻这种负担，方法是使用户能够借助对请求跟踪，日志，分析和元数据的摘要表示，有效地对分布式系统进行故障排除。

　　什么是Edgar？

　　Edgar是一种用于对分布式系统进行故障排除的自助服务工具，它建立在请求跟踪的基础上，顶部还附加了其他上下文。 借助请求跟踪以及来自日志，事件，元数据和分析的其他数据，Edgar可以显示通过我们的分布式系统的请求流-呼叫击中了哪些服务，从一个服务传递到下一个服务的信息， 该服务内部发生了什么，花费了多长时间以及发出了什么状态-并突出显示了可能发生问题的位置。 如果您熟悉Zipkin或OpenTelemetry之类的平台，听起来可能很熟悉。 但是，Edgar处理数据和用户的方式存在一些实质性差异。

　　· 尽管Edgar是建立在请求跟踪之上的，但它也使用跟踪作为将其他上下文绑定在一起的线程。 正如Cindy Sridharan在此博客文章中所阐述的那样，仅从跟踪数据中获取有意义的价值可能是具有挑战性的。 除了跟踪数据之外，Edgar还从日志，事件和元数据中提取其他上下文，筛选它们以确定有价值的相关信息，以便Edgar可以直观地突出显示错误发生的位置并提供详细的上下文。

　　· Edgar捕获了100％有趣的跟踪，而不是对固定流量的一小部分进行采样。 这种差异具有重大的技术含义，从要运输的有趣事物的分类到具有成本效益的存储（请留意稍后针对这些主题的Netflix Tech Blog帖子）。

　　· Edgar为工程师和非工程师提供了强大而易用的用户体验。 如果您接受存储大量痕迹的成本和复杂性，则希望从该成本中获得最大的价值。 通过使用Edgar，我们发现我们可以通过为其他团队（如客户服务运营）策划经验来利用这一价值，并且我们已经接受了构建使跟踪数据易于访问，易于获取和轻松的产品的挑战。 获得一些用户角色的见解。

　　追踪为基础

　　日志，指标和跟踪是可观察性的三大支柱。 指标可以宏观地传达正在发生的事情，跟踪可以说明隔离请求的生态系统，日志可以提供服务中发生的事情的详细信息快照。 这些支柱具有巨大的价值，因此，该行业投入大量资金来构建令人印象深刻的仪表板和围绕它们的工具也就不足为奇了。 缺点是我们有很多仪表板。 在一个仅涉及10个服务的请求中，可能有10个不同的分析仪表板和10个不同的日志存储。 但是，请求具有自己的唯一跟踪标识符，这是将请求的所有部分捆绑在一起的通用线程。 跟踪ID通常是在接收请求的第一个服务处生成的，然后作为标题值从一个服务传递到另一个服务。 这使跟踪成为在集中位置统一此数据的良好起点。

　　跟踪是一组段，代表整个系统中单个请求的每个步骤。 分布式跟踪是在分布式系统中生成，传输，存储和检索跟踪的过程。 当请求在服务之间流动时，每个不同的工作单元都记录为一个跨度。 跟踪由许多跨度组成，这些跨度使用跟踪ID组合在一起以形成单个的端到端伞。 跨度：

　　· 代表一个工作单元，例如从一项服务到另一项服务的网络调用（客户/服务器关系）或纯粹的内部操作（例如，启动和完成方法）。

　　· 通过父/子关系与其他跨度相关。

　　· 包含一组称为标签的键值对，服务所有者可以在其中附加有用的值，例如url，版本号，区域，相应的ID和错误。 标签可以与错误或警告相关联，Edgar可以在请求的图形表示中直观地显示这些错误或警告。

　　· 有开始时间和结束时间。 由于有了这些时间戳，用户可以快速查看该操作花费了多长时间。

　　跟踪（及其基础跨度）使我们可以按时间顺序以图形方式表示请求。

　　

　　> Sample timeline view of a trace, based on Jaegar UI's timeline view

　　向跟踪添加上下文

　　单独使用分布式跟踪，Edgar能够在流经各种系统的情况下绘制请求的路径。 这种集中式视图对于确定命中哪些服务以及何时运行非常有帮助，但是缺乏细微差别。 标签可能表明存在错误，但不能完全回答发生了什么问题。 将日志添加到图片可以有很大帮助。 使用日志，用户可以看到服务本身必须对发生问题的内容说些什么。 如果数据获取程序失败，则日志可以告诉您它正在运行哪个查询以及导致失败的确切ID或字段。 仅此一项就可以为工程师提供重现问题所需的知识。 在Edgar中，我们解析日志以查找错误或警告值。 我们将这些错误和警告添加到我们的UI中，在调用图中将其突出显示，并将其与给定服务明确关联，以使用户可以轻松查看我们发现的任何错误。

　　

　　> Example view of errors associated with a service, including an error parsed from a log

　　借助跟踪和日志中的其他上下文来说明问题，接下来的问题之一可能是该单个跟踪如何适应每个服务的总体运行状况和行为。 这是异常情况还是我们正在处理模式？ 为了帮助回答这个问题，Edgar从伙伴应用程序Telltale中引入了异常检测。 Telltale为Edgar提供了等待时间基准，该基准表明该给定服务的单个跟踪的等待时间是否异常。 仅凭一条跟踪就可以告诉您服务需要500毫秒才能响应，但是需要深入了解特定服务的典型行为才能确定此响应时间是否异常。 Telltale的异常分析着眼于历史行为，可以评估此跟踪所经历的延迟是否异常。 有了这些知识，Edgar可以在视觉上警告服务中发生了某些事情，从而导致其延迟超出正常范围。

　　

　　> Sample latency analysis

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

　　在一个界面中显示所有这些数据可以减少工程师发现每个源的工作量。但是，发现只是解决之道的一部分。有了Edgar提出和总结的所有证据，富贵论坛工程师可能会知道哪里出了问题以及哪里出了问题。这是朝着解决迈出的重要一步，但尚未值得庆祝。可能已找到根本原因，但是谁拥有相关服务？很多时候，找到正确的联系点将需要跳转到Slack或公司目录，这会花费更多时间。在埃德加（Edgar），我们已与服务集成在一起，以在应用程序内提供信息以及跟踪详细信息。对于配置了所有者和支持渠道的任何服务，Edgar都提供了指向该服务的联系人电子邮件及其Slack渠道的链接，从而使从一方到另一方的交接更加顺畅。如果工程师确实需要将问题传递给另一个团队或个人，Edgar的请求详细信息页面将包含所有上下文（跟踪，日志，分析），并且易于共享，从而无需编写详细的描述或提供一系列的信息。用于传达问题的链接。

　　

　　> Edgar's request detail page

　　Edgar任务的关键方面是最大程度地减轻用户和服务所有者的负担。 使用其所有数据源，庞大的数据量可能变得不堪重负。 对于Edgar来说，保持优先级的界面至关重要，该界面旨在向用户突出显示错误和异常，并帮助用户迈出下一步来解决问题。 随着用户界面的发展，在如何处理新数据源时要保持敏锐和明智，将它们编织到我们现有的错误和警告模型中以最小化干扰并促进快速理解非常重要。 我们将重点放在焦点小组和用户反馈上，以确保紧密的反馈循环，以便随着用户服务和用例的发展，Edgar可以继续满足用户的需求。

　　随着服务的发展，他们可能会更改其日志格式或使用新的标记来指示错误。 我们建立了一个管理页面，以向我们的服务所有者提供可配置性，并使我们的产品与深入的服务知识脱钩。 服务所有者可以配置其日志存储的基本详细信息，例如其日志位于何处以及它们用于跟踪ID和跨度ID的字段。 知道它们的跟踪和跨度ID就是使Edgar关联跟踪和日志的原因。 除此之外，他们的日志的特质是什么？ 某些字段可能不相关或已弃用，并且团队希望默认隐藏它们。 另外，某些字段包含最重要的信息，通过在Edgar UI中进行促销，他们可以更快地查看这些字段。 这种自助服务配置有助于减轻服务所有者的负担。

　　

　　> Initial log configuration in Edgar

　　利用Edgar

　　为了使用户在时间紧迫的情况下求助于Edgar，用户需要能够信任Edgar。 特别是，他们需要能够依靠Edgar获得有关其问题的数据。 分布式跟踪的许多方法涉及设置采样率（例如5％），然后仅跟踪请求流量的该百分比。 Edgar的任务不是捕获固定百分比，而是捕获100％有趣的请求。 因此，当发生错误时，Edgar的用户可以确信他们将能够找到它。 这是将Edgar定位为可靠来源的关键。 埃德加（Edgar）的方法承诺要获得有关特定问题的数据。

　　除了存储所有请求的跟踪数据外，Edgar还实施了一项功能，可以根据用户的指定标准，按需收集其他详细信息。 启用这种细粒度的跟踪功能后，Edgar会捕获请求和响应有效负载以及与用户条件匹配的请求标头。 这样一来，您就可以更清楚地了解通过请求路径从服务到服务传递的数据是什么。 尽管对于所有请求流量来说，这种粒度级别都是不可持续的，但它是有针对性的用例的强大工具，尤其是对于证明难以再现的错误而言。

　　可以想象，这带来了非常实际的存储成本。 尽管Edgar团队已尽最大努力来有效地管理这些成本并优化我们的存储，但成本并不微不足道。 增强我们的投资回报率的一种方法是成为整个软件开发生命周期中的关键工具。 埃德加（Edgar）是操作和维护生产服务的重要工具，减少恢复时间对客户产生直接影响。 工程师在整个开发和测试过程中还依赖我们的工具，他们使用Edgar请求页面在团队之间交流问题。

　　通过为多组用户提供工具，我们可以更有效地利用成本。 Edgar不仅已成为工程师的工具，而且已成为需要对Netflix服务进行故障排除的任何人的工具。在埃德加（Edgar）成立之初，我们努力在跟踪数据之上构建有价值的抽象，埃德加（Edgar）团队首先将流视频用例作为目标。我们建立了流媒体视频的策划体验，将请求分组为回放会话，以给定资产开始和停止回放为标志。我们发现，这种经验对于客户服务运营和工程团队而言是强大的。我们的团队听取了客户服务部门的操作，以了解哪些常见问题导致了过多的支持痛苦，以便我们可以在UI中总结这些问题。这使客户服务运营以及工程师能够以最少的挖掘量快速了解会员问题。通过逻辑上对跟踪进行分组并在更高级别上汇总行为，跟踪数据在回答以下问题变得非常有用：例如，为什么某个成员没有收到某个标题的4k视频，或者为什么成员看不到某些内容。

　　

　　> An example error viewing a playback session in Edgar

　　为工作室扩展Edgar

　　随着Netflix工作室的发展，我们意识到我们的电影和节目制作支持将受益于类似的用户活动。 我们的电影和节目制作支持可能需要回答为什么制作人员无法登录或访问其特定项目的资料的原因。 在为这个新用户群提供服务时，我们试图了解生产支持最需要回答哪些问题，然后将各种数据源捆绑在一起以在Edgar中回答这些问题。

　　Edgar团队积累了满足这种需求的经验，并使用跟踪数据构建了另一个抽象。 这次，重点是对与生产相关的用例和应用程序进行故障排除，而不是流视频会话。 Edgar为我们的生产支持提供了通过其名称或电子邮件来搜索给定承包商，供应商或生产人员的功能。 找到个人之后，Edgar进入众多日志存储区以获得其用户ID，然后将其登录历史记录，角色访问更改日志以及与生产相关的应用程序发出的最新跟踪汇总在一起。 Edgar会扫描这些数据以查找错误和警告，然后将这些错误显示在最前面。 厂商可能多次尝试使用错误的密码登录，或者他们在生产中被分配了错误的角色。 在这个新领域中，埃德加（Edgar）通过将信息绑定在一起并使其用户指向下一步解决方案来解决相同的多仪表板问题。

　　

　　> An example error for a production-related user

　　Edgar是什么

　　埃德加（Edgar）的目标不是成为工具的全部，最终工具，也不是成为统治所有工具的唯一工具。 相反，我们的目标是充当故障排除的门生-Edgar应该能够迅速引导用户理解问题，并将他们带到可以解决问题的下一个位置。 假设某生产供应商由于角色/权限分配不正确而无法访问其生产资料，并且该生产供应商伸出援手来协助解决故障。 当支持用户搜索该供应商时，Edgar应该能够表明该供应商最近发生了角色更改，并总结了此角色更改是什么。 他们没有被分配到Dead To Me Season 2，而是被分配到Season 1！ 在这种情况下，Edgar的目标是帮助支持用户得出这个结论，并将他们迅速引导到可以纠正该问题的角色管理工具，而不是拥有完整的解决方案。

　　Netflix的用法

　　Edgar是围绕Netflix的核心流视频用例创建的，但此后逐渐发展为涵盖了广泛的应用程序。 尽管Netflix流媒体视频被数以百万计的成员使用，但是某些使用Edgar的应用程序可能会按每分钟的请求而不是每秒的请求来衡量其流量，并且可能只有数十或数百个用户，而不是数百万。 当我们从一种精心设计的方法开始解决工程师的痛点并支持流视频工作时，我们发现该痛点与规模无关。 对于所有工程师来说，要想解决问题，成本高昂，无论他们是在构建30人使用的预算预测应用程序，还是正在构建数百万人使用的SVOD应用程序。

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

　　当您坐在沙发上观看新的未解之谜时，您可能仍然会发现自己的问题多于答案。 受害者为什么如此突然离开家？ 犯罪嫌疑人如何消失在空中？ 等等，有多少人看到那只不明飞行物？ 不幸的是，埃德加（Edgar）无法在这里为您提供帮助（相信我，我们也很失望）。 但是，如果因生产中断而中断了轻松的夜晚，Edgar将在幕后，帮助Netflix工程师解决眼前的谜团。

　　保持服务的正常运行可以使Netflix与我们的全球成员分享故事。 在每次中断和故障下，都有一个故事要讲述，需要强大的可观察性工具来讲述它。 如果您对可观察性充满热情，请与我们联系。