Charity Majors 的这句话可能是对科技行业当前可观察性状态的最好总结——完全的、大规模的混乱。大家都很狐疑。什么是 trace？什么是 span？一行日志就是一个 span 吗？如果我有日志，我还需要 trace 吗？如果我有很好的 metric，为什么还需要 trace？诸如此类的问题不胜罗列。Charity 与 Honeycomb 可观测系统中的其他良好人士一起，一直在努力解决这些问题。然而，根据我本身的经验，仍旧很难明释 Charity 所说的“日志是垃圾”是什么意思，更不消说日志和痕迹本质上是同一件事了。为什么大家都这么狐疑呢？
冒一点风险，我要怪罪 Open Telemetry。是的，它正在为今世的可观测性堆栈提供动力，然而我却将混乱的局面归咎于它。这并不是由于它是一个糟糕的解决方案 - 它非常出色！但是它本身的介绍、对 Open Telemetry 的概念和功能的解说，都使得可观测性看起来棘手而复杂。
首先，Open Telemetry 从一开始就明确区分了跟踪、指标和日志：
OpenTelemetry is a collection of APIs, SDKs, and tools. Use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you analyze your software’s performance and behavior.
OpenTelemetry 是 API、SDK 和工具的集合。使用它来检测、生成、收集和导出遥测数据（指标、日志和跟踪），以帮助您分析软件的性能和行为。
然后进一步深入解释这 3 个问题中的每一个。
这是 OpenTelemetry 网站介绍 trace 的部分截图。根据我与 OpenTelemetry 工作人员交谈的经验，该演示文稿确实已成为与可观测性相关的重要图片之一。对于一些人来说，这就是可观测性。它还将 trace 与其他任何东西区分开来。这显然不是日志，对吧？这看起来也不像指标，对吧？这是一些特别的东西，可能有点牛逼，需要投入学习。根据我的经验，一旦人们了解了 trace，他们只会在这张图片的上下文中思考它们以及相关术语，如 span、根 span、嵌套 span 等。OpenTelemetry 网站有一个包含 60 多个术语的词汇表页面！这齐备都极其复杂！
但更重要的是——这种对“日志、指标和链路追踪”的关注是否代表了可观察性的真正气力？确实，它确实涵盖了一些场景，但当涉及到大规模分布式系统时，更重要的是能够对数据举行深入挖掘 - 对其举行“切片和切块”，构建和分析各种视图，举行相关性分析，搜索非常情况… 而提供所有这些功能的系统确实存在。
Scuba: 可观测性天堂
当我在 Meta 公司工作时，我并没有意识到我有幸使用了有史以来最好的可观测性系统。这个系统称为 Scuba，它是脱离 Meta 公司后人们最吊唁的头等大事。
Scuba 的基本思想非常简单，不需要人们阅读术语页面就能理解。它使用广义事件（Wide Events）。广义事件只是一个带有名称和值的字段集合，就像一个JSON文档一样。如果你需要记录一些信息 - 无论是系统的当前状态还是由API调用、配景作业或其他事件引起的 - 你只需将一些广义事件写入Scuba。比方，如果一个系统提供广告服务，自然盼望记录广告展示 - 即某个广告被用户看到的究竟。相应的广义事件可能如下所示：- {
- "Timestamp": "1707951423",
- "AdId": "542508c92f6f47c2916691d6e8551279”,
- "UserCountry": "US",
- "Placement": "mobile_feed",
- "CampaingType": "direct_ads",
- "UserOS": "Android",
- "OSVersion": "14",
- "AppVersion": "798de3c28b074df9a24a479ce98302b6",
- "...": ""
- }
处理未知的未知情况可以通过一个例子更好地阐明。Scuba拥有一个直观易用的界面，可以轻松探索和操纵。它有一个部分可以选择要查看的指标，还有效于筛选和分组的部分 - Scuba会绘制一个漂亮的时间序列图表。对于广告展示数据集的首次查看将简单地绘制一个包含展示次数的图表：
如果我们用 SQL 来表达这里到底选择了什么，那么这就像：- SELECT COUNT(*) FROM AdImpressions
- WHERE IsTest = False
请注意，整个“放大”是由 UI 透明完成的，用户在查询期间无需考虑它。因此，假设发生了某个警报，并指示我们珍贵的广告展示图表看起来很奇怪：
每个使用 Scuba 举行调查的人的第一反应是举行“切片和切块”，即根据条件举行筛选或分组，以查看是否能够获取一些信息。我们不知道我们在寻找什么，但我们信任我们会找到。因此，我们会根据展示类型、用户国家或广告位置举行分组，直到找到可疑的地方。让我们假设是按照广告系列类型（CampaignType）举行分组：
我们发现某个名为 in_app_purchases 的广告系列类型（请注意，此类型名称是我编造的）似乎与其他类型不同。我们真的不知道它意味着什么 - 我们也不需要知道！ - 我们只需继续挖掘。好的，现在我们可以仅筛选这些广告系列，并继续根据其他我们能想到的条件举行分组。比方，用户操纵系统是有意义的。
嗯，Android 似乎有问题。iOS 没问题，这表明问题可能出现在客户端 - 可能是一个有问题的应用版本？
奇怪。有些人碰到了问题，而其他人没有。可能要检查操纵系统版本？
哈！这是最新的操纵系统版本，看起来某些应用版本在这个操纵系统版本上对于这种类型的广告系列体现不佳。鉴于这些信息，专门的团队现在可以深入研究了。
发生了什么？在没有任何关于系统的知识的情况下，我们已经缩小了问题的范围，并确定了负责进一步调查的团队。我们能事先知道这种奇怪的操纵系统、操纵系统版本、广告系列类型和应用版本的组合可能会导致一些问题，并准备好相应的度量指标吗？当然不可能。这是处理未知的未知情况的一个例子。我们只是将所有相关的上下文信息存储在广义事件中，并在需要时使用它们。Scuba使得探索变得简单，由于它快速且具有非常漂亮易用的用户界面。还请注意，我们从未提及过基数的任何内容。由于这并不重要 - 任何字段都可以具有任何基数。Scuba使用原始事件举行操纵，不举行预聚合，因此基数不是一个问题。
有时候界面/可视化方面没有得到足够的关注，监测系统提供了一些查询语言 - 可能是专有的（欠好-欠好-欠好），或者是SQL（稍微好一些，但仍旧欠好）。这样的界面几乎不可能举行类似的调查。Scuba的一个重要方面是所有字段（函数、筛选、分组等）都是可探索的。也就是说，有一种简单的方法可以查看我们可以选择的值的类型。当某个字段的所有者不懒惰时，他们甚至会为给定字段提供详细的描述，包括相关链接等。这非常重要。我乐成地举行了许多调查，而我对整个系统或该数据集中的可用数据并没有完全了解。而且在这些调查过程中，我通过与Scuba的互动简单地了解了很多关于系统的知识！这太神奇了。这就是可观测性的天堂。
脱离 Meta 之后的痛楚
现在想象一下，当我脱离 Meta 并了解到外部的可观测性系统的状况时，我有多么狐疑和难以置信。
日志？追踪？指标？这到底是什么？有人知道广义事件吗？我能否不去学习那60个术语的术语表，只是…探索一下东西？
我花了相称长的时间将基于 Scuba 的心智模子映射到 Open Telemetry 的心智模子上。我意识到 Open Telemetry 的 Span 其实就是广义事件。实际上，我仍旧不太确定我是否理解正确：
如果我们以广告展示为例，这个展示实际上并不是一项操纵，它只是我们想要记录的一些究竟… 公平地说，在 Open Telemetry 中确实存在事件（Event）的概念：
但如果我们按照链接深入挖掘，我们会再次发现事件实际上是跟踪、指标或日志之一
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
