文章討論了可觀測性中被忽視的“診斷程序”概念，類似于醫學中的MRI等，用于系統故障診斷。強調了在可觀測性2.0時代，為了讓AI代理能夠進行主動診斷，需要明確診斷程序的定義、風險、成本等，并規范其執行方式，以便AI能夠做出更準確的決策。

譯自：Observability’s Overlooked Fourth Pillar: Key for Agentic AI^[1]

作者：Amnon Heiman

從可觀測性 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