整體思路

在日常運(yùn)維中，經(jīng)常會(huì)遇到類似的問題：明明系統(tǒng)前一天運(yùn)行正常，第二天登錄量突然下降，卻要花費(fèi)大量時(shí)間去手工檢查日志、排查 Prometheus 指標(biāo)，再整理成報(bào)告發(fā)給業(yè)務(wù)方。這類重復(fù)、耗時(shí)的工作不僅影響效率，還容易出現(xiàn)遺漏。于是，我就產(chǎn)生了一個(gè)想法：能不能把這種巡檢工作自動(dòng)化？正好最近在研究 Prometheus 指標(biāo)采集、定時(shí)任務(wù)和大模型工作流，于是就設(shè)計(jì)了一個(gè)小實(shí)驗(yàn)，把“登錄統(tǒng)計(jì)”作為切入點(diǎn)，完整演示了如何實(shí)現(xiàn)自動(dòng)化巡檢的閉環(huán)。

通常在日常運(yùn)維中，我們會(huì)關(guān)注 CPU、磁盤、內(nèi)存等硬件資源的健康狀況，而這里我將巡檢對(duì)象替換成了“用戶登錄信息”，以此作為示例。流程是這樣的：首先通過自定義的 Prometheus Exporter 生成用戶登錄相關(guān)的指標(biāo)數(shù)據(jù)；然后由 Prometheus Server 來采集這些指標(biāo)；接著使用 crontab 配合定時(shí)腳本（inspector.sh）周期性地巡檢和獲取數(shù)據(jù)；最后，腳本會(huì)調(diào)用 Dify 的工作流，將巡檢結(jié)果進(jìn)一步加工，結(jié)合知識(shí)庫(kù)和腳本邏輯生成一份清晰的報(bào)告。這樣做的意義在于：不僅實(shí)現(xiàn)了定時(shí)化、自動(dòng)化的巡檢，而且把數(shù)據(jù)采集、指標(biāo)處理和智能化的結(jié)果生成串聯(lián)起來，形成一個(gè)可復(fù)用的運(yùn)維自動(dòng)化方案。換句話說，這篇文章的核心，是通過“登錄指標(biāo)替代傳統(tǒng)硬件指標(biāo)”的例子，向讀者展示如何用 Prometheus + 定時(shí)任務(wù) + Dify 工作流，把常見的運(yùn)維巡檢場(chǎng)景落地成一個(gè)完整的自動(dòng)化閉環(huán)。

接下來，我們來整理一下文章的順序。我們會(huì)先創(chuàng)建 Dify 工作流，工作流中根據(jù)采集到的用戶登錄情況，創(chuàng)建初步的運(yùn)維方案，然后通過工作流內(nèi)置的知識(shí)庫(kù)檢索生成詳細(xì)運(yùn)維方案。然后在創(chuàng)建定時(shí)巡檢的腳本 Inpector.sh 利用它調(diào)用工作流。接著設(shè)置定時(shí)任務(wù)，定時(shí)從 Prometheus 中拉取 Metrics 指標(biāo)數(shù)據(jù)作為要監(jiān)控的信息，并且調(diào)用Inpector.sh 讓 Dify 工作流返回的信息作為方案生成最終的運(yùn)維執(zhí)行報(bào)告。

安裝 Dify

首先我們嘗試安裝 Dify，這里我們會(huì)選擇在本地使用 Docker 安裝 Dify。

前提條件

安裝 Dify 之前, 請(qǐng)確保你的機(jī)器已滿足最低安裝要求：

• CPU >= 2 Core?
• RAM >= 4 GiB

克隆 Dify 代碼倉(cāng)庫(kù)

克隆 Dify 源代碼至本地環(huán)境。

# 假設(shè)當(dāng)前最新版本為 0.15.3
 git clone https://github.com/langgenius/dify.git --branch 0.15.3

啟動(dòng)容器

進(jìn)入 Dify 源代碼的 Docker 目錄：

cd dify/docker

復(fù)制環(huán)境配置文件：

cp .env.example .env

可以修改 .env 中 Nginx 的端口，默認(rèn)的端口是 80 ，我們修改成 8085。避免與本機(jī)的 80 端口沖突。

EXPOSE_NGINX_PORT=8085

啟動(dòng) Docker 容器：

根據(jù)你系統(tǒng)上的 Docker Compose 版本，選擇合適的命令來啟動(dòng)容器。你可以通過 $ docker compose version 命令檢查版本，詳細(xì)說明請(qǐng)參考 ???Docker 官方文檔??：

如果版本是 Docker Compose V2，使用以下命令：

docker compose up -d

如果版本是 Docker Compose V1，使用以下命令：

docker-compose up -d

運(yùn)行命令后，你應(yīng)該會(huì)看到類似以下的輸出，顯示所有容器的狀態(tài)和端口映射：

[+] Running 11/11
 ? Network docker_ssrf_proxy_network Created 0.1s 
 ? Network docker_default Created 0.0s 
 ? Container docker-redis-1 Started 2.4s 
 ? Container docker-ssrf_proxy-1 Started 2.8s 
 ? Container docker-sandbox-1 Started 2.7s 
 ? Container docker-web-1 Started 2.7s 
 ? Container docker-weaviate-1 Started 2.4s 
 ? Container docker-db-1 Started 2.7s 
 ? Container docker-api-1 Started 6.5s 
 ? Container docker-worker-1 Started 6.4s 
 ? Container docker-nginx-1 Started 7.1s

最后檢查是否所有容器都正常運(yùn)行：

docker compose ps

在這個(gè)輸出中，你應(yīng)該可以看到包括 3 個(gè)業(yè)務(wù)服務(wù) api / worker / web，以及 6 個(gè)基礎(chǔ)組件 weaviate / db / redis / nginx / ssrf_proxy / sandbox 。

NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS
 docker-api-1 langgenius/dify-api:0.6.13 "/bin/bash /entrypoi…" api About a minute ago Up About a minute 5001/tcp
 docker-db-1 postgres:15-alpine "docker-entrypoint.s…" db About a minute ago Up About a minute (healthy) 5432/tcp
 docker-nginx-1 nginx:latest "sh -c 'cp /docker-e…" nginx About a minute ago Up About a minute 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp
 docker-redis-1 redis:6-alpine "docker-entrypoint.s…" redis About a minute ago Up About a minute (healthy) 6379/tcp
 docker-sandbox-1 langgenius/dify-sandbox:0.2.1 "/main" sandbox About a minute ago Up About a minute 
 docker-ssrf_proxy-1 ubuntu/squid:latest "sh -c 'cp /docker-e…" ssrf_proxy About a minute ago Up About a minute 3128/tcp
 docker-weaviate-1 semitechnologies/weaviate:1.19.0 "/bin/weaviate --hos…" weaviate About a minute ago Up About a minute 
 docker-web-1 langgenius/dify-web:0.6.13 "/bin/sh ./entrypoin…" web About a minute ago Up About a minute 3000/tcp
 docker-worker-1 langgenius/dify-api:0.6.13 "/bin/bash /entrypoi…" worker About a minute ago Up About a minute 5001/tcp

通過這些步驟，你可以在本地成功安裝 Dify。通過 Docker Desktop 看到的就是如下圖的樣子。

啟動(dòng) Dify

由于我們之前修改了入口的端口號(hào)， 這里需要通過 8085 端口訪問 dify，如下：

???http://127.0.0.1:8085/install?

接著會(huì)進(jìn)入界面，設(shè)置管理員郵箱，名稱和密碼。

admin
 c12345678

然后按照下面頁(yè)面的方式，登錄就好了。

配置 LLM

在用戶的“配置”界面，點(diǎn)擊“模型供應(yīng)商”，添加如下圖所示的供應(yīng)商。

這里 DeepSeek 用來做模型推理，使用 SILICONFLOW 提供的 BAAI 模型完成向量數(shù)據(jù)庫(kù)的嵌入操作。

創(chuàng)建 workflow

工作流步驟描述如下：

• 獲取參數(shù)（參數(shù)提取器）：從用戶的自然語(yǔ)言中，提取登錄總?cè)藬?shù)，登錄異常人數(shù)等信息。?
• 得到方案（代碼執(zhí)行）：通過代碼判斷異常登錄比例，從而提供基本解決方案。?
• 細(xì)化方案（知識(shí)檢索）：輸入基本解決方案，通過知識(shí)庫(kù)檢索詳細(xì)解決方案。在知識(shí)庫(kù)中保存著所有運(yùn)維的解決方案信息。?
• 生成報(bào)表（ LLM）：根據(jù)詳細(xì)解決方案生成運(yùn)維報(bào)表。

提取參數(shù)

參數(shù)提取器，需要將自然語(yǔ)言轉(zhuǎn)化為參數(shù)，說白了就是要提取自然語(yǔ)言中的關(guān)鍵信息。本例中，登錄的總?cè)藬?shù)和登錄異常人數(shù)就是關(guān)鍵信息。此處會(huì)使用 LLM 幫助我們提取信息，因此需要給 LLM 指令如下：

提取 “總登錄人數(shù)”：文本中 “一共 XX 人登錄” 里的 “XX” 數(shù)值，對(duì)應(yīng)參數(shù)名 “total_login_count”（僅保留數(shù)字，如 “15680”）；
 提取 “成功登錄人數(shù)”：文本中 “成功 XX 人” 里的 “XX” 數(shù)值，對(duì)應(yīng)參數(shù)名 “success_login_count”（僅保留數(shù)字，如 “14739”）；
 提取 “失敗登錄人數(shù)”：文本中 “失敗 XX 人” 里的 “XX” 數(shù)值，對(duì)應(yīng)參數(shù)名 “failed_login_count”（僅保留數(shù)字，如 “941”）；

獲取關(guān)鍵信息之后，會(huì)通過“代碼執(zhí)行”判斷采取的具體方案。由于“代碼執(zhí)行”是“參數(shù)提取器”的下游節(jié)點(diǎn)，所以在“代碼執(zhí)行”中會(huì)對(duì)標(biāo)“參數(shù)提取器”中的兩個(gè)輸出參數(shù)，作為自己節(jié)點(diǎn)的輸入?yún)?shù)。如下圖所示，total_login 和 failed_login_count 作為“參數(shù)提取器”輸出參數(shù)，并作為“代碼執(zhí)行”的輸入?yún)?shù)，輸入到“PYTHON3”的函數(shù)腳本中。

執(zhí)行代碼

在完成提取參數(shù)之后，我們得到了登錄總?cè)藬?shù)和登錄失敗人數(shù)的關(guān)鍵信息，接著需要得到初步的解決方案。這里需要用到代碼執(zhí)行器，按照登錄失敗的比例進(jìn)行判斷，給出方案信息。

代碼執(zhí)行器，python 腳本如下：

def main(total_login: int, failed_login_count: int) -> dict:
 """ 
 參數(shù):
 total_login: 總登錄人數(shù)
 anomaly_count: 異常登錄人數(shù)
 
 返回:
 包含處理建議的字典
 """
 # 邊界情況處理
 if total_login == 0:
 return {"result": "總登錄人數(shù)為0，無(wú)法計(jì)算異常率，請(qǐng)檢查指標(biāo)采集是否正常"}
 
 # 計(jì)算異常率(保留2位小數(shù))
 anomaly_rate = round(failed_login_count / total_login * 100, 2)
 
 # 1級(jí)：輕微異常（異常率≤2%）
 if anomaly_rate <= 2:
 suggestion = """
 1. 監(jiān)控層面：開啟5分鐘粒度的異常趨勢(shì)跟蹤，無(wú)需觸發(fā)告警
 2. 操作層面：抽樣檢查3-5條異常日志，確認(rèn)是否為用戶操作失誤
 3. 后續(xù)跟進(jìn)：若10分鐘內(nèi)異常率持續(xù)上升至2%以上，手動(dòng)升級(jí)處理
 """.strip()
 
 # 2級(jí)：一般異常（2%<異常率≤5%）
 elif anomaly_rate <= 5:
 suggestion = """
 1. 服務(wù)檢查：執(zhí)行kubectl get pods | grep login-service確認(rèn)服務(wù)存活
 2. 日志分析：按錯(cuò)誤類型統(tǒng)計(jì)（4xx/5xx），排查是否集中在特定區(qū)域
 3. 處理動(dòng)作：重啟異常服務(wù)實(shí)例，清理登錄相關(guān)緩存
 4. 通知：同步當(dāng)日值班運(yùn)維工程師關(guān)注
 """.strip()
 
 # 3級(jí)：中度異常（5%<異常率≤10%）
 elif anomaly_rate <= 10:
 suggestion = """
 1. 緊急排查：檢查服務(wù)資源使用率（CPU<80%、內(nèi)存<85%），分析登錄SQL慢查詢
 2. 控制影響：封禁1分鐘內(nèi)失敗次數(shù)>20次的IP（臨時(shí)1小時(shí)），啟用緩存降級(jí)
 3. 協(xié)同響應(yīng)：通知運(yùn)維團(tuán)隊(duì)全員，同步開發(fā)查看近期代碼變更
 4. 進(jìn)度跟蹤：每15分鐘輸出一次異常處理進(jìn)展
 """.strip()
 
 # 4級(jí)：嚴(yán)重異常（10%<異常率≤20%）
 elif anomaly_rate <= 20:
 suggestion = """
 1. 資源擴(kuò)容：登錄服務(wù)實(shí)例緊急擴(kuò)容至原數(shù)量×2，數(shù)據(jù)庫(kù)連接數(shù)調(diào)至2000
 2. 服務(wù)降級(jí)：關(guān)閉登錄積分等非核心功能，對(duì)非會(huì)員啟用驗(yàn)證碼
 3. 應(yīng)急響應(yīng)：電話通知運(yùn)維負(fù)責(zé)人（15分鐘內(nèi)到場(chǎng)），啟動(dòng)應(yīng)急預(yù)案
 4. 進(jìn)度同步：每10分鐘向技術(shù)總監(jiān)匯報(bào)處理進(jìn)度
 """.strip()
 
 # 5級(jí)：緊急異常（異常率>20%）
 else:
 suggestion = """
 1. 全網(wǎng)告警：觸發(fā)短信+電話告警（技術(shù)總監(jiān)、運(yùn)維/開發(fā)負(fù)責(zé)人）
 2. 系統(tǒng)處理：?jiǎn)?dòng)災(zāi)備系統(tǒng)，實(shí)施流量限流（僅允許30%正常流量）
 3. 業(yè)務(wù)協(xié)同：通知業(yè)務(wù)負(fù)責(zé)人評(píng)估影響，成立臨時(shí)應(yīng)急小組
 4. 高層匯報(bào)：每5分鐘在應(yīng)急群更新進(jìn)展，30分鐘向管理層匯報(bào)
 """.strip()
 
 return {"result": suggestion}

如上腳本所示，它是針對(duì)登錄系統(tǒng)異常的自動(dòng)化分析與處置建議工具，核心功能是基于總登錄人數(shù)與異常登錄人數(shù)，通過計(jì)算異常率（保留 2 位小數(shù)）并匹配 5 級(jí)異常分級(jí)標(biāo)準(zhǔn)，輸出精準(zhǔn)的對(duì)應(yīng)處理方案。腳本首先會(huì)處理 “總登錄人數(shù)為 0” 的邊界情況，提示檢查指標(biāo)采集有效性；在正常計(jì)算場(chǎng)景下，會(huì)根據(jù)異常率≤2%（輕微異常）、2%-5%（一般異常）、5%-10%（中度異常）、10%-20%（嚴(yán)重異常）、>20%（緊急異常）的不同區(qū)間，分別生成從監(jiān)控跟蹤、日志抽樣到資源擴(kuò)容、災(zāi)備啟動(dòng)、跨團(tuán)隊(duì)協(xié)同響應(yīng)等不同粒度的操作建議，涵蓋監(jiān)控策略、服務(wù)檢查、資源調(diào)整、人員通知、進(jìn)度跟蹤等全流程動(dòng)作。

需要注意的是，這里返回的“建議”方案只是初步方案會(huì)為后期詳細(xì)方案的搜索和生成提供重要指引。

創(chuàng)建知識(shí)庫(kù)

在完成初步方案的生成之后，我們需要針對(duì)初步方案搜索“運(yùn)維知識(shí)庫(kù)”，從而生成更加詳細(xì)的方案。這里需要提前將知識(shí)庫(kù)建立起來。

如下圖所示，在 Dify 中點(diǎn)擊“知識(shí)庫(kù)”，并且“創(chuàng)建知識(shí)庫(kù)”。

如下圖所示，通過“選擇文件”導(dǎo)入文件。

這里導(dǎo)入的文件就是我們的“運(yùn)維知識(shí)庫(kù)”。如下圖所示，文件內(nèi)容按照操作類型，使用場(chǎng)景進(jìn)行分類。可以通過“代碼執(zhí)行”提供的解決方案在該文檔中查找更多信息，從而細(xì)化解決方案。

接著選擇文檔切割的方式以及文本嵌入的方式，如下圖所示。

界面中可設(shè)置文本分段相關(guān)參數(shù)，如分段標(biāo)識(shí)符（這里是\n\n，即兩個(gè)換行符，用于標(biāo)識(shí)文本分段位置）、分段最大長(zhǎng)度（500 tokens，tokens 是模型處理文本的基本單位，限制單段文本長(zhǎng)度）、分段重疊長(zhǎng)度（50 tokens，控制相鄰分段間重疊的 token 數(shù)量）；還有文本預(yù)處理規(guī)則，比如替換連續(xù)空格、換行符等；以及索引方式（提供 “高質(zhì)量” 和 “經(jīng)濟(jì)” 兩種，影響檢索精度與成本）和Embedding 模型（這里選擇的是BAAI/bge - m3，Embedding 模型用于將文本轉(zhuǎn)化為向量表示，助力后續(xù)檢索等操作）。

這里需要補(bǔ)充一下，知識(shí)庫(kù)嵌入時(shí)需要文本切割和上下文覆蓋（分段覆蓋）的原因：

• 文本切割：大語(yǔ)言模型（LLM）在處理文本時(shí)，存在上下文窗口限制（即能同時(shí)處理的文本長(zhǎng)度有限）。知識(shí)庫(kù)中的文本可能很長(zhǎng)，若不進(jìn)行切割，超出模型上下文窗口的部分就無(wú)法被有效處理。通過按照一定規(guī)則（如基于 token 數(shù)量、特定分隔符等）切割文本，能讓每一段文本都處于模型可處理的長(zhǎng)度范圍內(nèi)，從而保證文本能被 Embedding 模型正確編碼為向量，便于后續(xù)的檢索、匹配等操作。?
• 上下文覆蓋（分段覆蓋）：文本在自然語(yǔ)義上是連貫的，當(dāng)進(jìn)行切割時(shí)，可能會(huì)把一個(gè)完整的語(yǔ)義單元（比如一個(gè)完整的知識(shí)點(diǎn)、邏輯表述）分割到兩個(gè)不同的文本段中。設(shè)置分段重疊長(zhǎng)度，能讓相鄰的文本段之間有部分內(nèi)容重疊。這樣一來，在后續(xù)基于向量檢索等操作時(shí)，即使一個(gè)問題或查詢涉及的內(nèi)容處于兩個(gè)文本段的 “分割處”，由于有重疊部分，也能更好地捕捉到完整的語(yǔ)義信息，避免因文本切割而丟失上下文關(guān)聯(lián)，提升知識(shí)庫(kù)檢索和問答的準(zhǔn)確性。

接著，我們就可以設(shè)置“知識(shí)檢索”的內(nèi)容，如下圖所示，選擇“查詢變量”為“代碼執(zhí)行”的 result 也就是返回的“結(jié)果”，我們可以回想一下在“代碼執(zhí)行”中會(huì)返回“初步的方案”，這里以result 變量的方式輸入到“知識(shí)檢索”中。

換句話說，就是將“代碼執(zhí)行”得到的初步解決方案放到知識(shí)庫(kù)中進(jìn)行檢索，從而得到細(xì)化之后的解決方案。

大模型生成報(bào)告

好了，到了這里就需要將細(xì)化之后的解決方案生成運(yùn)維報(bào)告，指導(dǎo)運(yùn)維工程師處理登錄異常的問題。我們需要利用大模型加上提示詞完成，如下圖所示，在系統(tǒng)提示詞中處理登錄總?cè)藬?shù)和失敗人數(shù)以外，還需要加入“上下文”。 這個(gè)“上下文”就是從知識(shí)庫(kù)中檢索出來的細(xì)化之后的方案。

測(cè)試工作流

通過上面一頓操作，工作流就創(chuàng)建完畢了，接著讓我們測(cè)試工作流是否正常運(yùn)行。

如下圖所示，在工作流的“開始”節(jié)點(diǎn)，添加參數(shù)“user_query”，顧名思義就是用輸入的參數(shù)，用來接受用戶輸入的內(nèi)容。然后，點(diǎn)擊右上角的“運(yùn)行”按鈕，在“user_query”中輸入請(qǐng)求。

輸入請(qǐng)求內(nèi)容如下，很明顯包含了登錄總?cè)藬?shù)，成功登錄人數(shù)，以及失敗人數(shù)的信息。

一共 2350 人登錄，成功 2218 人，失敗 132 人。

可以在右邊欄中看到結(jié)果和追蹤信息。如下圖所示，可以查看工作流每個(gè)步驟的執(zhí)行時(shí)間和執(zhí)行內(nèi)容， 在“結(jié)束”節(jié)點(diǎn)中可以看到最終結(jié)果。

Agent 接入工作流

在完成工作流之后，我們還可以將工作流接入到 Dify 的 Agent 中，這是為了方便客戶端進(jìn)行更好的使用，比如我們可以與工作流進(jìn)行對(duì)話，詢問一些運(yùn)維相關(guān)的處理意見。

需要注意的是，在本例中這個(gè)步驟屬于支線任務(wù)，可做可不做，接入 Agent 的做法是讓我們對(duì) Dify 工作流有更好的使用。并不是僅僅給自動(dòng)化巡檢任務(wù)賦能，還可以一魚多吃，把工作流接入到對(duì)話應(yīng)用中。如果對(duì)這個(gè)不感興趣的同學(xué)，可以直接跳過這個(gè)環(huán)節(jié)。

在接入 Agent 之前，需要發(fā)布工作流，并且“發(fā)布為工具”，如下圖所示。

在 Agent 中會(huì)通過工具調(diào)用的方式引用工作流的能力。

接著， 如下圖所示，創(chuàng)建 Agent。

然后，編輯 Agent 內(nèi)容，如下圖所示。

提示詞的部分，如下：

接受登錄相關(guān)信息。
 例如：“一共 2350 人登錄，成功 2218 人，失敗 132 人。” 得到登錄異常的處理方法。
 調(diào)用工作流 login_inspect

通過舉例的方式告訴 Agent 提示詞“長(zhǎng)什么樣子”（Few-Shot），并且告訴 LLM 調(diào)用對(duì)應(yīng)的工作流：login_inspect。 這個(gè)名字就是我們把工作流發(fā)布為工具的時(shí)候，起的名字。

在右上方選擇一個(gè)處理用戶自然語(yǔ)言的模型，這里選擇我們已經(jīng)定義的 DeepSeek 模型。然后就可以在下方的輸入框中提問，讓 Agent 調(diào)用工作流給出答案了。

輸入如下問題：

一共 2350 人登錄，成功 2218 人，失敗 132 人。

提問之后，可以通過下圖看到結(jié)果。

很明顯，在輸入與登錄相關(guān)的信息之后，Agent 會(huì)調(diào)用工作流 login_inspect ，并且從工作流返回的字段 "tool response" 明顯看到返回的信息。 在最下方，是 Agent 結(jié)合 LLM 潤(rùn)色得到的最終回復(fù)。

當(dāng)然，我們可以通過右上角的“發(fā)布”按鈕，將 Agent 發(fā)布給其他的運(yùn)維人員使用。

編寫定時(shí)任務(wù)腳本

完成工作流的開發(fā)之后，我們需要由一個(gè)定時(shí)任務(wù)獲取 Prometheus Server 的指標(biāo)數(shù)據(jù)，也就是用戶登錄的數(shù)據(jù)，然后再調(diào)用 Dify 工作流對(duì)其進(jìn)行詳細(xì)方案的分析。

具體而言，腳本的主要作用是對(duì)用戶登錄情況進(jìn)行自動(dòng)化巡檢與報(bào)告生成。它會(huì)定期從 Prometheus 中獲取關(guān)鍵指標(biāo)，包括總登錄次數(shù)、登錄成功次數(shù)和失敗次數(shù)，并通過指定路徑的 jq 工具進(jìn)行數(shù)據(jù)解析與匯總。隨后，腳本會(huì)將整理后的結(jié)果轉(zhuǎn)換為結(jié)構(gòu)化文本，調(diào)用本地 Workflow 服務(wù)進(jìn)行進(jìn)一步分析，并輸出直觀的中文結(jié)果。為了保證結(jié)果的可追溯性，腳本會(huì)將每次的分析結(jié)果按時(shí)間戳保存為 JSON 文件存放在 report 目錄中。

先上腳本，再展開講解。

#!/bin/bash

 # ===== 配置部分 =====
 API_KEY="app-QO7DYA9uxq2HApfSVSKKHC0Y"
 BASE_URL="http://127.0.0.1:8085/v1"
 USER_ID="local-user-001"
 PROM_URL="http://localhost:9090"
 LOG_FILE="inspector.log"

 # ===== jq 路徑 =====
 JQ_CMD="/Users/cuihao/opt/anaconda3/bin/jq"

 # ===== 日志函數(shù) =====
 log() {
 TIMESTAMP=$(date +"%Y-%m-%d %H:%M:%S")
 echo "[$TIMESTAMP] $1" | tee -a "$LOG_FILE"
 }

 log "腳本開始執(zhí)行"

 # ===== 查詢 Prometheus 指標(biāo) =====
 log "查詢 Prometheus: 總登錄次數(shù)"
 TOTAL_LOGINS=$(curl -s "${PROM_URL}/api/v1/query?query=user_login_total" \
 | $JQ_CMD '[.data.result[] | .value[1] | tonumber] | add')
 TOTAL_LOGINS=${TOTAL_LOGINS:-0}
 log "總登錄次數(shù): $TOTAL_LOGINS"

 log "查詢 Prometheus: 登錄成功次數(shù)"
 SUCCESS_LOGINS=$(curl -s "${PROM_URL}/api/v1/query?query=user_login_total" \
 | $JQ_CMD '[.data.result[] | select(.metric.login_status=="success") | .value[1] | tonumber] | add')
 SUCCESS_LOGINS=${SUCCESS_LOGINS:-0}
 log "登錄成功次數(shù): $SUCCESS_LOGINS"

 log "查詢 Prometheus: 登錄失敗次數(shù)"
 FAIL_LOGINS=$(curl -s "${PROM_URL}/api/v1/query?query=user_login_total" \
 | $JQ_CMD '[.data.result[] | select(.metric.login_status=="failed") | .value[1] | tonumber] | add')
 FAIL_LOGINS=${FAIL_LOGINS:-0}
 log "登錄失敗次數(shù): $FAIL_LOGINS"

 # ===== 生成 Workflow 輸入文本 =====
 INPUT_TEXT="用戶登錄統(tǒng)計(jì)：總登錄次數(shù): ${TOTAL_LOGINS}，登錄成功: ${SUCCESS_LOGINS}，登錄失敗: ${FAIL_LOGINS}"
 SAFE_INPUT_TEXT=$(echo "$INPUT_TEXT" | $JQ_CMD -Rs .)
 log "生成 Workflow 輸入文本: $INPUT_TEXT"

 # ===== 調(diào)用 Workflow =====
 log "?? 正在調(diào)用 Workflow ..."
 RESPONSE=$(curl -s -X POST "${BASE_URL}/workflows/run" \
 -H "Authorization: Bearer ${API_KEY}" \
 -H "Content-Type: application/json" \
 -d "{
 \"inputs\": {
 \"user_query\": $SAFE_INPUT_TEXT
 },
 \"response_mode\": \"blocking\",
 \"user\": \"${USER_ID}\"
 }")

 log "收到 Workflow 原始響應(yīng): $RESPONSE"

 # ===== 輸出結(jié)果 =====
 echo "? Workflow 返回結(jié)果："
 RESULT=$(echo "${RESPONSE}" | $JQ_CMD -r '.data.outputs["tool response"]')
 echo "$RESULT"
 log "Workflow 中文結(jié)果: $RESULT"

 log "腳本執(zhí)行完成"

 # ===== 保存報(bào)告 =====
 TIMESTAMP=$(date +"%Y%m%d%H%M%S")
 REPORT_DIR="/Users/cuihao/docker/dify/report"
 mkdir -p "$REPORT_DIR"
 REPORT_FILE="${REPORT_DIR}/inspector_${TIMESTAMP}.json"
 echo "$RESULT" > "$REPORT_FILE"
 log "Workflow 結(jié)果已保存到: $REPORT_FILE"

 log "腳本執(zhí)行完成"

腳本分為四步：

配置與日志

定義了 API_KEY、Prometheus 地址、Workflow 服務(wù)地址、日志文件等基本參數(shù)。

使用 log() 函數(shù)統(tǒng)一記錄執(zhí)行過程和結(jié)果，保證排查時(shí)可追溯。

采集指標(biāo)

通過 curl 調(diào)用 Prometheus 的 HTTP API，分別獲取三個(gè)核心指標(biāo)：

• ?總登錄次數(shù)?
• 登錄成功次數(shù)?
• 登錄失敗次數(shù)?

用 jq 解析 Prometheus 返回的 JSON 數(shù)據(jù)，并計(jì)算對(duì)應(yīng)數(shù)值。

生成分析輸入 & 調(diào)用 Workflow

將三個(gè)指標(biāo)拼接成一句中文描述（如“總登錄次數(shù) 100，成功 95，失敗 5”）。

通過 jq 將文本轉(zhuǎn)為 JSON 安全字符串。

調(diào)用本地運(yùn)行的 Workflow 服務(wù)接口，把指標(biāo)數(shù)據(jù)作為輸入，等待返回分析結(jié)果。

結(jié)果輸出與歸檔

在終端和日志中打印 Workflow 的中文結(jié)果。

同時(shí)將結(jié)果保存為 JSON 文件，按時(shí)間戳命名，存放在 report 目錄下，方便后續(xù)留存和比對(duì)。

細(xì)心的你可能發(fā)現(xiàn)了，這個(gè)腳本中定義了工作流的 key，我們需要通過它調(diào)用 Dify 的工作流。下面就來看看如何申請(qǐng)這個(gè) Key。

生成 workflow API 密鑰

如下圖所示，在 Dify 工作室右上角點(diǎn)擊“API 密鑰” 按鈕，在彈出框中選擇“創(chuàng)建密鑰”，請(qǐng)保存好你的密鑰。

生成好的密鑰大概長(zhǎng)下面這個(gè)樣子。

app-QO7DYA9uxq2HApfSVSKKHC0Y

接著可以通過如下命令執(zhí)行腳本，從而測(cè)試能否調(diào)用 Dify 的工作流。

執(zhí)行腳本命令如下：

chmod +x inspector.sh
 ./inspector.sh

如果執(zhí)行完畢之后，在 report 目錄下看到 report 文件，說明執(zhí)行成功了。

配置定時(shí)任務(wù)

由于我用的 Mac OS，為了方便使用 crontab 協(xié)助我完成定時(shí)任務(wù)的執(zhí)行。crontab 是類 Unix 操作系統(tǒng)（如 Linux、macOS）中用于定時(shí)執(zhí)行任務(wù)的工具，其核心是通過 crontab 命令管理定時(shí)任務(wù)列表（即 crontab 文件），并由系統(tǒng)后臺(tái)的 cron 守護(hù)進(jìn)程持續(xù)監(jiān)聽、觸發(fā)任務(wù)。用戶可通過 crontab -e 編輯任務(wù)，每條任務(wù)需遵循 “分 時(shí) 日 月 周 命令” 的固定時(shí)間格式（例如 0 2 * * * /home/backup.sh 表示每天凌晨 2 點(diǎn)執(zhí)行備份腳本），支持使用通配符（如 * 代表所有值）、范圍符（如 1-5 代表周一到周五）靈活設(shè)定執(zhí)行周期，適用于日志切割、數(shù)據(jù)備份、系統(tǒng)監(jiān)控等重復(fù)性操作，無(wú)需人工干預(yù)即可實(shí)現(xiàn)任務(wù)的自動(dòng)化定時(shí)運(yùn)行。

通過如下命令，打開當(dāng)前用戶的 crontab 文件（通常是 vim / nano）。

crontab -e

在 crontab 中輸入如下內(nèi)容，指定要執(zhí)行的文件和日志輸出文件。

*/5 * * * * /bin/bash /Users/cuihao/docker/dify/inspector.sh >> /Users/cuihao/docker/dify/inspector.log 2>&1

這里執(zhí)行的文件就是我們的inspector.sh 腳本文件，它幫助我們調(diào)用 Dify 的工作流，并且返回詳細(xì)的方案信息，接著生成報(bào)告。另外日志輸出文件，是針對(duì) crontab 的執(zhí)行情況的日志。

查看 crontab 任務(wù)：

crontab -l

查看 crontab 任務(wù)執(zhí)行狀態(tài)：

sudo launchctl list | grep cron

測(cè)試整體流程

好了，萬(wàn)事俱備只欠東風(fēng)，通過如下程序生成 Metrics 指標(biāo)數(shù)據(jù)寫入到 Prometheus 中，這樣就有了測(cè)試數(shù)據(jù)。

from prometheus_client import start_http_server, Counter
 import random
 import time

 # 定義登錄指標(biāo)（與告警規(guī)則中的標(biāo)簽完全匹配）
 LOGIN_COUNT = Counter(
 'user_login_total',
 '用戶登錄總次數(shù)及狀態(tài)統(tǒng)計(jì)',
 ['user_type', 'login_status', 'ip_region'] # 包含規(guī)則中用到的user_type、login_status
 )

 def simulate_login(failure_rate=0.2):
 """模擬登錄行為，可指定失敗率（默認(rèn)20%，確保觸發(fā)15%閾值）"""
 # 70%普通用戶，30%管理員（與規(guī)則2的admin類型匹配）
 user_type = random.choices(['normal', 'admin'], weights=[0.7, 0.3])[0]
 
 # 按指定失敗率生成登錄狀態(tài)（默認(rèn)20%失敗，超過15%閾值）
 login_status = random.choices(
 ['success', 'failed'],
 weights=[1 - failure_rate, failure_rate]
 )[0]
 
 # 隨機(jī)地區(qū)（規(guī)則未用到，但不影響）
 ip_region = random.choice(['beijing', 'shanghai', 'guangzhou'])
 
 # 記錄指標(biāo)（標(biāo)簽與規(guī)則中的篩選條件完全對(duì)應(yīng)）
 LOGIN_COUNT.labels(
 user_type=user_type,
 login_status=login_status,
 ip_reginotallow=ip_region
 ).inc()
 
 # 打印失敗日志，方便觀察觸發(fā)情況
 if login_status == 'failed':
 print(f"[失敗] 用戶類型: {user_type}，地區(qū): {ip_region}")

 if __name__ == '__main__':
 # 啟動(dòng)指標(biāo)服務(wù)（9091端口，與Prometheus配置一致）
 start_http_server(9091)
 print("Exporter運(yùn)行中：http://localhost:9091/metrics")
 print("開始模擬登錄（高失敗率，確保觸發(fā)告警）...")
 
 # 持續(xù)模擬登錄（每0.5秒1次，快速累積數(shù)據(jù)，匹配規(guī)則的2分鐘窗口）
 while True:
 simulate_login(failure_rate=0.3) # 20%失敗率，超過15%閾值
 time.sleep(0.5)

此時(shí)，crontab 已經(jīng)開始運(yùn)行了，由于我們?cè)O(shè)置的是 5 分鐘執(zhí)行一次crontab 定義的inspector.sh 腳本。 所以，稍微等待就可以看看inspector_crontab.log 文件中 crontab 任務(wù)的執(zhí)行情況了。

如下所示：

[2025-09-16 15:45:00] 腳本開始執(zhí)行
 [2025-09-16 15:45:00] 查詢 Prometheus: 總登錄次數(shù)
 [2025-09-16 15:45:00] 總登錄次數(shù): 10113
 [2025-09-16 15:45:00] 查詢 Prometheus: 登錄成功次數(shù)
 [2025-09-16 15:45:00] 登錄成功次數(shù): 7117
 [2025-09-16 15:45:00] 查詢 Prometheus: 登錄失敗次數(shù)
 [2025-09-16 15:45:00] 登錄失敗次數(shù): 2996
 [2025-09-16 15:45:00] 生成 Workflow 輸入文本: 用戶登錄統(tǒng)計(jì)：總登錄次數(shù): 10113，登錄成功: 7117，登錄失敗: 2996
 [2025-09-16 15:45:00] ?? 正在調(diào)用 Workflow ...
 ......
 ### **電商平臺(tái)登錄異常應(yīng)急響應(yīng)執(zhí)行報(bào)告**

 **報(bào)告生成時(shí)間：** 2023-10-27 15:00
 **事件主題：** 電商平臺(tái)登錄接口失敗率異常告警
 **報(bào)告人：** 運(yùn)維工程師

 ---

 #### **一、 事件摘要**

 * **事件發(fā)生時(shí)間：** 2023-10-27 14:30 (監(jiān)控系統(tǒng)觸發(fā)告警)
 * **事件級(jí)別：** **緊急異常（5級(jí)）**
 * **核心指標(biāo)：**
 * 登錄請(qǐng)求總數(shù)：11,888
 * 登錄失敗數(shù)：3,527
 * **計(jì)算失敗率：** (3,527 / 11,888) * 100% ≈ **29.7%**
 * **事件現(xiàn)象：** 平臺(tái)登錄接口出現(xiàn)大量失敗請(qǐng)求，失敗率高達(dá)29.7%，遠(yuǎn)超2%的健康閾值，嚴(yán)重影響用戶正常登錄體驗(yàn)，存在重大業(yè)務(wù)風(fēng)險(xiǎn)。
 * **初步判斷：** 此失敗率屬于災(zāi)難性級(jí)別，可能原因包括：認(rèn)證服務(wù)集群故障、數(shù)據(jù)庫(kù)連接池耗盡、緩存（Redis）失效或過載、網(wǎng)絡(luò)分區(qū)、或遭受惡意撞庫(kù)攻擊等。

由于篇幅有限，我們展示一部分的 crontab 日志。從日志中可以看出，腳本采集到 Prometheus Server 的 Metrics 數(shù)據(jù)，以及啟動(dòng) Dify 工作流都成功了，并且看到了詳細(xì)的處理方案和執(zhí)行步驟。

最后，來到 report 目錄下面。如圖所示，可以看到以 report+時(shí)間為名字的 json 文件被創(chuàng)建，并且文件中可以看到報(bào)告內(nèi)容。

作者介紹

崔皓，51CTO社區(qū)編輯，資深架構(gòu)師，擁有18年的軟件開發(fā)和架構(gòu)經(jīng)驗(yàn)，10年分布式架構(gòu)經(jīng)驗(yàn)。