云與 AI 成為基礎設施與平臺的當下，運維團隊正面臨多重挑戰(zhàn)：指標、日志、跟蹤數(shù)據(jù)割裂形成的 “數(shù)據(jù)孤島”，被動響應機制導致的平均修復時間攀升，傳統(tǒng)監(jiān)控在動態(tài)微服務架構中的失效等等。

而在現(xiàn)代應用開發(fā)的背景下，可觀測性可以從各種來源收集和分析數(shù)據(jù)：日志、指標和追蹤 —— 以深入了解在你環(huán)境中運行的應用程序的行為。而通過可觀測性方案 + AI，也能為現(xiàn)代 IT 系統(tǒng)實現(xiàn)更加智能的可觀測性。

本周六，第 114 期 OSC 源創(chuàng)會將在北京舉辦，以 “AI 運維「開掛」指南”為主題。Elastic 社區(qū)首席布道師劉曉國將出席活動，并發(fā)表 《通過 AIOps、生成式 AI 和機器學習，實現(xiàn)更智能的可觀測性》主題演講。

在活動正式開始前，先來簡單了解下可觀測方案。

OSCHINA：您提到現(xiàn)代系統(tǒng)需從 “被動響應轉向主動防御”，當前企業(yè)在可觀測性實踐中面臨的最大痛點是什么？傳統(tǒng)監(jiān)控方案為何難以應對云原生環(huán)境下的復雜性？

劉曉國：

數(shù)據(jù)量大，存儲成本高、海量數(shù)據(jù)處理壓力大，很多企業(yè)的可觀測性數(shù)據(jù)（指標，日志及跟蹤）存在于不同的數(shù)據(jù)庫中，從而造成數(shù)據(jù)孤島，手動關連它們或通過一些工具進行轉化比較困難。當真正的事件發(fā)生后，很難找到真正的原因。

另外人工分析這些數(shù)據(jù)幾乎是不可能的，特別是想從被動響應轉向主動防御。 Elastic 的全面可觀測性方案可以采用機器學習的方法來對實時數(shù)據(jù)進行分析，并查看異常事件，從而完成從被動響應轉向主動防御的需求。這些異常的事件可以結合通知 / 告警的方式以不同的形式發(fā)送給運維人員。

云原生環(huán)境中的服務頻繁啟動，停止和擴展，傳統(tǒng)的監(jiān)控很難實時地跟蹤這些變化。另外，傳統(tǒng)監(jiān)控難以在云環(huán)境中捕獲服務的調用鏈和依賴關系。Elastic 的服務圖可以很方便地顯示各個服務之間的調用關系，并在圖上以不同的顏色顯示該服務的健康狀態(tài)。我們可以結合機器學習及大模型來進一步解釋及提供修正的方案。

OSCHINA：Elastic 可觀測性方案的優(yōu)勢是什么？

劉曉國：

Elastic 可觀測性方案把指標，日志，跟蹤及通用分析數(shù)據(jù)保存于同一個數(shù)據(jù)庫中，盡管存在于同一個平臺的不同索引里。Elastic 使用 ECS (Elastic Common Schema) 語義語法來定義統(tǒng)一的字段名稱。這樣不同的索引還是可以通過一些字段進行關聯(lián)。

當一個事件發(fā)生時（比如響應緩慢可以在跟蹤視圖可見），我們可以同時同時在一個平臺查看日志，指標，從而找出真正的事件原因。Elastic 全觀測性方案可以更快地位 IT 團隊找出根因，而不用在各個不同的平臺里進行手動關聯(lián)，或通過一種轉換的方式來進行操作。

OSCHINA：在您遇到的案例中，是否有某個問題通過傳統(tǒng)監(jiān)控完全無法捕捉，卻因 Universal Profiling 的‘全棧可見性’意外暴露？當時團隊如何反應？

劉曉國：

Elastic Universal Profiling? 是一種全系統(tǒng)、始終在線、連續(xù)的分析解決方案，無需代碼檢測、重新編譯、主機上調試符號或服務重新啟動。

通用分析利用 eBPF在 Linux 內核空間內運行，以不引人注目的方式以最小的開銷僅捕獲所需的數(shù)據(jù)。它可以幫我們定位消耗時間最多的函數(shù)以及這些函數(shù)的調用情況，并以火焰圖的形式表達出來。它可以幫我們了解整個基礎架構中哪些代碼行始終消耗 CPU 資?源。我們可以通過 Universal Profiling 工具來優(yōu)化我們的代碼設計。

OSCHINA：AIAssistant 生成的操作建議需要人工復核嗎？在您經歷的案例中，運維團隊對 AI 建議的信任度如何建立？

劉曉國：

我們的 AI Assistant 是基于 LLM RAG 基礎之上的智能助手。我們可以建立自己的知識庫，從而消除人工智能在推理時產生的幻覺。這些知識庫存在于 Elastic 自己的索引里，是可以由運維人員自己創(chuàng)建的，或者直接有運營手冊直接導入的。這些知識庫可以來自 github，runbook， playbook 等。

另外 Elasticsearch 的文檔非常全面，很多大模型對 Elasticsearch 的文檔進行了充分的訓練。通常來說，產生幻覺的機會還是蠻少的。我們將來甚至可以推出自己的大模型。針對有些敏感的操作，我們可以在助手里做出相應的選擇。

在 AI 進行回答問題之前，通常會查看自己的知識庫得到最相近的答案。如果 AI 提供的推理是建立在自己的知識庫之上，或者我們在自己平時積累的解決方案之上，那么 AI 推理提出的解決方案還是相當可以接受的。

OSCHINA：您認為 LLM+Observability 的結合會催生哪些新范式？未來是否可能出現(xiàn) “自主修復系統(tǒng)”？

劉曉國：

是的，這種完全可能。目前在 Elastic 的可觀測性方案中，我們使用 AIOps 來針對可觀測性提供解決方案。由于 LLM 具有良好的推理及總結功能，甚至它還可以幫我們關聯(lián)不同索引里的數(shù)據(jù)。結合私有知識庫，LLM+Observability 為我們的可觀測性提供良好的解決方案。Elastic 的可觀測性其實還有一個叫做 AutoOps 的解決方案。其實主要是針對集群的運行及查詢，攝入的監(jiān)控，并提出相應的解決方案。

OSCHINA：對于資源有限的中小團隊，部署智能可觀測性最應規(guī)避的‘過度設計’陷阱是什么？能否分享一個最小可行方案的搭建路徑？”

劉曉國：

我覺得盡量采用通用標準，比如 OpenTelemetry 從而規(guī)避鎖定廠商。另外，盡量避免工具泛濫，膨脹。工具多了，維護的成本也會增加，帶來的問題也會很多。如把需要的數(shù)據(jù)采集到一個數(shù)據(jù)庫中，而不是分散到不同的平臺中。還有最好采用一下比較成熟的解決方案，而不是一些未經得到證實的方案。

Elastic 其實已經提供了一個比較簡介的部署方案，從數(shù)據(jù)攝取，處理，展示，搜索，及到事件的捕獲，通知 / 告警。在同一個平臺即可搞定所有的事。我們還可以結合人工智能來幫助我們攝取，優(yōu)化，推理，并提供解決方案。

OSCHINA：開發(fā)者需掌握哪些新技能來駕馭智能運維時代？

劉曉國：

日志，指標及跟蹤的數(shù)據(jù)采集，處理及分析技能（Elastic Stack, OpenTelemetry 等）

數(shù)據(jù)整合的能力，比如數(shù)據(jù)采集，清洗，豐富等

熟悉 Kafka, Spark, Flink, Logstash, Beats, Elastic Agents 等數(shù)據(jù)處理框架。

AI/ML 能力。Elastic 中使用 ML 來監(jiān)測異常事件。雖然開發(fā)者不需要掌握很深的 ML 能力，但是知道其作用并如何使用即可。。如果使用 LLMs 來幫助我們分析文件，解決問題。在海量的數(shù)據(jù)里找到洞察。

具有使用一些構建易用，直觀的運維可視化界面能力（比如 Kibana, Grafana 等）

通知及告警

AI agents

OSCHINA：Elastic 近年從搜索引擎擴展到可觀測性、安全甚至生成式 AI領域，這種跨界拓展背后的核心邏輯是什么？在您看來，未來 3 年 Elastic 最可能顛覆的 “下一個生態(tài)位” 會是什么？

劉曉國：

其實 Elastic 在很多年前已經進入到可觀測性及安全領域。早期我們還有企業(yè)搜索。這些構成了 Elastic 的三大技術方案。目前企業(yè)搜索已經退出，更多地集成到我們的 Search 解決方案里。Elastic 在過去的三年里大量投入到 AI 領域。我們的向量搜索庫 Elasticsearch 是世界上下載最多的數(shù)據(jù)庫。

在未來，我們將圍繞 AI 打造智能解決方案。LLMs 為這些提供了良好的基礎。我們結合 MCP 這種 AI agents 通過自然語言的方式對我們的數(shù)據(jù)進行查詢，分析，并提出解決方案。AI 智能體在未來肯定會越來越聰明，并為我們的可觀測性帶來自動處理的能力！