作者 | 崔皓
審校 | 重樓
整體思路
在日常運維中，經常會遇到類似的問題：明明系統前一天運行正常，第二天登錄量突然下降，卻要花費大量時間去手工檢查日志、排查 Prometheus 指標，再整理成報告發給業務方。這類重復、耗時的工作不僅影響效率，還容易出現遺漏。于是，我就產生了一個想法：能不能把這種巡檢工作自動化？正好最近在研究 Prometheus 指標采集、定時任務和大模型工作流，于是就設計了一個小實驗，把“登錄統計”作為切入點，完整演示了如何實現自動化巡檢的閉環。
通常在日常運維中，我們會關注 CPU、磁盤、內存等硬件資源的健康狀況，而這里我將巡檢對象替換成了“用戶登錄信息”，以此作為示例。流程是這樣的：首先通過自定義的 Prometheus Exporter 生成用戶登錄相關的指標數據；然后由 Prometheus Server 來采集這些指標；接著使用 crontab 配合定時腳本（inspector.sh）周期性地巡檢和獲取數據；最后，腳本會調用 Dify 的工作流，將巡檢結果進一步加工，結合知識庫和腳本邏輯生成一份清晰的報告。這樣做的意義在于：不僅實現了定時化、自動化的巡檢，而且把數據采集、指標處理和智能化的結果生成串聯起來，形成一個可復用的運維自動化方案。換句話說，這篇文章的核心，是通過“登錄指標替代傳統硬件指標”的例子，向讀者展示如何用 Prometheus + 定時任務 + Dify 工作流，把常見的運維巡檢場景落地成一個完整的自動化閉環。
接下來，我們來整理一下文章的順序。我們會先創建 Dify 工作流，工作流中根據采集到的用戶登錄情況，創建初步的運維方案，然后通過工作流內置的知識庫檢索生成詳細運維方案。然后在創建定時巡檢的腳本 Inpector.sh 利用它調用工作流。接著設置定時任務，定時從 Prometheus 中拉取 Metrics 指標數據作為要監控的信息，并且調用Inpector.sh 讓 Dify 工作流返回的信息作為方案生成最終的運維執行報告。
安裝 Dify
首先我們嘗試安裝 Dify，這里我們會選擇在本地使用 Docker 安裝 Dify。
前提條件
安裝 Dify 之前, 請確保你的機器已滿足最低安裝要求：
- CPU >= 2 Core
- RAM >= 4 GiB
操作系統 | 軟件 | 描述 |
macOS 10.14 or later | Docker Desktop | 為 Docker 虛擬機（VM）至少分配 2 個虛擬 CPU(vCPU) 和 8GB 初始內存，否則安裝可能會失敗。 |
Linux platforms | Docker 19.03 or later Docker Compose 1.28 or later | 請參閱安裝 Docker 和安裝 Docker Compose 以獲取更多信息。 |
Windows with WSL 2 enabled | Docker Desktop | 我們建議將源代碼和其他數據綁定到 Linux 容器中時，將其存儲在 Linux 文件系統中，而不是 Windows 文件系統中。 |
克隆 Dify 代碼倉庫
克隆 Dify 源代碼至本地環境。
# 假設當前最新版本為 0.15.3
git clone https://github.com/langgenius/dify.git --branch 0.15.3啟動容器
進入 Dify 源代碼的 Docker 目錄：
cd dify/docker復制環境配置文件：
cp .env.example .env可以修改 .env 中 Nginx 的端口，默認的端口是 80 ，我們修改成 8085。避免與本機的 80 端口沖突。
EXPOSE_NGINX_PORT=8085啟動 Docker 容器：
根據你系統上的 Docker Compose 版本，選擇合適的命令來啟動容器。你可以通過 $ docker compose version 命令檢查版本，詳細說明請參考 Docker 官方文檔：
如果版本是 Docker Compose V2，使用以下命令：
docker compose up -d如果版本是 Docker Compose V1，使用以下命令：
docker-compose up -d運行命令后，你應該會看到類似以下的輸出，顯示所有容器的狀態和端口映射：
[+] 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最后檢查是否所有容器都正常運行：
docker compose ps在這個輸出中，你應該可以看到包括 3 個業務服務 api / worker / web，以及 6 個基礎組件 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 看到的就是如下圖的樣子。
啟動 Dify
由于我們之前修改了入口的端口號， 這里需要通過 8085 端口訪問 dify，如下：
http://127.0.0.1:8085/install接著會進入界面，設置管理員郵箱，名稱和密碼。
admin
c12345678然后按照下面頁面的方式，登錄就好了。
配置 LLM
在用戶的“配置”界面，點擊“模型供應商”，添加如下圖所示的供應商。
這里 DeepSeek 用來做模型推理，使用 SILICONFLOW 提供的 BAAI 模型完成向量數據庫的嵌入操作。
創建 workflow
工作流步驟描述如下：
- 獲取參數（參數提取器）：從用戶的自然語言中，提取登錄總人數，登錄異常人數等信息。
- 得到方案（代碼執行）：通過代碼判斷異常登錄比例，從而提供基本解決方案。
- 細化方案（知識檢索）：輸入基本解決方案，通過知識庫檢索詳細解決方案。在知識庫中保存著所有運維的解決方案信息。
- 生成報表（ LLM）：根據詳細解決方案生成運維報表。
提取參數
參數提取器，需要將自然語言轉化為參數，說白了就是要提取自然語言中的關鍵信息。本例中，登錄的總人數和登錄異常人數就是關鍵信息。此處會使用 LLM 幫助我們提取信息，因此需要給 LLM 指令如下：
提取 “總登錄人數”：文本中 “一共 XX 人登錄” 里的 “XX” 數值，對應參數名 “total_login_count”（僅保留數字，如 “15680”）；
提取 “成功登錄人數”：文本中 “成功 XX 人” 里的 “XX” 數值，對應參數名 “success_login_count”（僅保留數字，如 “14739”）；
提取 “失敗登錄人數”：文本中 “失敗 XX 人” 里的 “XX” 數值，對應參數名 “failed_login_count”（僅保留數字，如 “941”）；獲取關鍵信息之后，會通過“代碼執行”判斷采取的具體方案。由于“代碼執行”是“參數提取器”的下游節點，所以在“代碼執行”中會對標“參數提取器”中的兩個輸出參數，作為自己節點的輸入參數。如下圖所示，total_login 和 failed_login_count 作為“參數提取器”輸出參數，并作為“代碼執行”的輸入參數，輸入到“PYTHON3”的函數腳本中。
執行代碼
在完成提取參數之后，我們得到了登錄總人數和登錄失敗人數的關鍵信息，接著需要得到初步的解決方案。這里需要用到代碼執行器，按照登錄失敗的比例進行判斷，給出方案信息。
代碼執行器，python 腳本如下：
def main(total_login: int, failed_login_count: int) -> dict:
"""
參數:
total_login: 總登錄人數
anomaly_count: 異常登錄人數
返回:
包含處理建議的字典
"""
# 邊界情況處理
if total_login == 0:
return {"result": "總登錄人數為0，無法計算異常率，請檢查指標采集是否正常"}
# 計算異常率(保留2位小數)
anomaly_rate = round(failed_login_count / total_login * 100, 2)
# 1級：輕微異常（異常率≤2%）
if anomaly_rate <= 2:
suggestion = """
1. 監控層面：開啟5分鐘粒度的異常趨勢跟蹤，無需觸發告警
2. 操作層面：抽樣檢查3-5條異常日志，確認是否為用戶操作失誤
3. 后續跟進：若10分鐘內異常率持續上升至2%以上，手動升級處理
""".strip()
# 2級：一般異常（2%<異常率≤5%）
elif anomaly_rate <= 5:
suggestion = """
1. 服務檢查：執行kubectl get pods | grep login-service確認服務存活
2. 日志分析：按錯誤類型統計（4xx/5xx），排查是否集中在特定區域
3. 處理動作：重啟異常服務實例，清理登錄相關緩存
4. 通知：同步當日值班運維工程師關注
""".strip()
# 3級：中度異常（5%<異常率≤10%）
elif anomaly_rate <= 10:
suggestion = """
1. 緊急排查：檢查服務資源使用率（CPU<80%、內存<85%），分析登錄SQL慢查詢
2. 控制影響：封禁1分鐘內失敗次數>20次的IP（臨時1小時），啟用緩存降級
3. 協同響應：通知運維團隊全員，同步開發查看近期代碼變更
4. 進度跟蹤：每15分鐘輸出一次異常處理進展
""".strip()
# 4級：嚴重異常（10%<異常率≤20%）
elif anomaly_rate <= 20:
suggestion = """
1. 資源擴容：登錄服務實例緊急擴容至原數量×2，數據庫連接數調至2000
2. 服務降級：關閉登錄積分等非核心功能，對非會員啟用驗證碼
3. 應急響應：電話通知運維負責人（15分鐘內到場），啟動應急預案
4. 進度同步：每10分鐘向技術總監匯報處理進度
""".strip()
# 5級：緊急異常（異常率>20%）
else:
suggestion = """
1. 全網告警：觸發短信+電話告警（技術總監、運維/開發負責人）
2. 系統處理：啟動災備系統，實施流量限流（僅允許30%正常流量）
3. 業務協同：通知業務負責人評估影響，成立臨時應急小組
4. 高層匯報：每5分鐘在應急群更新進展，30分鐘向管理層匯報
""".strip()
return {"result": suggestion}如上腳本所示，它是針對登錄系統異常的自動化分析與處置建議工具，核心功能是基于總登錄人數與異常登錄人數，通過計算異常率（保留 2 位小數）并匹配 5 級異常分級標準，輸出精準的對應處理方案。腳本首先會處理 “總登錄人數為 0” 的邊界情況，提示檢查指標采集有效性；在正常計算場景下，會根據異常率≤2%（輕微異常）、2%-5%（一般異常）、5%-10%（中度異常）、10%-20%（嚴重異常）、>20%（緊急異常）的不同區間，分別生成從監控跟蹤、日志抽樣到資源擴容、災備啟動、跨團隊協同響應等不同粒度的操作建議，涵蓋監控策略、服務檢查、資源調整、人員通知、進度跟蹤等全流程動作。
需要注意的是，這里返回的“建議”方案只是初步方案會為后期詳細方案的搜索和生成提供重要指引。
創建知識庫
在完成初步方案的生成之后，我們需要針對初步方案搜索“運維知識庫”，從而生成更加詳細的方案。這里需要提前將知識庫建立起來。
如下圖所示，在 Dify 中點擊“知識庫”，并且“創建知識庫”。
如下圖所示，通過“選擇文件”導入文件。
這里導入的文件就是我們的“運維知識庫”。如下圖所示，文件內容按照操作類型，使用場景進行分類?？梢酝ㄟ^“代碼執行”提供的解決方案在該文檔中查找更多信息，從而細化解決方案。
接著選擇文檔切割的方式以及文本嵌入的方式，如下圖所示。
界面中可設置文本分段相關參數，如分段標識符（這里是\n\n，即兩個換行符，用于標識文本分段位置）、分段最大長度（500 tokens，tokens 是模型處理文本的基本單位，限制單段文本長度）、分段重疊長度（50 tokens，控制相鄰分段間重疊的 token 數量）；還有文本預處理規則，比如替換連續空格、換行符等；以及索引方式（提供 “高質量” 和 “經濟” 兩種，影響檢索精度與成本）和Embedding 模型（這里選擇的是BAAI/bge - m3，Embedding 模型用于將文本轉化為向量表示，助力后續檢索等操作）。
這里需要補充一下，知識庫嵌入時需要文本切割和上下文覆蓋（分段覆蓋）的原因：
- 文本切割：大語言模型（LLM）在處理文本時，存在上下文窗口限制（即能同時處理的文本長度有限）。知識庫中的文本可能很長，若不進行切割，超出模型上下文窗口的部分就無法被有效處理。通過按照一定規則（如基于 token 數量、特定分隔符等）切割文本，能讓每一段文本都處于模型可處理的長度范圍內，從而保證文本能被 Embedding 模型正確編碼為向量，便于后續的檢索、匹配等操作。
- 上下文覆蓋（分段覆蓋）：文本在自然語義上是連貫的，當進行切割時，可能會把一個完整的語義單元（比如一個完整的知識點、邏輯表述）分割到兩個不同的文本段中。設置分段重疊長度，能讓相鄰的文本段之間有部分內容重疊。這樣一來，在后續基于向量檢索等操作時，即使一個問題或查詢涉及的內容處于兩個文本段的 “分割處”，由于有重疊部分，也能更好地捕捉到完整的語義信息，避免因文本切割而丟失上下文關聯，提升知識庫檢索和問答的準確性。
接著，我們就可以設置“知識檢索”的內容，如下圖所示，選擇“查詢變量”為“代碼執行”的 result 也就是返回的“結果”，我們可以回想一下在“代碼執行”中會返回“初步的方案”，這里以result 變量的方式輸入到“知識檢索”中。
換句話說，就是將“代碼執行”得到的初步解決方案放到知識庫中進行檢索，從而得到細化之后的解決方案。
大模型生成報告
好了，到了這里就需要將細化之后的解決方案生成運維報告，指導運維工程師處理登錄異常的問題。我們需要利用大模型加上提示詞完成，如下圖所示，在系統提示詞中處理登錄總人數和失敗人數以外，還需要加入“上下文”。 這個“上下文”就是從知識庫中檢索出來的細化之后的方案。
測試工作流
通過上面一頓操作，工作流就創建完畢了，接著讓我們測試工作流是否正常運行。
如下圖所示，在工作流的“開始”節點，添加參數“user_query”，顧名思義就是用輸入的參數，用來接受用戶輸入的內容。然后，點擊右上角的“運行”按鈕，在“user_query”中輸入請求。
輸入請求內容如下，很明顯包含了登錄總人數，成功登錄人數，以及失敗人數的信息。
一共 2350 人登錄，成功 2218 人，失敗 132 人。
可以在右邊欄中看到結果和追蹤信息。如下圖所示，可以查看工作流每個步驟的執行時間和執行內容， 在“結束”節點中可以看到最終結果。
Agent 接入工作流
在完成工作流之后，我們還可以將工作流接入到 Dify 的 Agent 中，這是為了方便客戶端進行更好的使用，比如我們可以與工作流進行對話，詢問一些運維相關的處理意見。
需要注意的是，在本例中這個步驟屬于支線任務，可做可不做，接入 Agent 的做法是讓我們對 Dify 工作流有更好的使用。并不是僅僅給自動化巡檢任務賦能，還可以一魚多吃，把工作流接入到對話應用中。如果對這個不感興趣的同學，可以直接跳過這個環節。
在接入 Agent 之前，需要發布工作流，并且“發布為工具”，如下圖所示。
在 Agent 中會通過工具調用的方式引用工作流的能力。
接著， 如下圖所示，創建 Agent。
然后，編輯 Agent 內容，如下圖所示。
提示詞的部分，如下：
接受登錄相關信息。
例如：“一共 2350 人登錄，成功 2218 人，失敗 132 人?！?得到登錄異常的處理方法。
調用工作流 login_inspect通過舉例的方式告訴 Agent 提示詞“長什么樣子”（Few-Shot），并且告訴 LLM 調用對應的工作流：login_inspect。 這個名字就是我們把工作流發布為工具的時候，起的名字。
在右上方選擇一個處理用戶自然語言的模型，這里選擇我們已經定義的 DeepSeek 模型。然后就可以在下方的輸入框中提問，讓 Agent 調用工作流給出答案了。
輸入如下問題：
一共 2350 人登錄，成功 2218 人，失敗 132 人。提問之后，可以通過下圖看到結果。
很明顯，在輸入與登錄相關的信息之后，Agent 會調用工作流 login_inspect ，并且從工作流返回的字段 "tool response" 明顯看到返回的信息。 在最下方，是 Agent 結合 LLM 潤色得到的最終回復。
當然，我們可以通過右上角的“發布”按鈕，將 Agent 發布給其他的運維人員使用。
編寫定時任務腳本
完成工作流的開發之后，我們需要由一個定時任務獲取 Prometheus Server 的指標數據，也就是用戶登錄的數據，然后再調用 Dify 工作流對其進行詳細方案的分析。
具體而言，腳本的主要作用是對用戶登錄情況進行自動化巡檢與報告生成。它會定期從 Prometheus 中獲取關鍵指標，包括總登錄次數、登錄成功次數和失敗次數，并通過指定路徑的 jq 工具進行數據解析與匯總。隨后，腳本會將整理后的結果轉換為結構化文本，調用本地 Workflow 服務進行進一步分析，并輸出直觀的中文結果。為了保證結果的可追溯性，腳本會將每次的分析結果按時間戳保存為 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"
# ===== 日志函數 =====
log() {
TIMESTAMP=$(date +"%Y-%m-%d %H:%M:%S")
echo "[$TIMESTAMP] $1" | tee -a "$LOG_FILE"
}
log "腳本開始執行"
# ===== 查詢 Prometheus 指標 =====
log "查詢 Prometheus: 總登錄次數"
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 "總登錄次數: $TOTAL_LOGINS"
log "查詢 Prometheus: 登錄成功次數"
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 "登錄成功次數: $SUCCESS_LOGINS"
log "查詢 Prometheus: 登錄失敗次數"
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 "登錄失敗次數: $FAIL_LOGINS"
# ===== 生成 Workflow 輸入文本 =====
INPUT_TEXT="用戶登錄統計：總登錄次數: ${TOTAL_LOGINS}，登錄成功: ${SUCCESS_LOGINS}，登錄失敗: ${FAIL_LOGINS}"
SAFE_INPUT_TEXT=$(echo "$INPUT_TEXT" | $JQ_CMD -Rs .)
log "生成 Workflow 輸入文本: $INPUT_TEXT"
# ===== 調用 Workflow =====
log "?? 正在調用 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 原始響應: $RESPONSE"
# ===== 輸出結果 =====
echo "? Workflow 返回結果："
RESULT=$(echo "${RESPONSE}" | $JQ_CMD -r '.data.outputs["tool response"]')
echo "$RESULT"
log "Workflow 中文結果: $RESULT"
log "腳本執行完成"
# ===== 保存報告 =====
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 結果已保存到: $REPORT_FILE"
log "腳本執行完成"腳本分為四步：
配置與日志
定義了 API_KEY、Prometheus 地址、Workflow 服務地址、日志文件等基本參數。
使用 log() 函數統一記錄執行過程和結果，保證排查時可追溯。
采集指標
通過 curl 調用 Prometheus 的 HTTP API，分別獲取三個核心指標：
- 總登錄次數
- 登錄成功次數
- 登錄失敗次數
用 jq 解析 Prometheus 返回的 JSON 數據，并計算對應數值。
生成分析輸入 & 調用 Workflow
將三個指標拼接成一句中文描述（如“總登錄次數 100，成功 95，失敗 5”）。
通過 jq 將文本轉為 JSON 安全字符串。
調用本地運行的 Workflow 服務接口，把指標數據作為輸入，等待返回分析結果。
結果輸出與歸檔
在終端和日志中打印 Workflow 的中文結果。
同時將結果保存為 JSON 文件，按時間戳命名，存放在 report 目錄下，方便后續留存和比對。
細心的你可能發現了，這個腳本中定義了工作流的 key，我們需要通過它調用 Dify 的工作流。下面就來看看如何申請這個 Key。
生成 workflow API 密鑰
如下圖所示，在 Dify 工作室右上角點擊“API 密鑰” 按鈕，在彈出框中選擇“創建密鑰”，請保存好你的密鑰。
生成好的密鑰大概長下面這個樣子。
app-QO7DYA9uxq2HApfSVSKKHC0Y接著可以通過如下命令執行腳本，從而測試能否調用 Dify 的工作流。
執行腳本命令如下：
chmod +x inspector.sh
./inspector.sh如果執行完畢之后，在 report 目錄下看到 report 文件，說明執行成功了。
配置定時任務
由于我用的 Mac OS，為了方便使用 crontab 協助我完成定時任務的執行。crontab 是類 Unix 操作系統（如 Linux、macOS）中用于定時執行任務的工具，其核心是通過 crontab 命令管理定時任務列表（即 crontab 文件），并由系統后臺的 cron 守護進程持續監聽、觸發任務。用戶可通過 crontab -e 編輯任務，每條任務需遵循 “分 時 日 月 周 命令” 的固定時間格式（例如 0 2 * * * /home/backup.sh 表示每天凌晨 2 點執行備份腳本），支持使用通配符（如 * 代表所有值）、范圍符（如 1-5 代表周一到周五）靈活設定執行周期，適用于日志切割、數據備份、系統監控等重復性操作，無需人工干預即可實現任務的自動化定時運行。
通過如下命令，打開當前用戶的 crontab 文件（通常是 vim / nano）。
crontab -e在 crontab 中輸入如下內容，指定要執行的文件和日志輸出文件。
*/5 * * * * /bin/bash /Users/cuihao/docker/dify/inspector.sh >> /Users/cuihao/docker/dify/inspector.log 2>&1這里執行的文件就是我們的inspector.sh 腳本文件，它幫助我們調用 Dify 的工作流，并且返回詳細的方案信息，接著生成報告。另外日志輸出文件，是針對 crontab 的執行情況的日志。
查看 crontab 任務：
crontab -l查看 crontab 任務執行狀態：
sudo launchctl list | grep cron測試整體流程
好了，萬事俱備只欠東風，通過如下程序生成 Metrics 指標數據寫入到 Prometheus 中，這樣就有了測試數據。
from prometheus_client import start_http_server, Counter
import random
import time
# 定義登錄指標（與告警規則中的標簽完全匹配）
LOGIN_COUNT = Counter(
'user_login_total',
'用戶登錄總次數及狀態統計',
['user_type', 'login_status', 'ip_region'] # 包含規則中用到的user_type、login_status
)
def simulate_login(failure_rate=0.2):
"""模擬登錄行為，可指定失敗率（默認20%，確保觸發15%閾值）"""
# 70%普通用戶，30%管理員（與規則2的admin類型匹配）
user_type = random.choices(['normal', 'admin'], weights=[0.7, 0.3])[0]
# 按指定失敗率生成登錄狀態（默認20%失敗，超過15%閾值）
login_status = random.choices(
['success', 'failed'],
weights=[1 - failure_rate, failure_rate]
)[0]
# 隨機地區（規則未用到，但不影響）
ip_region = random.choice(['beijing', 'shanghai', 'guangzhou'])
# 記錄指標（標簽與規則中的篩選條件完全對應）
LOGIN_COUNT.labels(
user_type=user_type,
login_status=login_status,
ip_reginotallow=ip_region
).inc()
# 打印失敗日志，方便觀察觸發情況
if login_status == 'failed':
print(f"[失敗] 用戶類型: {user_type}，地區: {ip_region}")
if __name__ == '__main__':
# 啟動指標服務（9091端口，與Prometheus配置一致）
start_http_server(9091)
print("Exporter運行中：http://localhost:9091/metrics")
print("開始模擬登錄（高失敗率，確保觸發告警）...")
# 持續模擬登錄（每0.5秒1次，快速累積數據，匹配規則的2分鐘窗口）
while True:
simulate_login(failure_rate=0.3) # 20%失敗率，超過15%閾值
time.sleep(0.5)此時，crontab 已經開始運行了，由于我們設置的是 5 分鐘執行一次crontab 定義的inspector.sh 腳本。 所以，稍微等待就可以看看inspector_crontab.log 文件中 crontab 任務的執行情況了。
如下所示：
[2025-09-16 15:45:00] 腳本開始執行
[2025-09-16 15:45:00] 查詢 Prometheus: 總登錄次數
[2025-09-16 15:45:00] 總登錄次數: 10113
[2025-09-16 15:45:00] 查詢 Prometheus: 登錄成功次數
[2025-09-16 15:45:00] 登錄成功次數: 7117
[2025-09-16 15:45:00] 查詢 Prometheus: 登錄失敗次數
[2025-09-16 15:45:00] 登錄失敗次數: 2996
[2025-09-16 15:45:00] 生成 Workflow 輸入文本: 用戶登錄統計：總登錄次數: 10113，登錄成功: 7117，登錄失敗: 2996
[2025-09-16 15:45:00] ?? 正在調用 Workflow ...
......
### **電商平臺登錄異常應急響應執行報告**
**報告生成時間：** 2023-10-27 15:00
**事件主題：** 電商平臺登錄接口失敗率異常告警
**報告人：** 運維工程師
---
#### **一、 事件摘要**
* **事件發生時間：** 2023-10-27 14:30 (監控系統觸發告警)
* **事件級別：** **緊急異常（5級）**
* **核心指標：**
* 登錄請求總數：11,888
* 登錄失敗數：3,527
* **計算失敗率：** (3,527 / 11,888) * 100% ≈ **29.7%**
* **事件現象：** 平臺登錄接口出現大量失敗請求，失敗率高達29.7%，遠超2%的健康閾值，嚴重影響用戶正常登錄體驗，存在重大業務風險。
* **初步判斷：** 此失敗率屬于災難性級別，可能原因包括：認證服務集群故障、數據庫連接池耗盡、緩存（Redis）失效或過載、網絡分區、或遭受惡意撞庫攻擊等。由于篇幅有限，我們展示一部分的 crontab 日志。從日志中可以看出，腳本采集到 Prometheus Server 的 Metrics 數據，以及啟動 Dify 工作流都成功了，并且看到了詳細的處理方案和執行步驟。
最后，來到 report 目錄下面。如圖所示，可以看到以 report+時間為名字的 json 文件被創建，并且文件中可以看到報告內容。
作者介紹
崔皓，51CTO社區編輯，資深架構師，擁有18年的軟件開發和架構經驗，10年分布式架構經驗。
