序言 “狼來了”

"叮咚！CPU使用率超過90%！"

"叮咚！內(nèi)存占用達到80%！"

"叮咚！連接池資源空閑數(shù)低于5%！"

凌晨3點，我們的老演員，運維工程師小李，再次被釘釘機器人中監(jiān)控的Prometheus的告警吵醒，他盯著手機屏幕，眼神呆滯，本著“小心駛得萬年船，不可讓一個故障漏網(wǎng)”的原則，他還是艱難地對抗了睡意，把所有系統(tǒng)健康指標(biāo)進行逐一排查，如期所料，又是一起誤報。

“悠悠蒼天，何薄于我？這玩意監(jiān)控了個寂寞呀?！?/p>

告警對于廣大運維人員來說，真的是又愛又恨，不用長時間監(jiān)控系統(tǒng)有異常之后通知運維人員，極大的節(jié)省了時間，但隨著設(shè)備規(guī)模的大量增加，原本較少誤報突然呈現(xiàn)了爆炸式的增長，從而使得“狼來了”式的告警逐漸降低了運維人員的警惕閾值，從而使得正真的故障狼來了之時，運維人員可能還蒙在鼓里，毫無反應(yīng)。

前章 “AI智能體”

AI時代，是否有更好的解決方案？熱烈歡迎本場的主角“AI智能體”上線。

AI智能體，通常是指能夠感知環(huán)境、自主決策并執(zhí)行動作以實現(xiàn)特定目標(biāo)的一類人工智能系統(tǒng)。該系統(tǒng)結(jié)合了感知、推理、學(xué)習(xí)和行動能力，可以獨立或在人工協(xié)同指導(dǎo)下完成任務(wù)。

那么如何通過構(gòu)建AI智能體來處理Prometheus的告警呢？基本可以遵循如下的功能模塊來處置。

▍一、感知模塊

負(fù)責(zé)接收和處理來自環(huán)境的各類信息，為后續(xù)決策提供所需的數(shù)據(jù)支持。該部分的準(zhǔn)確性和敏感度會直接影響到后續(xù)的處理。常見的感知模塊一般可以使用如下方式：

文本感知：NLP模型（BERT/GPT）

圖像感知：CV模型（YOLO/ResNet）

語音感知：ASR系統(tǒng)

▍二、認(rèn)知引擎

負(fù)責(zé)記錄相關(guān)故障處置的上下文信息及對應(yīng)處置經(jīng)驗。按照信息存活時間及相關(guān)信息的固化特征可以分為：

短期記憶：對話上下文管理（LSTM/Transformer）

長期記憶：一般使用知識圖譜、向量數(shù)據(jù)庫

在構(gòu)建對應(yīng)的認(rèn)知記憶過程需要遵循嚴(yán)格的標(biāo)準(zhǔn)，比如在AI智能體在處理Prometheus告警時，需要考慮如下的因素：

歷史性：異常指標(biāo)是否在相同周期內(nèi)出現(xiàn)

全局性：異常指標(biāo)在集群架構(gòu)下影響力

價值性：何種嚴(yán)重程度需要提示為告警，把小李從床上拉起來

基礎(chǔ)信息：持續(xù)時間、嚴(yán)重程度

關(guān)聯(lián)關(guān)系：服務(wù)組來源信息

同時對于告警的處置結(jié)果執(zhí)行方式也分為三個星級：

一星告警："嗯。"（記錄日志完事）

二星告警："嗯？"（發(fā)個Slack消息）

三星告警："??！"（打電話+發(fā)短信+在辦公室拉防空警報）

▍三、決策中心

該模塊通過綜合考慮各種因素，運用邏輯推理和概率統(tǒng)計等方法，做出最優(yōu)決策。在大模型逐漸成熟的當(dāng)下，該部分主要由各大模型來扮演，如DeepSeek、GPT等，相關(guān)介紹材料很多，在此不再贅述。

▍四、執(zhí)行模塊

依據(jù)決策中心提供的處理意見完成對應(yīng)處理工作，設(shè)計的核心是完成與相關(guān)業(yè)務(wù)系統(tǒng)的交互與聯(lián)動，通?？梢酝ㄟ^如下方式完成：

API調(diào)用：OpenAPI規(guī)范封裝

RPA操作：Playwright/Airflow集成

執(zhí)行模塊是最終呈現(xiàn)處置的關(guān)鍵部分，最終來衡量AI智能體在過程中非人工介入程度，與工具的對接的豐富度及耦合度決定了執(zhí)行的準(zhǔn)確性。

▍五、反饋系統(tǒng)

實現(xiàn)系統(tǒng)的持續(xù)自我優(yōu)化，通過計算關(guān)鍵指標(biāo)（如任務(wù)完成率、耗時）來進行效果評估。常見的模型更新：

在線學(xué)習(xí)：Bandit算法實時調(diào)整策略

離線訓(xùn)練：每周全量數(shù)據(jù)retraining

終章 “不看廣告，看療效”

▍第一回合：CPU使用率告警

Prometheus："報！CPU沖到95%了！"

AI："淡定，這是每日報表生成時間，你家CPU在996呢"

結(jié)果：標(biāo)記為"預(yù)期波動"，Slack發(fā)個已處理消息

▍第二回合：磁盤空間不足

Prometheus："急急急！/var只剩5%了！"

AI："（查看歷史記錄）發(fā)現(xiàn)這個分區(qū)每周三都會這樣...等等，日志輪轉(zhuǎn)腳本又睡懶覺了？"

結(jié)果：自動觸發(fā)日志清理腳本，并在Jira創(chuàng)建工單："日志輪轉(zhuǎn)腳本又雙叒叕偷懶了"

▍第三回合：數(shù)據(jù)庫連接池耗盡

Prometheus："藥丸！連接池100%了！"

AI："（0.1秒內(nèi)掃描全鏈路）前端流量激增→促銷活動忘了限流→這不是故障，這是KPI在發(fā)光??！"

結(jié)果：自動擴容數(shù)據(jù)庫實例+@市場部："親，下次搞活動記得提前說哦~"

寫在最后：AI不是終點，而是起點

記住：

再智能的AI也干不過寫bug的程序員

再精準(zhǔn)的過濾也擋不住老板的突發(fā)奇想

最好的監(jiān)控系統(tǒng)也永遠有一個會罵“這什么破AI”的幕后運維小李

在完成該文章的過程中，消耗了作者4杯咖啡和12次對Prometheus的告警的親切問候。

審核編輯 黃宇