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

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

作者：Amnon Heiman

從可觀測性 1.0 到 2.0 的轉(zhuǎn)變增加了很多東西，但我認為我們在此過程中忘記了一些東西。

快速回顧一下可觀測性 1.0 的三大支柱。三個既定的支柱是 指標、日志和追蹤^[2]。我喜歡根據(jù)成本（在系統(tǒng)監(jiān)控方面，CPU、內(nèi)存和磁盤）以及優(yōu)勢和劣勢（基數(shù)、分辨率和保留）對它們進行分類。

? 指標： 數(shù)值，基數(shù)有限，分辨率無限，保留時間很長。它們的系統(tǒng)成本很低。

? 日志： 日志具有無限的基數(shù)、有限的分辨率和有限的保留時間。由于磁盤使用量，它們至少比指標貴一個數(shù)量級。

? 追蹤： 追蹤具有高基數(shù)、低分辨率、長保留時間和相對較高的系統(tǒng)需求。同樣，它們至少比日志貴一到兩個數(shù)量級。

可觀測性 2.0^[3] 引入了上下文作為一等公民。上下文是實踐者已經(jīng)在使用的東西。然而，它存在于正式的可觀測性堆棧之外，并且沒有被明確命名。它還增加了寬事件的概念，為觀察提供了上下文。這兩者都來自于觀察可觀測性已經(jīng)擁有的東西，并識別出缺失的東西。

同樣，我們一直在使用但沒有命名的另一部分是：診斷程序。如果我們現(xiàn)在不認識到這一點，我們就有可能重蹈覆轍：將一項關(guān)鍵能力排除在可觀測性模型之外，直到為時已晚。如果我們將其排除在外，我們將沒有工具或機器可用的知識，在遷移到可觀測性 2.0 時，自動化代理執(zhí)行這些操作所需的工具或機器可用的知識。

醫(yī)學類比

我想舉一個醫(yī)學類比。我承認，我看過太多“豪斯醫(yī)生”的劇集。為自己辯解的是，我也見過很多系統(tǒng)診斷。

一個人根據(jù)癥狀被送進醫(yī)院。工作人員將他們連接到監(jiān)視器（好吧，這是類比中顯而易見的部分），進行一些血液檢查，并通過口頭方式跟蹤他們的狀況。（就像病人喊道，“護士，我頭疼！”）

在這個階段，醫(yī)生可能會查看所有這些輸入，然后決定，“他們只是脫水了”，然后讓他們回家。這是例行的第一線診斷，這是我們在“豪斯醫(yī)生”中幾乎看不到的部分。

但是，當?shù)谝痪€診斷失敗時，另一組診斷程序就會發(fā)揮作用：X 射線、MRI、導管插入術(shù)等等。這些要昂貴得多，并且可能對患者的健康或福祉造成真正的風險。這就是為什么它們是根據(jù)臨床判斷，以特別的方式啟動的，并且具有很強的針對性。

在更復雜的情況下，您可能會聽到諸如“讓我們給他們施加壓力，直到癥狀變得更強烈”或“讓我們沖洗他們，這樣他們就會再次癲癇發(fā)作”之類的話。這些是有意干預，以使隱藏的問題可見。

這里的關(guān)鍵是，診斷程序是選擇性的、有意的，并且由其他數(shù)據(jù)以及調(diào)查人員的經(jīng)驗和理解來告知。

映射到可觀測性

在進一步討論之前，讓我們明確醫(yī)學診斷如何映射到可觀測性診斷。

然后是第四大支柱：診斷程序，它們是用于系統(tǒng)的 MRI、活檢和導管插入術(shù)。這些是罕見的、有針對性的、有時是危險的操作，當我們發(fā)現(xiàn)所有其他方法都無法解釋癥狀時，我們會執(zhí)行這些操作。

系統(tǒng)中的診斷程序

對于軟件系統(tǒng)，診斷是有針對性的、通常是昂貴的、臨時的操作，用于了解內(nèi)部系統(tǒng)行為。讓我們稍微解釋一下。

首先，臨時和有意的。發(fā)起者在系統(tǒng)外部，通常是對癥狀或意外行為做出響應。關(guān)鍵是，決定觸發(fā)它是……由人或由自動化系統(tǒng)做出。

其次，有針對性。我們執(zhí)行該程序是為了回答一個特定的問題或驗證一個假設。關(guān)鍵是它精確且專注（與廣泛且連續(xù)的指標或日志不同）。

最后，成本。這包括系統(tǒng)資源，如 CPU、內(nèi)存、網(wǎng)絡和磁盤，以及任何外部資源（如工程師將探針物理連接到網(wǎng)卡）。成本還包括風險：對系統(tǒng)的潛在影響以及風險實現(xiàn)時的懲罰。

以下是診斷程序的一些真實示例：

? 將日志級別設置為 DEBUG

? 生成核心轉(zhuǎn)儲

? 重置機器

? 連接調(diào)試器

? 運行網(wǎng)絡數(shù)據(jù)包診斷

任何照顧過苦苦掙扎的系統(tǒng)的人可能都能理解。您有理由這樣做，并且您知道這會帶來風險，尤其是在系統(tǒng)已經(jīng)顯示出性能下降的情況下。從成本和風險的角度理解更廣泛的背景是關(guān)鍵。在測試環(huán)境中將調(diào)試器連接到主機以解決已知問題可能會讓您獲得加薪；在生產(chǎn)環(huán)境中執(zhí)行相同的操作可能會讓您被解雇。

診斷程序通常：

? 響應觀察結(jié)果而觸發(fā)。

? 專注于特定的假設。

? 可能對系統(tǒng)穩(wěn)定性造成干擾。

? 在設計上是非連續(xù)的。

看看維基百科對可觀測性的定義：“可觀測性是收集有關(guān)程序執(zhí)行、模塊內(nèi)部狀態(tài)以及組件之間通信的數(shù)據(jù)的能力?！边@正是這些診斷程序所做的。

它們一直都在這里。它們是可觀測性的一個重要方面，但在定義原始支柱時，它們卻被忽視和未命名。就像可觀測性 1.0 中的上下文一樣，它們一直是調(diào)查人員工具包的一部分，但不是重點。

為什么診斷程序現(xiàn)在如此重要

可觀測性 2.0 如此受人關(guān)注是有原因的。它以“A”開頭，以“I”結(jié)尾。

一旦您嘗試教 AI 代理理解您的可觀測性堆棧，您就會意識到上下文很難。對人類來說也很難。這就是為什么我們有熟練的工程師努力診斷有故障的系統(tǒng)。但我們也看到，對人類來說很自然的一些任務對 AI 來說要困難得多。

在可觀測性 2.0 中，我們的目標是為事件提供上下文。對于人類來說，上下文存在于我們的頭腦中（和我們的筆記本中）。這種轉(zhuǎn)變可能會對第一線支持有所幫助，這相當于急診室護士的可觀測性。但很快我們就會遇到下一個障礙：這還不夠。

如果我們希望 AI 不僅僅進行分診，還能進行主動診斷，我們需要將方向盤交給它，而不僅僅是地圖。這意味著以機器可以理解的方式捕獲診斷程序，包括它們的上下文、成本和風險。就像寬事件一樣，AI 需要更廣泛的上下文才能做出有意義的決策。它需要對系統(tǒng)及其操作的可能結(jié)果有更廣泛的理解。

分布式數(shù)據(jù)庫示例

以分布式數(shù)據(jù)庫中典型的高可用性設置為例：復制因子為 3。每條數(shù)據(jù)都存儲在三個節(jié)點上，允許系統(tǒng)在一個節(jié)點出現(xiàn)故障時繼續(xù)正常運行。

現(xiàn)在想象一下，集群正在遭受突發(fā)的高延遲。

? 場景 1： 系統(tǒng)過載。正確的做法可能是減少不必要的后臺任務或添加更多計算資源。

? 場景 2： 一臺機器上的故障磁盤正在減慢操作速度。

發(fā)現(xiàn)一個節(jié)點落后于其他節(jié)點，人工操作員可能會決定重新啟動該節(jié)點，甚至將其從服務中刪除，因為知道其余節(jié)點可以處理負載。同一個人還會檢查全局事件，例如正在進行的升級，以確定此操作是否安全。

雖然在這種設置中丟失一個節(jié)點是可以的，但丟失兩個節(jié)點會破壞可用性。做出這種判斷需要廣泛的背景：了解當前的工作負載、冗余、最近的更改和故障風險。

對于 AI 代理，基于理解更廣泛的背景做出正確的決定可能意味著：

? 通過智能地刪除不穩(wěn)定的節(jié)點來保存系統(tǒng)，以及

? 將其從高延遲變?yōu)橥耆C

Agentic AI 需要什么

如果沒有明確識別和編碼診斷程序（包括其前提條件、成本和后果），AI 將很難^[4]做出這些細致的判斷。

如果我們現(xiàn)在不識別診斷程序，隨著可觀測性 2.0 工具和 AI 驅(qū)動的工作流程的成熟，我們將落后于一項關(guān)鍵能力。

上下文在可觀測性 1.0 的正式支柱中缺失。工具和操作員并非旨在捕獲或使用它。對于 AI 代理來說，自行生成上下文是一項特別艱巨的任務。

同樣的風險也適用于今天的診斷程序。人類將繼續(xù)出于習慣和經(jīng)驗執(zhí)行這些操作，但 AI 代理和自動化系統(tǒng)將沒有掛鉤、保障措施或理解來有效地使用它們。如果我們希望下一代可觀測性真正與我們最好的工程師所能做的事情相匹配，我們需要立即將診斷程序公開化：命名它們、建模它們并為它們設計。

首先，我們需要一種統(tǒng)一的方法來描述它們，捕獲風險、持續(xù)時間、成本、可能的影響、服務級別協(xié)議 (SLA) 考慮因素、可逆性和影響標準等屬性。（例如，請參閱此假設的診斷程序定義^[5]。）

這種方法的美妙之處在于，一旦我們以這種結(jié)構(gòu)化的方式規(guī)范診斷程序，我們自然會開始重新思考它們。通過使這些風險因素顯式化，而不是僅僅依靠直覺，我們可以降低支持工程師今天已經(jīng)在做的事情的危險，并使其對 AI 代理明天做同樣的事情更安全。

其次，我們將需要一種統(tǒng)一和規(guī)范的方式來運行這些程序。例如，AI 代理可能會選擇通過從診斷程序庫中選擇“全面表面掃描”來驗證有關(guān)故障磁盤的假設。它會承認對系統(tǒng)的潛在影響，確定它不會違反 SLA 承諾，并使用 SLA 標準的規(guī)范化規(guī)范來執(zhí)行它：定義什么是服務中斷與服務降級，中斷多長時間是可以接受的，在什么條件下停止以及允許該過程消耗多少系統(tǒng)資源。

引用鏈接

[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