这句来自查理蒂·梅杰斯的名言可能是对当前技术行业可观察性状态的最佳总结——完全的大混乱。每个人都感到困惑。什么是追踪？什么是跨度？日志行是跨度吗？如果我有日志，我还需要追踪吗？如果我有优秀的指标，我为什么需要追踪？类似的问题列表还在继续。查理蒂和其他来自名为Honeycomb的可观察性系统的优秀人才一直在努力解答这些问题。然而，根据我自己的经验，解释查理蒂所说的“日志是垃圾”究竟是什么意思，仍然极其困难，更不用说日志和追踪本质上是相同的事情的事实了。为什么大家都这么困惑？冒险有点尖锐，我要把责任归咎于Open Telemetry。是的，它推动了现代可观察性栈，但我仍然要指责它造成了大混乱。不是因为它是一个糟糕的解决方案——它很棒！但它展示的方式以及解释Open Telemetry是什么以及它所做的事情，使得可观察性显得复杂而棘手。首先，Open Telemetry从一开始就清晰地区分了追踪、指标和日志：OpenTelemetry是一组API、SDK和工具，使用它来进行仪器化，生成、收集和导出遥测数据（指标、日志和追踪），以帮助你分析软件的性能和行为。然后，它更深入地解释了这三者中的每一个。这是OpenTelemetry网站介绍追踪部分的截图。根据我与使用OpenTelemetry的人的交流经验，这种呈现方式确实已成为与可观察性相关的主要图像之一。对某些人来说，这就是可观察性。它也将追踪与其他任何东西区分开来。这显然不是日志，对吧？这也不像指标，对吧？它是一种特殊的东西，可能有点神圣，且需要学习的投资。根据我的经验，一旦人们了解了追踪，他们只会在这种图像及这些词汇（如跨度、根跨度、嵌套跨度等）的背景下进行思考。OpenTelemetry网站有一个包含超过60个术语的词汇表！这一切都异常复杂！但更重要的是，这种对“日志、指标和追踪”的关注是否代表了可观察性的真正力量？诚然，它确实涵盖了一些场景，但当涉及到大规模分布式系统时，更重要的是“深入”数据的能力——“切片和切 丁”，构建和分析各种视图，关联，搜索异常……提供这一切的系统确实存在。当我在Meta工作时，我并不知道我能使用有史以来最好的可观察性系统是一种特权。这个系统叫做Scuba，是人们离开Meta时错失的最大亮点。Scuba的基本理念极为简单，不需要一个词汇表页面供人们理解。它使用宽事件。宽事件只是具有名称和值的字段集合，就像一个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使用此信息来正确“放大”图表上显示的结果，因此无需在内存中进行这种放大。