文章讨论了可观测性中被忽视的“诊断程序”概念，类似于医学中的MRI等，用于系统故障诊断。强调了在可观测性2.0时代，为了让AI代理能够进行主动诊断，需要明确诊断程序的定义、风险、成本等，并规范其执行方式，以便AI能够做出更准确的决策。

从可观测性 1.0 到 2.0 的转变增加了很多东西，但我认为我们在此过程中忘记了一些东西。

快速回顾一下可观测性 1.0 的三大支柱。三个既定的支柱是 指标、日志和追踪^[2]。我喜欢根据成本（在系统监控方面，CPU、内存和磁盘）以及优势和劣势（基数、分辨率和保留）对它们进行分类。

• 指标： 数值，基数有限，分辨率无限，保留时间很长。它们的系统成本很低。

• 日志： 日志具有无限的基数、有限的分辨率和有限的保留时间。由于磁盘使用量，它们至少比指标贵一个数量级。

• 追踪： 追踪具有高基数、低分辨率、长保留时间和相对较高的系统需求。同样，它们至少比日志贵一到两个数量级。

可观测性 2.0^[3] 引入了上下文作为一等公民。上下文是实践者已经在使用的东西。然而，它存在于正式的可观测性堆栈之外，并且没有被明确命名。它还增加了宽事件的概念，为观察提供了上下文。这两者都来自于观察可观测性已经拥有的东西，并识别出缺失的东西。

同样，我们一直在使用但没有命名的另一部分是：诊断程序。如果我们现在不认识到这一点，我们就有可能重蹈覆辙：将一项关键能力排除在可观测性模型之外，直到为时已晚。如果我们将其排除在外，我们将没有工具或机器可用的知识，在迁移到可观测性 2.0 时，自动化代理执行这些操作所需的工具或机器可用的知识。

医学类比

我想举一个医学类比。我承认，我看过太多“豪斯医生”的剧集。为自己辩解的是，我也见过很多系统诊断。

一个人根据症状被送进医院。工作人员将他们连接到监视器（好吧，这是类比中显而易见的部分），进行一些血液检查，并通过口头方式跟踪他们的状况。（就像病人喊道，“护士，我头疼！”）

在这个阶段，医生可能会查看所有这些输入，然后决定，“他们只是脱水了”，然后让他们回家。这是例行的第一线诊断，这是我们在“豪斯医生”中几乎看不到的部分。

但是，当第一线诊断失败时，另一组诊断程序就会发挥作用：X 射线、MRI、导管插入术等等。这些要昂贵得多，并且可能对患者的健康或福祉造成真正的风险。这就是为什么它们是根据临床判断，以特别的方式启动的，并且具有很强的针对性。

在更复杂的情况下，您可能会听到诸如“让我们给他们施加压力，直到症状变得更强烈”或“让我们冲洗他们，这样他们就会再次癫痫发作”之类的话。这些是有意干预，以使隐藏的问题可见。

这里的关键是，诊断程序是选择性的、有意的，并且由其他数据以及调查人员的经验和理解来告知。

映射到可观测性

在进一步讨论之前，让我们明确医学诊断如何映射到可观测性诊断。

然后是第四大支柱：诊断程序，它们是用于系统的 MRI、活检和导管插入术。这些是罕见的、有针对性的、有时是危险的操作，当我们发现所有其他方法都无法解释症状时，我们会执行这些操作。

系统中的诊断程序

对于软件系统，诊断是有针对性的、通常是昂贵的、临时的操作，用于了解内部系统行为。让我们稍微解释一下。

首先，临时和有意的。发起者在系统外部，通常是对症状或意外行为做出响应。关键是，决定触发它是……由人或由自动化系统做出。

其次，有针对性。我们执行该程序是为了回答一个特定的问题或验证一个假设。关键是它精确且专注（与广泛且连续的指标或日志不同）。

最后，成本。这包括系统资源，如 CPU、内存、网络和磁盘，以及任何外部资源（如工程师将探针物理连接到网卡）。成本还包括风险：对系统的潜在影响以及风险实现时的惩罚。

以下是诊断程序的一些真实示例：

• 将日志级别设置为 DEBUG

• 生成核心转储

• 重置机器

• 连接调试器

• 运行网络数据包诊断

任何照顾过苦苦挣扎的系统的人可能都能理解。您有理由这样做，并且您知道这会带来风险，尤其是在系统已经显示出性能下降的情况下。从成本和风险的角度理解更广泛的背景是关键。在测试环境中将调试器连接到主机以解决已知问题可能会让您获得加薪；在生产环境中执行相同的操作可能会让您被解雇。

诊断程序通常：

• 响应观察结果而触发。

• 专注于特定的假设。

• 可能对系统稳定性造成干扰。

• 在设计上是非连续的。

看看维基百科对可观测性的定义：“可观测性是收集有关程序执行、模块内部状态以及组件之间通信的数据的能力。”这正是这些诊断程序所做的。

它们一直都在这里。它们是可观测性的一个重要方面，但在定义原始支柱时，它们却被忽视和未命名。就像可观测性 1.0 中的上下文一样，它们一直是调查人员工具包的一部分，但不是重点。

为什么诊断程序现在如此重要

可观测性 2.0 如此受人关注是有原因的。它以“A”开头，以“I”结尾。

一旦您尝试教 AI 代理理解您的可观测性堆栈，您就会意识到上下文很难。对人类来说也很难。这就是为什么我们有熟练的工程师努力诊断有故障的系统。但我们也看到，对人类来说很自然的一些任务对 AI 来说要困难得多。

在可观测性 2.0 中，我们的目标是为事件提供上下文。对于人类来说，上下文存在于我们的头脑中（和我们的笔记本中）。这种转变可能会对第一线支持有所帮助，这相当于急诊室护士的可观测性。但很快我们就会遇到下一个障碍：这还不够。

如果我们希望 AI 不仅仅进行分诊，还能进行主动诊断，我们需要将方向盘交给它，而不仅仅是地图。这意味着以机器可以理解的方式捕获诊断程序，包括它们的上下文、成本和风险。就像宽事件一样，AI 需要更广泛的上下文才能做出有意义的决策。它需要对系统及其操作的可能结果有更广泛的理解。

分布式数据库示例

以分布式数据库中典型的高可用性设置为例：复制因子为 3。每条数据都存储在三个节点上，允许系统在一个节点出现故障时继续正常运行。

现在想象一下，集群正在遭受突发的高延迟。

• 场景 1： 系统过载。正确的做法可能是减少不必要的后台任务或添加更多计算资源。

• 场景 2： 一台机器上的故障磁盘正在减慢操作速度。

发现一个节点落后于其他节点，人工操作员可能会决定重新启动该节点，甚至将其从服务中删除，因为知道其余节点可以处理负载。同一个人还会检查全局事件，例如正在进行的升级，以确定此操作是否安全。

虽然在这种设置中丢失一个节点是可以的，但丢失两个节点会破坏可用性。做出这种判断需要广泛的背景：了解当前的工作负载、冗余、最近的更改和故障风险。

对于 AI 代理，基于理解更广泛的背景做出正确的决定可能意味着：

• 通过智能地删除不稳定的节点来保存系统，以及

• 将其从高延迟变为完全停机

Agentic AI 需要什么

如果没有明确识别和编码诊断程序（包括其前提条件、成本和后果），AI 将很难^[4]做出这些细致的判断。

如果我们现在不识别诊断程序，随着可观测性 2.0 工具和 AI 驱动的工作流程的成熟，我们将落后于一项关键能力。

上下文在可观测性 1.0 的正式支柱中缺失。工具和操作员并非旨在捕获或使用它。对于 AI 代理来说，自行生成上下文是一项特别艰巨的任务。

同样的风险也适用于今天的诊断程序。人类将继续出于习惯和经验执行这些操作，但 AI 代理和自动化系统将没有挂钩、保障措施或理解来有效地使用它们。如果我们希望下一代可观测性真正与我们最好的工程师所能做的事情相匹配，我们需要立即将诊断程序公开化：命名它们、建模它们并为它们设计。

首先，我们需要一种统一的方法来描述它们，捕获风险、持续时间、成本、可能的影响、服务级别协议 (SLA) 考虑因素、可逆性和影响标准等属性。（例如，请参阅此假设的诊断程序定义^[5]。）

这种方法的美妙之处在于，一旦我们以这种结构化的方式规范诊断程序，我们自然会开始重新思考它们。通过使这些风险因素显式化，而不是仅仅依靠直觉，我们可以降低支持工程师今天已经在做的事情的危险，并使其对 AI 代理明天做同样的事情更安全。

其次，我们将需要一种统一和规范的方式来运行这些程序。例如，AI 代理可能会选择通过从诊断程序库中选择“全面表面扫描”来验证有关故障磁盘的假设。它会承认对系统的潜在影响，确定它不会违反 SLA 承诺，并使用 SLA 标准的规范化规范来执行它：定义什么是服务中断与服务降级，中断多长时间是可以接受的，在什么条件下停止以及允许该过程消耗多少系统资源。

引用链接

[1] Observability’s Overlooked Fourth Pillar: Key for Agentic AI: https://thenewstack.io/observabilitys-overlooked-fourth-pillar-key-for-agentic-ai/

[2] 指标、日志和追踪: https://thenewstack.io/observability-working-with-metrics-logs-and-traces/

[3] 可观测性 2.0: https://thenewstack.io/beyond-monitoring-how-observability-2-0-is-revolutionizing-developer-experience/

[4] AI 将很难: https://thenewstack.io/why-ai-demands-a-new-approach-to-observability/

[5] 假设的诊断程序定义: https://gist.github.com/amnonh/42b889f9f53648714565afe938c11bdb

文章来自：51CTO