Azure SRE Agent 中的 HTTP 觸發程序

Azure SRE 代理中的 HTTP 觸發器是外部系統用來按需呼叫代理的 webhook 端點。當持續整合與持續交付（CI/CD）管線失效、警示工具偵測異常，或任何 HTTP 用戶端發送 POST 請求時，代理程式會立即接收事件上下文並開始工作。

問題是：警報和流程故障需要手動分類

您的小組已經擁有像 Datadog、Dynatrace、Jira、Splunk 和 Grafana 這些用於警示、可檢視性與工作流程的工具，以及容易發生問題的 CI/CD 管線。當出錯時，每次的反應都是一樣的：

一位工程師被呼叫： 工程師會打開監控工具，讀取警示，然後手動打開多個儀表板的日誌、指標和部署歷史，找出發生了什麼事。
管道失敗：有人必須停下手邊的工作，檢查建置輸出、與最近變更的關聯，並決定是要回滾或進行修復。
上下文脈絡零散： Datadog 警示顯示：「prod-ap 上的 CPU 使用率激增。」若要找出根本原因，需要對三個服務的記錄建立關聯，檢查近期部署，並檢閱 Dynatrace 的追蹤。

HTTP 觸發器的運作方式

HTTP 觸發器讓你能將任何支援 webhook 的工具直接連接到你的 SRE 代理實例。偵測問題的系統，無論是 Datadog 警示、Dynatrace 異常、Jira 工作流程轉換或管線故障，都不會由工程師手動篩選，而是指示代理人調查。上下文會自動傳遞。

每個觸發程序都是 Agent 上具唯一 URL 的具名 Webhook 端點。當外部系統透過 HTTP POST呼叫該 URL 時，代理程式會執行觸發器設定的提示符，該提示符會被請求主體中的任何 JSON 資料豐富。

關鍵概念

概念	運作方式
Trigger	一個命名端點，帶有一個提示詞、一個指定的代理（預設代理或子代理），以及一個自治層級（自主代理或審查）。
觸發 URL	當你建立觸發器時產生的獨特 webhook URL。此 webhook URL 是外部工具呼叫的結果。
JSON 上下文	可選的 JSON 主體會隨 `POST` 請求一起發送。它成為代理人提示的一部分，因此擁有完整的上下文。
執行歷程記錄	每次呼叫都會記錄時間戳記、執行緒連結及成功或失敗狀態。
啟用/停用	切換觸發程序的開啟或關閉而不是刪除。禁用觸發器會返回404。

啟動觸發器

使用 HTTP POST 請求調用觸發器 URL：

curl -X POST \
  https://your-agent.sre.azure.com/api/v1/httptriggers/trigger/<TRIGGER_ID> \
  -H "Authorization: Bearer <ARM_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "source": "datadog",
    "alert_title": "High error rate on checkout-api",
    "severity": "critical",
    "service": "checkout-api",
    "region": "eastus2",
    "metric": "error_rate",
    "value": "8.2%",
    "threshold": "5%"
  }'

部分	內容
URL	觸發程序的唯一 Webhook 端點。在觸發詳細檢視中找到觸發網址。
Authorization	Azure Resource Manager 持有者權杖。關於觸發呼叫，請參見認證。
內容類型	如果你要傳送 JSON 正文，應該是 `application/json` 這樣。
JSON 主體（可選）	任何你想讓客服人員看到的 JSON 資料。這些資料成為代理提示的一部分。請包含協助客服人員調查的上下文，例如警示名稱、嚴重程度及受影響的服務。

JSON 正文是可選的。如果你呼叫觸發器但沒有實體，代理程式只會用觸發器設定的提示符執行。具備正文時，Agent 會同時看到提示和您傳送的資料。

觸發程序調用的驗證

觸發程序端點需要Authorization: Bearer <TOKEN>標頭中的 Azure Resource Manager 持有者權杖。呼叫者需要 Microsoft.App/agents/threads/write 取得代理資源的權限。

取得代幣的方法

方法	最適合用於	詳細資料
Service Principal	CI/CD 管線、自動化系統	建立應用程式註冊，在 Agent 資源上指派角色，並使用用戶端認證流程取得權杖。
受控識別	Azure-hosted services （Azure Functions， Azure Virtual Machines， Azure Container Apps）	沒有需要管理的秘密。 Azure 資源會自動進行驗證。
Azure CLI	測試與開發	執行 `az account get-access-token --resource https://management.azure.com --query accessToken -o tsv`。

連接不支援 Azure 認證的外部工具

像 Datadog、Dynatrace、Jira 和 Splunk 這類工具會用自己的認證格式發送 webhook，而不是 Azure Resource Manager 的憑證。為了彌補這個差距，請使用以下其中之一的中介機構。

中介	運作方式
Azure Functions	接收 webhook 之後，利用其管理身份取得 Azure 資源管理員令牌，並將該呼叫轉發至觸發 URL。
Azure Logic 應用程式	無需程式碼的工作流程，能從任何來源接收 webhook，並呼叫內建 Azure Resource Manager 認證的 Azure API。
Azure API Management	它位於觸發程序 URL 前方，透過原則處理權杖驗證與轉換。

回應

{
  "message": "HTTP trigger execution initiated",
  "executionTime": "2026-03-13T10:30:00Z",
  "threadId": "thread-abc123",
  "success": true
}

觸發器會立即回傳 HTTP 202（已接受）。代理程式以非同步方式處理請求。

這種做法有什麼不同

HTTP 觸發器能將你現有的警示和 CI/CD 工具直接連接到你的代理程式，無需工程師介入。偵測問題的系統會告訴客服人員調查，並自動傳達完整的上下文。不需要分頁、不需要切換儀表板，也不需要手動蒐集內容。

前後比較

之前（手動分流）	之後 (HTTP 觸發程序)
觸發 Datadog 警示。工程師被呼叫，打開三個儀表板，開始調查。	Datadog webhook 呼叫觸發程序。代理人會自動調查並發布調查結果。
管線破裂。工程師會檢查建造日誌、審查PR，並決定下一步。	管線失敗處理常式呼叫觸發程序。代理人會分析故障並列出根本原因。
Dynatrace 偵測異常。工程師會手動對應不同服務。	結合異常背景脈絡的 Dynatrace webhook 呼叫觸發程序。代理程式會將日誌、指標和部署進行關聯。

排程任務與 HTTP 觸發器

排定的任務	HTTP 觸發程序
以時間為基礎（按時間順序安排）。	事件驅動 (按需提供)。
無論事情是否發生，它都會執行。	只有被召喚時才會跑。
每次執行都沒有外部輸入。	插入到每次叫用中的酬載資料。
最適合反覆檢查。	最適合於事件驅動的反應。

兩者一起使用。使用排程任務進行主動監控，HTTP 觸發器用於被動事件處理。

應用案例

CI/CD 管線整合

當部署管線失敗時，呼叫代理程式來分析失敗：

# In your pipeline's failure handler
curl -X POST "$AGENT_TRIGGER_URL" \
  -H "Authorization: Bearer $ARM_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"pipeline\": \"$PIPELINE_NAME\", \"run_id\": \"$RUN_ID\", \"error\": \"$ERROR_MESSAGE\"}"

警示驅動調查

整合您的警示系統，以便在關鍵警示觸發時自動展開調查：

{
  "alert_name": "Error rate > 5%",
  "severity": "P1",
  "service": "checkout-api",
  "region": "eastus2",
  "start_time": "2026-03-13T10:15:00Z"
}

部署合規檢查

部署完成後，觸發合規審查：

curl -X POST "$AGENT_TRIGGER_URL" \
  -H "Authorization: Bearer $ARM_TOKEN" \
  -d '{"deployment_id": "deploy-456", "environment": "production", "changes": ["config update", "image bump"]}'

API 參考資料

端點	方法	說明
`/api/v1/httptriggers`	`GET`	列出所有觸發因素。
`/api/v1/httptriggers/create`	`POST`	建立新的觸發點。
`/api/v1/httptriggers/{id}`	`GET`	取得觸發細節。
`/api/v1/httptriggers/{id}`	`PUT`	更新觸發屬性。
`/api/v1/httptriggers/{id}`	`DELETE`	刪除觸發器。
`/api/v1/httptriggers/{id}/enable`	`POST`	啟用觸發器。
`/api/v1/httptriggers/{id}/disable`	`POST`	關閉觸發器。
`/api/v1/httptriggers/{id}/execute`	`POST`	手動操作扳機。
`/api/v1/httptriggers/{id}/executions`	`GET`	取得執行紀錄。
`/api/v1/httptriggers/trigger/{id}`	`POST`	外部 webhook 端點。

Troubleshooting

觸發程序傳回 404

確認觸發器是否已啟用。 禁用觸發器會返回404。
請檢查網址中的觸發 ID 是否正確。

401 未經授權

令牌受眾必須與 SRE 代理應用程式 ID 相符，而非 https://management.azure.com。
要取得測試用的 token ，請使用 az account get-access-token --resource 59f0a04a-b322-4310-adc9-39ac41e9631e --query accessToken -o tsv。

觸發器執行，但代理人沒有行動

請查看代理提示。空白提示可能無法產生有用的輸出。
確認所選子代理人擁有執行任務所需的工具。
請查看執行紀錄中的錯誤細節。

限制

資源	Limit
每個 Agent 的觸發程序數	沒有硬性限制。
每次執行的最大回合數	250回合。
Authentication	每個觸發網址都需要持有人令牌。

意見反應

此頁面對您有幫助嗎？

Last updated on 2026-04-29