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

作者:薊北

構建面向 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:

  1. 它給的 PromQL 語法上是正確的。

  2. 它對我們的系統一無所知,不知道我們的指標名,當然它對別的公司提供的監控系統也不知道。

  3. 它其實不大瞭解用戶問這個問題真正的意圖,因爲它在這裏的背景知識太少了。

也就是說,看起來 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 版上線,歡迎開發者體驗。

每月 50GB 免費額度讓 Prometheus 成本更低、更可控

近期,可觀測監控 Prometheus 版發佈新計費模式,屏蔽原有上報指標採樣點數量、存儲時長等計費項,以實際寫入數據量(GB)進行計費。

新計費模式單價 & 免費額度:

Prometheus 包含基礎指標、自定義指標。其中,基礎指標以容器服務產生的基礎指標舉例,默認存儲 7 天且免費,不佔用 50GB 免費額度。自定義指標以雲服務器 ECS 實例舉例,每日上報指標量 24.5 萬/實例,每日數據寫入量約 0.093GB/實例。

計算器:https://armsnext.console.aliyun.com/price-gb#/overview

老用戶如何基於新計費模式進行成本預估

1)基本條件

1 條上報指標約 0.5KB;

🔔 注:不同使用模式下存在一定數據量差異,實際使用時請關注。

2)新老對比

以中小企業通常每日上報自定義指標 15000 萬條 ,數據保存 30 天舉例。

  • 新計費(按量付費)

    每月成本:150000000(條) * 0.00000048 (GB/條) * 0.4(元/GB)* 30(天)= 864 元

  • 舊計費(按量付費)

  • 階梯一部分:50000000 條 * 0.0000008(元/條)* 30(天)= 1200元
  • 階梯二部分:100000000 條 * 0.00000065(元/條)* 30(天)= 1950元
  • 總計成本:1200 + 1950 = 3150元

對比兩種計費方式,新計費節省 70% 以上。

點擊此處,瞭解更多 Prometheus 能力!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章