埃德加:用可观察性更快地解开谜团

2020-09-12 22:21:59

Edgar借助请求跟踪、日志、分析和元数据的摘要演示,帮助Netflix团队高效地排除分布式系统故障。

每个人都喜欢未解之谜。总有人似乎是万无一失的罪魁祸首。有明确的动机,完美的机会,并留下了牵连的足迹。然而,这是未解之谜!事情从来没有那么简单。无论是电视后面的一张神秘字条,还是关键时刻未知号码打来的神秘电话,这些片段很少能完美地结合在一起。作为神秘爱好者,我们想要回答侦探小说这个古老的问题;我们想知道到底发生了什么。

对于工程师来说,问题通常不是侦探小说,而是“什么失败了,为什么?”当问题发生时,我们戴上侦探帽,通过收集证据开始我们的破案过程。系统越复杂,寻找线索的地方就越多。工程师可能会发现自己在挖掘日志,研究痕迹,盯着几十个仪表盘。

所有这些来源都使我们很难知道从哪里开始,并增加找出哪里出了问题所花费的时间。虽然这种丰富的仪表盘和信息并不是Netflix独有的,但在我们的微服务架构中肯定也是如此。每个微服务可能很容易单独理解和调试,但是当组合成一个访问数十或数百个微服务的请求时又会怎样呢?寻找关键证据就像大海捞针。

在某些情况下,我们要回答的问题是,“现在发生了什么?”而每一秒没有解决的问题都会带来沉重的代价。我们希望尽快解决这个问题,这样我们的会员就可以重新开始欣赏他们最喜欢的电影和节目。对于构建可观察性工具的团队来说,问题是:我们如何让理解系统的行为变得快速和易于理解?即使您对该系统的内部工作原理和错综复杂的情况不是很熟悉,也可以快速解析,并且很容易找出哪里出了问题?在Netflix,我们用一套可观察性工具回答了这个问题。在早些时候的一篇博客文章中,我们讨论了我们的健康监测系统Telltale。当应用程序不健康时,Tell会告诉我们,但有时我们需要更细粒度的洞察力。我们需要知道特定请求失败的原因和位置。我们构建EDGAR是为了减轻这一负担,方法是使我们的用户能够借助请求跟踪、日志、分析和元数据的汇总演示文稿高效地排除分布式系统故障。

Edgar是一个用于诊断分布式系统故障的自助服务工具,它构建在请求跟踪的基础上,并在上面添加了其他上下文。通过请求跟踪以及来自日志、事件、元数据和分析的其他数据,Edgar能够显示通过我们的分布式系统的请求流-调用击中了哪些服务、将哪些信息从一个服务传递到下一个服务、该服务内部发生了什么、花费了多长时间以及发出了什么状态-并突出显示了可能发生问题的位置。如果您熟悉像Zipkin或OpenTelemeter这样的平台,这可能听起来很熟悉。但是,在Edgar处理数据和用户的方式上有一些实质性的不同。

虽然Edgar构建在请求跟踪之上,但它也使用跟踪作为线程将其他上下文绑定在一起。正如辛迪·斯里德哈兰(Cindy Sridharan)在这篇博客文章中所阐述的那样,仅从跟踪数据中获得有意义的价值可能是具有挑战性的。除了跟踪数据之外,Edgar还从日志、事件和元数据中提取额外的上下文,对它们进行筛选以确定有价值的相关信息,以便Edgar可以直观地突出显示错误发生的位置并提供详细的上下文。

Edgar捕捉100%有趣的痕迹,而不是采样一小部分固定的流量。这种差异具有重大的技术意义,从运输的趣味性分类到经济高效的存储(请密切关注稍后Netflix Tech针对这些主题的博客文章)。

Edgar为工程师和非工程师提供了功能强大且易于使用的用户体验。如果您接受存储大量跟踪的成本和复杂性,您希望从该成本中获得最大价值。有了Edgar,我们发现我们可以通过为其他团队(如客户服务运营)策划体验来利用这一价值,我们已经接受了构建一种产品的挑战,该产品使跟踪数据易于访问、易于摸索,并易于通过多个用户角色获得洞察力。

日志、度量和跟踪是可观察性的三大支柱。度量在宏观范围内传达正在发生的事情,跟踪说明孤立请求的生态系统,日志提供服务内发生的事情的详细信息快照。这些支柱具有巨大的价值,因此业界投入巨资围绕每个支柱构建令人印象深刻的仪表板和工具也就不足为奇了。缺点是我们有太多的仪表盘。在一个仅命中10个服务的请求中,可能有10个不同的分析仪表板和10个不同的日志存储。但是,请求有其自己的唯一跟踪标识符,该标识符是将此请求的所有片段捆绑在一起的公共线程。跟踪ID通常在接收请求的第一个服务处生成,然后作为标头值从一个服务传递到另一个服务。这使得跟踪成为在集中位置统一这些数据的一个很好的起点。

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

表示一个工作单元,例如从一个服务到另一个服务的网络调用(客户端/服务器关系)或纯粹的内部操作(例如,启动和结束一个方法)。

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

有开始时间和结束时间。多亏了这些时间戳,用户可以快速查看操作花费了多长时间。

跟踪(及其底层跨度)允许我们按时间顺序以图形方式表示请求。

仅使用分布式跟踪,Edgar就能够在请求流经各种系统时绘制请求的路径。这种集中视图对于确定哪些服务以及何时受到攻击非常有帮助,但缺乏细微差别。标记可能表示有错误,但不能完全回答所发生的问题。将日志添加到图片中会有很大帮助。有了日志,用户就可以看到服务本身对哪里出了问题说了些什么。如果数据抓取器失败,日志可以告诉您它正在运行什么查询,以及导致失败的确切ID或字段。仅这一点就可能给工程师提供重现问题所需的知识。在Edgar中,我们解析日志以查找错误或警告值。我们将这些错误和警告添加到我们的UI中,在调用图中突出显示它们,并清楚地将它们与给定的服务相关联,以便于用户查看我们发现的任何错误。

有了说明问题的日志中的跟踪和其他上下文,下一个问题之一可能是这个单独的跟踪如何与每个服务的整体运行状况和行为相适应。这是一种反常现象,还是我们在处理一种模式?为了帮助回答这个问题,Edgar从合作伙伴应用程序Telltale中引入了异常检测功能。TELTALE为Edgar提供延迟基准,以指示单个跟踪的延迟对于此给定服务是否异常。仅跟踪就可以告诉您服务需要500ms的响应时间,但是需要深入了解特定服务的典型行为才能确定此响应时间是否为异常值。Telltale的异常分析着眼于历史行为,并可以评估此跟踪经历的延迟是否异常。有了这些知识,Edgar就可以直观地警告服务中发生了导致其延迟超出正常界限的事情。

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

Edgar使命的一个关键方面是将用户和服务所有者的负担降至最低。由于它的所有数据源,绝对数量的数据可能会变得不堪重负。对于Edgar来说,维护一个按优先顺序排列的界面非常重要,该界面旨在向用户突出错误和异常,并帮助用户采取下一步的解决措施。随着我们UI的增长,在如何处理新的数据源方面要有洞察力和判断力,将它们编织到我们现有的错误和警告模型中,以最大限度地减少中断并促进快速理解,这一点很重要。我们在很大程度上依赖焦点小组和用户反馈来确保紧密的反馈循环,以便Edgar能够随着用户的服务和用例的发展继续满足他们的需求。

随着服务的发展,它们可能会更改其日志格式或使用新的标记来指示错误。我们构建了一个管理页面,为我们的服务所有者提供这种可配置性,并将我们的产品与深入的服务知识分离。服务所有者可以配置其日志存储的基本详细信息,例如其日志位于何处,以及将哪些字段用于跟踪ID和SPAN ID。了解它们的跟踪和跨区ID使Edgar能够将跟踪和日志关联起来。除此之外,他们日志的特点是什么?某些字段可能无关紧要或已弃用,团队希望在默认情况下隐藏它们。或者,一些字段包含最重要的信息,通过在Edgar UI中提升它们,他们能够更快地查看这些字段。此自助服务配置有助于减轻服务所有者的负担。

为了让用户在时间至关重要的情况下求助于埃德加,用户需要能够信任埃德加。特别是,他们需要能够依赖埃德加拥有关于他们问题的数据。分布式跟踪的许多方法包括设置采样率(例如5%),然后仅跟踪该百分比的请求流量。Edgar的任务不是抽取固定百分比的样本,而是100%捕获感兴趣的请求。因此,当错误发生时,Edgar的用户可以确信他们能够找到它。这是将埃德加定位为可靠消息来源的关键。埃德加的方法承诺拥有关于特定问题的数据。

除了存储所有请求的跟踪数据外,Edgar还实现了一项功能,可以根据用户的判断根据给定条件按需收集额外的详细信息。启用这种细粒度级别的跟踪后,Edgar将捕获请求和响应有效负载以及与用户标准匹配的请求的头。这使通过请求路径从一个服务传递到另一个服务的确切数据更加清晰。虽然此级别的粒度对于所有请求流量都是不可持续的,但它在目标用例中是一个健壮的工具,特别是对于事实证明具有挑战性的错误

随着Netflix制片厂的发展,我们意识到我们的电影和节目制作支持将从类似的用户活动聚合中受益。我们的电影和节目制作支持可能需要回答为什么制作团队中的一些人不能登录或访问他们的特定项目的材料。当我们努力为这一新的用户群体服务时,我们试图了解我们的生产支持需要最频繁地回答哪些问题,然后将各种数据源捆绑在一起,在Edgar中回答这些问题。

Edgar团队构建了满足这一需求的体验,使用跟踪数据构建了另一个抽象;这一次,重点放在解决与生产相关的用例和应用程序上,而不是流式视频会话。EDGAR为我们的生产支持人员提供了通过姓名或电子邮件搜索给定承包商、供应商或生产员工的能力。在找到这个人之后,Edgar找到了他们的用户ID的众多日志存储区,然后将他们的登录历史记录、角色访问更改日志和最近从生产相关应用程序发出的跟踪信息收集在一起。Edgar扫描这些数据以查找错误和警告,然后将这些错误显示在最前面。可能是供应商尝试使用错误密码登录的次数太多,或者他们在生产中被分配了错误的角色。在这个新的领域,Edgar正在通过将信息捆绑在一起并将用户指向下一步解决方案来解决同样的多仪表板问题。

埃德加的目标不是成为工具的至高无上的最终目标,也不是成为统治所有工具的唯一工具。相反,我们的目标是充当故障排除的礼宾-Edgar应该能够迅速引导用户了解问题,并将他们带到下一个位置,在那里他们可以解决问题。假设某个生产供应商由于角色/权限分配不正确而无法访问其生产材料,并且该生产供应商联系了支持人员以帮助排除故障。当支持用户搜索该供应商时,Edgar应该能够指出该供应商最近进行了角色更改,并总结了该角色更改是什么。他们没有被分配到第二季,而是被分配到了第一季!在这种情况下,Edgar的目标是帮助支持用户得出这一结论,并将他们快速引导到可以纠正此问题的角色管理工具,而不是拥有完整的解决方案。

虽然Edgar是围绕Netflix的核心流媒体视频用例创建的,但自那以后它已经发展到覆盖广泛的应用程序。虽然Netflix流媒体视频被数百万会员使用,但一些使用Edgar的应用程序可能会以每分钟的请求量来衡量它们的数量,而不是以每秒的请求量来衡量,而且可能只有几十或数百个用户,而不是数百万。虽然我们一开始采用精心策划的方法来解决工程师的痛点并支持流视频的工作,但我们发现这个痛点与规模无关。对于所有工程师来说,弄清问题的真相都是代价高昂的,无论他们是构建30人大量使用的预算预测应用程序,还是构建数百万人使用的SVOD应用程序。

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

当你坐在沙发上看新一集的“未解之谜”时,你可能仍然会发现自己有更多的问题而不是答案。为什么受害者离家这么突然?嫌疑犯是怎么凭空消失的?等等,有多少人看到那个不明飞行物??不幸的是,埃德加在这方面帮不了你(相信我,我们也很失望)。但是,如果你的放松之夜因生产中断而中断,埃德加将在幕后帮助Netflix工程师解开手头的谜团。

通过保持服务正常运行,Netflix可以与我们全球的会员分享故事。在每一次停机和失败的背后,都有一个故事要讲述,需要强大的可观察性工具来讲述。如果您对可观测性感兴趣,请与我们联系。