---
GA: UA-34467841-15
---

# 當AIOps走入K8s：Prometheus可觀測性進化 - 蕭兆洋(Charles Hsiao)

###### tags: `KubeSummit2025` `K8s2025` `2025` `kubernetes` `DE 會議室` `可觀測性` `AIOps` `機器學習 K8s 實例`

<blockquote>
在 Kubernetes Cluster 管理實務中，我們經常面臨這樣的運維困境：Pod 突然 OOM、節點資源意外耗盡、服務延遲無預警飆升，而運維團隊總是在告警響起後才開始緊急救火。想像一下，如果你的 Kubernetes Cluster 能夠像資深 SRE 一樣，具備提前洞察問題並主動調整的智慧能力會如何？

本次演講將深入探討如何運用 Python PyCaret 的 AutoML 技術，充分挖掘 Prometheus metrics 的潛力，構建實用且高效的 AIOps 平台。我們將系統性地剖析四大類型的 Prometheus metrics（Counter、Gauge、Histogram、Summary）在不同運維場景下的最佳應用策略，建立對應的機器學習模型選擇決策框架。

內容涵蓋從時間序列預測模型處理週期性指標變化，到異常檢測算法即時識別系統異常，再到分類回歸模型精準預測資源瓶頸時間點。我們將進一步剖析如何運用外生變數和多維度 metrics 集合，將單一指標分析升級為多元特徵的智能預測系統，並考量實際監控環境的不穩定性，審視不同模型的缺失值與異常點的穩健性，大幅提升預測準確性。

此外，演講還將分享如何結合 LLM 技術將複雜的機器學習預測結果轉化為清晰易懂的運維洞察報告，並說明如何將這些智能預測成果無縫整合到 Kubernetes 的自動化資源調度和故障自癒機制中。

讓我們一起從傳統的被動監控模式，邁向真正的主動預測運維，實現 AIOps 的核心價值！

《聽眾收穫》

AIOps 平台建構能力：

掌握 PyCaret AutoML 實戰應用技巧建立四大 Prometheus metrics 類型對應的機器模型選擇決策框架學會運用外生變數和多維度特徵工程提升預測模型準確性理解機器學習模型如何處理缺失值與異常點的穩健性

智能運維轉型思維：

掌握將機器學習預測結果轉化為 Kubernetes 自動化資源調度的實施策略學會運用 LLM 技術生成人類可理解的運維洞察和決策建議理解從傳統被動監控向主動預測運維模式的轉換路徑和關鍵要素

實戰應用與組織價值：

獲得可立即複製的 AIOps 實施方法論和最佳實踐案例掌握團隊 AIOps 能力建設的評估指標和推動策略學會設計故障自癒系統的核心原則和風險控制機制
</blockquote>

{%hackmd @k8ssummit/announcement-2025 %}

## 會議資訊

**時間：** 13:30 ~ 14:10
**地點：** DE 會議室
**日期：** 2025年10月22日
**語言：** 中文
**難度：** 中階

**相關連結：**
- [KubeSummit 2025 官方網站](https://k8s.ithome.com.tw/2025) [target=_blank]
- [KubeSummit 2025 議程表](https://k8s.ithome.com.tw/2025/agenda) [target=_blank]

## 筆記區

> 請從這裡開始記錄你的筆記
>

pycaret => automl
資源波動率

## 討論區

> 歡迎在此進行討論與 Q&A

(1) 想請問是單一類別的 release unit 就要自己去做 ML 嗎? 如果全部丟進去應該會有滿多誤判? \
Ans: 依據想解決的問題可能會有不一樣的答案，譬如:
- 想依據資源用量去做 Alert group 分群: 這種就適合跨服務的 metrics 一起 training
- 想針對特定服務去預測是否 pod 會 OOM/異常偵測: 每個服務可能造成 OOM 的原因不大一樣，可能有效的特徵也不大一樣，要提升準確度的話，確實實務上可能要 by service 去客製化 ML model，初期導入時會建議從重要的 service 開始 (ex: payment system)

(2) 演講中只拿擴展資源當作實際trigger action的範例，比如說scale replica, increase disk space，實務上autoML有其他更有趣或實用的應用嗎？畢竟metrics資料不像logs那麼豐富~ \
Ans:
- AutoML 比較算是實踐一個 Machine Learning 的懶人方式，實際上任何你想得到的 Machine learning 適用的情境都可以試著透過 AutoML 達成
- 如果整合 logging，最簡單可以拿來當 ML 特徵的可能就是像是 log count(ex: error/warn log) or latency 之類的數值，可能的做法是譬如透過 ML 抓到特定時間區段有異常時，從 logging system 把對應時段的 logs 撈出來，連同 ML 分析的結果一併送給 LLM 去分析
- 現在也有一些工具能做到 Metrics/Logs/Tracing 的整合，譬如開源的 keep: https://www.keephq.dev/

## 相關資源

- 投影片連結：https://www.scribd.com/document/936102836/KubeSummit-2025-%E7%95%B6AIOps%E8%B5%B0%E5%85%A5K8s-Prometheus%E5%8F%AF%E8%A7%80%E6%B8%AC%E6%80%A7%E9%80%B2%E5%8C%96
- 相關文件：(待更新)