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实际情况并非完全如此。Scuba 还具有原生采样的概念。当某个事件被写入 Scuba 时，还必须写入一个称为 samplingRate 的字段，表示此特定事件的采样率。Scuba 使用此信息来正确地“放大”图表上显示的结果，因此无需在头脑中进行这种放大操作。这是一个非常棒的概念，因为它允许动态采样 - 例如，某种类型的展示可能比另一种类型的展示更频繁地进行采样，同时保留 UI 中的“真实”值。因此，底层的实际查询是：
请注意，整个“放大”是由 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）的概念：
但如果我们按照链接深入挖掘，我们会再次发现事件实际上是跟踪、指标或日志之一
标签：Wide,Logs,观测,Metrics,事件,日志,我们,Scuba,广告 From： https://www.cnblogs.com/ulricqin/p/18159755