面向智算服務，構建可觀測體系最佳實踐

作者：薊北

構建面向 AI、大資料、容器的可觀測體系

（一）智算服務可觀測概況

對於越來越火爆的人工智慧領域來說，MLOps 是解決這一領域的系統工程，它結合了所有與機器學習相關的任務和流程，從資料管理、建模、持續部署的到執行時計算和資源管理。下圖是開源 ML-Ops 平臺 MLReef 在 2021 年釋出的 ML 市場相關工具和平臺玩家。時至今日，相關工具與平臺玩家數量保持著持續高速增長。當前，隨著大語言模型（LLM）從新興技術發展為主流技術，以大模型為核心技術的產品將迎來全新迭代。

近期，阿里雲戰略進行了一定調整，確立“AI 驅動，公有云優先”核心戰略。在 AI 領域有哪些產品佈局呢？

基礎設施及服務 IaaS 層
在計算、儲存、網路、安全產品中提供以“靈駿”智算服務為特色的軟硬體一體化的算力叢集服務；
容器即服務 CaaS 層
laaS 層之上以 Kubernetes 為代表的容器技術，已成為雲端計算的新介面， “ACK 靈駿託管叢集”+“雲原生 AI 套件” 產品組合可以高效管理異構資源，提供 AI、HPC 等高效能運算場景下的雲原生增強能力；
平臺即服務 PaaS 層
CaaS 之上的平臺即服務 PaaS 層構建了以 “人工智慧平臺 PAI” 為核心，提供一站式機器學習解決方案；
模型即服務 MaaS 層
提供 “靈機模型服務 DashScope” 、通義大模型和各行業生態大模型、企業專屬定製大模型及 ModelScope 魔搭社群供業內交流，圍繞 AI 各領域模型，透過標準化 API 提供模型推理、模型微調訓練在內的多種服務。

AI 時代下有新技術棧，包括新技術、新資料型別及新工作流。目前可觀測領域產品更多服務於應用開發者，針對 ML 開發者也需要配套的工具來更好地進行除錯、運維及釋出模型服務。為了更好的幫助大家理解，我們先講講可觀測行業頭部企業 DataDog 如何做 AI 可觀測。所謂的 AI 端到端可觀測即從 Infrastructure，Vector Database 再到 Model 和 orchestration framework。DataDog 早已推出了 OpenAI 即 model 這一層的可觀測能力，包括 api 費用、介面響應及 prompt，收穫了非常多小客戶。

本次 2023 Dash 大會將模型從 OpenAI GPT 模型延伸到了更多模型，基本上實現上面所有模型的可觀測能力。隨著各種大模型不斷豐富，每一次請求涉及到的鏈路會非常複雜，對於使用方來說都是黑盒。因此 DataDog 推出 LLM Model Catalog，方便開發者去觀測鏈路上各個節點的異常，介面非常類似 APM 服務列表和鏈路查詢功能。基於 Catalog，不僅可以按照模型提供方維度，服務維度，環境維度等進行瀏覽，清晰看到不同模型效能、請求延遲、請求量以及費用。還可以針對 prompt 進行監控，增加了統一的反饋功能，來對 prompt 結果統一分析。接下來，我們看看國內廠商針對 AI 場景在做進行哪些探索。

（二）Prometheus 雲產品可觀測監控生態

既然圍繞 AI 的可觀測要有一套標準體系，誰來做 AI 可觀測更為合適呢？我們的回答是 Prometheus，因為他天生契合了雲原生架構，在開源領域 Prometheus 處於 Metrics 事實規範的市場地位。

當今多種行業都在做雲原生化改造背景下，Prometheus 在架構、功能維度與 Kubernetes 天然整合。它具有自動服務發現、多層次採集能力、生態強大、通用多模指標模型及強大的 PromQL 查詢語法等特點。下圖是阿里雲所提供的全棧可觀測能力，裡面囊括了上百款阿里雲產品的監控，覆蓋基礎設施、容器、中介軟體、應用等各個層面，而這些產品監控都由 Prometheus 支撐。

阿里雲 Prometheus 整合的眾多雲產品業務指標，針對雲產品多租需求提供了一整套完整的解決方案。每個阿里云云產品除對產品自身指標監控外，同時需要對產品售賣租戶指標進行監控。雲產品針對租戶資源劃分主要分為租戶獨佔資源、租戶共享資源兩種模式，可以給資源打租戶標籤或雲產品自行新增租戶資訊方式來區分租戶。

阿里雲Prometheus 監控相對開源 Prometheus 採用採集、儲存查詢分離架構，採集端具備多租識別和分發能力，儲存端內建多租能力，租戶之間資源是完全隔離的。阿里雲 Prometheus 會每個阿里雲使用者建立一個 Prometheus 雲服務例項來儲存使用者對應的阿里雲產品指標，真正解決了以往監控系統資料分散形成資料孤島的問題，同時為每個雲產品提供了深度定製、開箱即用的大盤和告警能力。

下圖是阿里雲 Prometheus 接入雲產品監控的完整架構，包含以 Pull 模式為主、Push 模式為輔的全場景覆蓋。Pull 模式支援雲產品以 Kubernetes 或 ECS 部署模式，透過指標暴露、日誌或雲監控方式來對接；Push 模式支援以 Prometheus 標準的 Pushgateway、Remote Write 協議將指標推送過來，所有接入模式均支援雲產品面向自身和租戶的兩層監控能力。我後面講到的阿里雲 AI 產品可觀測就是綜合運用了多種接入模式完成相關產品可觀測監控接入的。

（三）阿里雲 AI 可觀測最佳實踐

下面我詳細講下阿里雲 AI 產品體系如何做端到端可觀測體系建設。

最底層 IaaS 層，阿里雲以 “靈駿” 智算服務為特色的軟硬體一體化設計的算力叢集服務，靈駿底層硬體核心由磐久伺服器以及高效能 RDMA 網路兩部分組成，這裡面就包括提供 NAVIDIA A100 高效能 GPU 伺服器。靈駿本身是以節點交付的，靈駿叢集內可以劃分多個分組，分組內包含計算節點。

節點上的計算資源 GPU、RDMA、Nimitz 等元件監控資料自身以 Pushgateway 協議上報的 Prometheus，指標中攜帶租戶標來實現多個租戶的隔離。內建的監控大盤支援叢集級、節點級 GPU、RDMA 等資源的監控能力，涵蓋 IaaS 層常規 CPU、Mem、Disk、Net 以及算力方面的一千餘個指標。

高效能算力之上 CaaS 層，ACK 靈駿託管叢集提供全託管和高可用的控制面的標準 Kubernetes 叢集服務，它作為支援機器學習平臺 PAI 的雲原生底座。ACK 靈駿叢集會預設啟用雲原生 AI 套件，向下封裝對各類異構資源的統一管理，向上提供標準 K8s 叢集環境，提供高效、靈活的一站式 AI 平臺。

ACK 靈駿託管叢集支援對靈駿節點管理，納入到靈駿節點池。AI 套件增強對異構資源排程，透過 GPU 共享排程和 GPU 拓撲感知排程可以高效地管理 GPU 程式以及 GPU 隔離。GPU 監控 2.0 基於 NVIDIA DCGM 來構建。ACK 靈駿叢集內建 Prometheus 監控整合，可以一鍵獲取整個 K8s 叢集全部資源、元件的監控採集。節點上安裝了 ACK 團隊增強的 gpu-exporter 將 DCGM 服務以指標暴露出來，並內建了叢集、節點、Pod 維度 GPU 大盤。

這裡有一點需要說明，常規 GPU 利用率指標採用 nvidia-smi 查詢到整張卡的 GPU 利用率。但 GPU 利用率目前存在一些侷限性，如不能告知使用者有多少 SM 在使用，使用者寫的程式碼到底是真忙還是假忙，程式碼到底在做單雙精度浮點運算（FP32/64）還是在複製資料？此時就需要做一些 Profiling 指標，去檢視更細粒度的指標資訊。

在 PaaS 層，阿里雲人工智慧平臺 PAI，提供了一站式機器學習解決方案。他包含基礎設施，計算引擎和容器，計算框架，ML 從資料準備、模型開發與訓練及模型部署階段的全流程產品，應用於金融、醫療、教育等各領域。

PAI 的可觀測也是最複雜的，我們需要囊括 PAI 各自產品、容器、節點等相應層面的監控覆蓋，每一層的架構、部署方式都有極大差異，接入方式也各不相同。但 Prometheus 儲存、查詢側我們做到了一致的解決方案，以各子產品為隔離粒度的面向租戶的儲存，垂直形成一個租戶邏輯例項，單例項支援 100w/s 寫入，每個產品可以根據業務情況切分例項單獨擴容，邏輯例項可以付費升級成租戶獨享例項支援使用者定義更長儲存週期和更高的隔離粒度確保穩定性。如果使用者想要所有 PAI 產品的監控資料還可以定義全域性聚合例項會返回所有產品監控資訊而不佔用儲存空間。

我們實現了 PAI 產品的全棧可觀測能力，支援 EAS 線上推理指標，DLC 訓練作業級、節點級、LRN 級資源指標的透出，以及容器元件、節點、Pod 等叢集所有資源指標，還有底層基礎設施算力節點的全部監控資料採集、儲存、展示等全方位能力。

最上層 MaaS 層，模型服務靈機 DashScope 圍繞 AI 各領域模型，透過標準化 API 提供模型推理、模型微調訓練在內的多種模型服務。內建包括通義千問、白川開源大語言模型在內的 20+ LLM，支援模型推理、定製，並結合 ModelScope 魔搭社群打造下一代模型及服務共享平臺。

靈積的監控是透過日誌中轉方式實現的，靈機將各種 LLM 大模型以及業務閘道器監控資料寫到日誌系統，Prometheus 透過內部的流式 ETL 工具實時將日誌轉成指標資料分發到各租戶名下，形成了靈機模型 API 層面的監控覆蓋。

正如前面講到的 AI 時代下有新技術棧，目前的可觀測領域產品更多服務於應用開發。當前的 AI 可觀測雖然做到了 IaaS、CaaS、PaaS、MaaS 不同層面核心產品覆蓋，但整套 AI 體系還有更多可觀測需要挖掘和覆蓋的場景，真正做到 AI 端到端全棧可觀測任重而道遠。

可觀測藉助 AI 實現自身資料的深入洞察

（一）Smart Metrics

可觀測離不開告警，告警裡有兩個核心痛點。一是無效告警太多，AIOps 對告警資料做了統計之後發現真實意圖的告警比例僅為 3.05%，典型無效告警配置包括用固定閾值遍歷所有應用/介面，敞口告警可能最初配置沒問題，執行一段時候後業務變化了告警就失效了。二是告警難配，典型的告警頁面僅支援配靜態閾值，而真實的指標（比如 QPS）往往是隨著業務週期變化的，基於靜態閾值的告警配置難、維護難。

Smart Metrics 為了解決上述告警痛點而生，基於歷史資料中學習 Metrics 特徵，並對未來一段時間內 Metrics 正常變化範圍做出預測，生成上下基線。他具有開箱即用免運維、效果可視、準確率高，支援 Grafana 原生告警能力等特徵。

事實上用單一模型是難以滿足多種曲線型別的，我們採用自研分類演算法 + 多模型融合方式，使用者可以自定義靈敏度事件等，多模型可以為每種曲線尋找最合適的演算法，讓我們的產品足夠“Smart”。

這裡簡單介紹兩個使用場景。

場景 1： 針對 QPS 波動性明顯指標，靜態閾值是沒法配置的，智慧演算法可以一鍵產生上下邊界，超出邊界的值我們才認為是可以報警的，這樣就幫使用者解決了如 QPS 等起伏不定指標的告警難配問題。

場景 2： CPU 使用率等一般平穩型指標，會隨著新應用上線發生較大變化。傳統做法需要對釋出後更新閾值，Smart Metrics 可以每天自動更新模型，自動學習新環境，自動生成上下邊界，有效減少“敞口告警”問題產生。

（二）Text2PromQL 問答機器人

如果說用演算法預測監控曲線基本上成為每款監控產品的必備能力，那 Text2PromQL 則是使用 LLM 解決可觀測提效問題的利器。

為什麼我們需要自然語言轉 PromQL 的智慧機器人？PromQL 是 Prometheus 專屬查詢語言，和傳統 SQL 有本質的不同。PromQL 是幾乎所有 K8s 應用的運維工程師最經常使用的查詢語句，沒有之一。寫 PromQL 不是一件簡單的事，用三個 C 來形容它的複雜性。第一個"C"是"Complex"，PromQL 語法其實是比較複雜的；第二個"C"是"Confusing"， PromQL 是由指標名、運算元和 label 組成，指標名有時候會非常難懂。

每個公司都有自己的命名方式，甚至有一些指標是使用者自定義的。監控領域關注的指標又多又雜，有時候看文件都看不明白那些指標到底什麼意思；第三個"C"是"Commenly"，PromQL 是一個非常常用的查詢語言。它不僅能提供運維相關的指標，也可以統計點選率、轉換率、SLA 等業務指標，運維、開發、產品、運營都可以用它。綜上，PromQL 語法不好學、指標名又複雜，日常工作中用得又多，為了減輕 SRE 工作、降低服務工單，也為了 Promethues、K8s 的推廣，我們需要一款自然語言轉 PromQL 的機器人。

我們第一步要做的事情是，先看看 ChatGPT 是不是就可以完成自然語言到 PromQL 的翻譯了。如果大模型本身就可以很好地完成這個任務，那我們不用開發了。就等著通義千問做大做強，我們直接呼叫他們的 API 就行。我們做了一些實驗，發現 ChatGPT 和通義千問，都不能很好地完成這個工作。以 ChatGPT 為例，我問他“給我寫個 PromQL，幫我查一下過去 5min，平均響應時間最長的 10 個應用是啥”。

它給我的回答是：topk(10,avg_over_time(application_response_time_seconds[5m]))

我們看下它哪裡錯了，首先是指標名的事情，在我們的系統中，根本沒有一個叫"application_response_time_seconds"的指標。其次，對平均響應時間的理解也是不對的，正確的例子：

topk(10,sum by (service)(sum_over_time(arms_http_requests_seconds{}[5m]))/sum by (service)(sum_over_time(arms_http_requests_count{}[5m])))

總的來說，通用的 LLM：

它給的 PromQL 語法上是正確的。
它對我們的系統一無所知，不知道我們的指標名，當然它對別的公司提供的監控系統也不知道。
它其實不大瞭解使用者問這個問題真正的意圖，因為它在這裡的背景知識太少了。

也就是說，看起來 LLM 需要更多的知識......

為了給 LLM 灌知識，我們也做了一些調研。總的來說，有 2 種方案：

第一種是 Fine-tuning： 就是你用足夠的語料，對大模型進行微調，這裡的微調指的是，你已經改了模型本身的一些引數，或者你在大模型外接了一個小模型，總之除了 LLM 本身自帶的引數之外，已經有了你自己任務相關的神經網路和引數了。

第二種方案是 Prompt Engineering，提示詞工程：就是我們不會增加或修改大模型本身任意一個引數，我們做的只是在使用者問問題的時候，給它帶一點上下文，作為額外的知識，來提升回答的準確性。

這兩種方案本身沒有優劣之分，我們畫了一顆決策樹，希望能給想要做 LLM-based 應用的同行們一些我們的經驗。

既然選擇了 Prompt Engineering 提示詞工程，下一個問題就是，什麼樣的提示詞是有用的。

我們花了好幾個月的時間，嘗試了 5 種的提示詞，終於，把 Text2PromQL 準確率從 5% 以下，提升到了百分之 70-80%。我們的探索過程使用過 PromQL 官方文件、Stack Overflow 社群問答、阿里雲 ARMS 內部客戶 QA 問答（這裡包含了我們自己系統的指標名資訊）、ARMS 內部 PromQL 問答示例 + ChatGPT 生成的 PromQL 解釋等手段準確率可以到 20% 左右。

直到引入 Chain-of-Thought 格式 PromQL 問答示例，準確率一下子提升到 60-70%，終於迎來了第一個拐點。最後我們基於 Chain-of-Thought 格式 PromQL 問答+通義千問，準確率原地漲了 10%，達到 80% 左右。即使不完全對的場景，也給了指標名、該用的運算元等非常有用的資訊，而且語法基本不會錯了。通義千問確實很厲害！

Chain-of-Thought 是 Google Brain 實驗室提出來演算法，本來用來增強 LLM 推理能力的，它的提示詞是帶有推理步驟的知識。推理過程很像解小學數學題。

普通提示詞：

Q：Roger 有 5 個羽毛球，他又買了 2 桶，每桶有 3 個，那他現在有幾個。

A：答案是 11。

理論上，LLM 應該能照葫蘆畫瓢回答出來，但是他的答案是錯誤的。

Google 給的 Chain-of-Thought 提示詞：

Q：Roger 有 5 個羽毛球，他又買了 2 桶，每桶有 3 個，那他現在有幾個。

A：Roger 本來有 5 個球，買了 2 桶，每桶 3 個的球，也就是 6 個球。5+6=11。所以答案是 11。

這裡就是給了例子中的推導過程。

然後，奇蹟發生了，GPT 居然就會了，給了正確的答案。

下面我們來介紹 CoT 演算法，在 Text2PromQL 場景下是怎麼使用的。

這是我們的架構圖，我們擁有一個離線系統和一個線上系統。在離線系統中，我們將 ARMS 多年沉澱的，大量使用者關於 Text2PromQL 的問答示例，透過 Chain-of-Chain Prompting 演算法，轉換成 Chain-of-thought 格式 Q&A 示例，然後進行文字切割，得到 Q&A 示例。然後透過 embedding，將文字轉換為數字組成的向量。再把這些向量存到資料庫中；線上系統中，當一個使用者提問，比如寫一個 PromQL，查平均響應時間最長的 10 個應用，我們會把這些文字透過 embedding 轉換成數字組成的向量。

現在我們擁有了使用者問題轉換出來的向量以及離線系統中資料庫中一系列向量。那麼，我們就可以在資料庫中檢索和當前使用者問題最相似的 topk 個向量，把這個 k+1個數字組成的向量還原為文字，然後把使用者的問題以及 k 個最相似的歷史 Q&A 作為提示詞輸入到大模型中，從而可以得到最終 PromQL。可以看到，我們這個系統初始的輸入是使用者的 PromQL 問答示例，所以當使用者問得越多，我們能覆蓋的場景也越多，準確率也會越高，總的來說，我們的機器人會越問越聰明。

我們當前覆蓋了 20+ 場景，準確率 76.9%。即使在沒有覆蓋的場景下，也能給出非常多有用的資訊。更重要的是，因為我們是 Prompt Engineering，透過給提示詞增加模型的準確率，所以覆蓋新場景非常快，只要給它生成 CoT 格式的提示詞就好。目前 Smart Metrics 和 Text2PromQL 已經在阿里雲可觀測視覺化 Grafana 版上線，歡迎開發者體驗。