13分钟阅读 2天前 -- Prasanna Vijayanathan, Renzo Sanchez-Silva 当杰克·保罗和迈克·泰森在2024年11月走进拳击台时，我们为大约6500万的并发流提供了这场比赛。平时，我们的基础设施每天处理超过20亿个请求，并每秒处理超过3800万条实时日志事件。在这个规模下，整个情况无法容纳在一个工程团队的思维中，或是在一个仪表板上展示。随着直播内容、播客和实时流的增多，我们需要尽快理解并更新我们的系统，以提供良好的用户体验，变得愈发重要。以这种规模和我们的时间限制理解系统，常常变成在一片草堆里寻找针的艰巨任务，在黑暗丛林中，蒙着眼睛。这篇文章就是关于寻找这根针的。 修复前的四个小时 考虑一下我们在某一周所见的回归现象。你看到的电影列表的主屏幕开始渲染需要多花1.5秒。一个警报产生了。然后我们开始寻找造成这个问题的原因以及如何修复它？恰巧的是，应用程序的回归可能与系统中的任何地方有关——一个新的版本部署或A/B测试推出导致的客户端应用回归，基础设施中的负载削减，或由于下游6个跳跃的服务推出而导致的GraphQL查询响应错误数据，在这一点上都是可疑者。因此，回答“是什么造成了这个问题？”需要来自系统各个部分的见解，这涉及到以细致的方式梳理数据的层次。 MELT层 “是什么造成了这个问题？”指标、事件、日志和追踪，行业的简称是MELT，是进行此类调查的正确原材料，每个部分大约回答了问题的四分之一。我们在这四个支柱中收集可观察性数据，统一到一个单一的可观察性数据层。这使我们能够实时观察我们的系统，包括用户的体验、我们的应用程序的表现以及我们的后端基础设施和服务正在处理和响应的内容。 按下回车或点击查看完整图像 MELT——指标、事件、日志和追踪，以及它们如何跨系统捕获。随之而来的调查可能在每一层中如下所示： 按下回车或点击查看完整图像 MELT的每一层告诉我们什么，留下了什么 关于调查的时间线 那么，调查一个问题、找到根本原因并修复它需要多长时间，以便我们的用户不再遇到这个问题？ 按下回车或点击查看完整图像 一次调查的时间线：~4小时 在我们选择的示例中，四小时。很少花费在计算任何困难的东西上。大多数时间花费在重建我们的可观察性系统已经知道但我们从未将其写下来以供人类或机器 fácil 阅读和发现的关系上。 深层的不一致 这里的直觉可能是在2023年，寻求更多的数据或更好的仪表板，虽然两者在边缘上有帮助，但都没有解决问题调查缓慢的根本原因。现在是2026年，因此我们可能会说：“嘿，代理，”但如果没有提供给代理的正确上下文，AI系统就会出现幻觉，特别是在团队处于呼叫状态并需要“立即”解决问题时，我们不能让不准确的代理分析引导我们走上错误的道路。我们需要正确的针，而不是任何针。我们每个系统内部都是一致的，外部是隔离的。Atlas，我们的遥测平台，了解应用程序及其时间序列。Radar，我们的警报系统，知道阈值和触发历史。incident.io了解严重性和响应者。PagerDuty了解轮班。Spinnaker了解什么被交付以及何时。我们的Slack历史记录以一种没有任何查询引擎能够触及的形式知道，哪个工程师在上个季度解决了非常相似的问题以及他们发现了什么。困难在于它们在讨论的内容上并不一致。在一个系统中是应用程序的东西在第二个系统中是服务，而在第三个系统中是集群，名称因后缀、大小写约定或只有几个人记得的重命名而不同（SMEs，还记得吗？）。跨越它们的连接需要一个人将映射牢记于心，而这个人就成了跨领域调查中的瓶颈。 端到端可观察性的难点可能更好地被理解为数据建模问题。我们缺乏的是一个关于我们操作世界中实体的明确、机器可读的协议。 本体 这种协议有一个名称：本体。Ontology是类型、它们所携带的属性及其可能关系的正式规范。它的单位是三元组，一条事实表示为主语、谓语、宾语。考虑以下示例三元组。api-gateway rdf:type ops:Application . api-gateway ops:ownedBy "Team Bedrock" . api-gateway ops