針對 Azure 監視器警示中的問題進行疑難排解
本文討論 Azure 監視器警示和通知的常見問題。 在監視資料中發現重大狀況時，Azure 監視器會主動通知您。
如需針對 Azure 計量或記錄搜尋警示進行疑難排解的特定資訊，請參閱：
疑難排解之前
如果警示如預期引發但適當的通知未如預期執行，請先測試動作群組以確保其正確設定。
否則，請使用本文其餘部分的資訊來針對您的問題進行疑難排解。
我並未收到預期的電子郵件
如果您可以在 Azure 入口網站中看到引發的警示，但未收到已設定的電子郵件，請遵循下列步驟：
警示處理規則是否隱藏了該電子郵件？
按一下入口網站中引發的警示，然後查看記錄標籤中是否有隱藏的動作群組：
![[警示歷程記錄] 索引標籤的螢幕擷取畫面，並經過警示處理規則的歸併。](media/alerts-troubleshoot/history-tab-alert-processing-rule-suppression.png)
動作類型是否為「電子郵件 Azure Resource Manager 角色」？
此動作只會查看位於訂用帳戶範圍內、以及 [使用者]或 [群組] 類型的 Azure Resource Manager 角色指派。 請確定您已在訂用帳戶層級而不是在資源層級或資源群組層級指派角色。
您的電子郵件伺服器和信箱是否接受外部電子郵件？
確認來自這三個地址的電子郵件不會遭到封鎖：
- azure-noreply@microsoft.com
- azureemail-noreply@microsoft.com
- alerts-noreply@mail.windowsazure.com
內部郵寄清單或通訊群組清單通常會封鎖來自外部電子郵件地址的電子郵件。 請確保您允許來自上述電子郵件地址的郵件。 若要進行測試，請將一般工作電子郵件地址 (而非郵寄清單) 新增至動作群組，並查看警示是否送達該電子郵件。
收件匣規則或垃圾郵件篩選器是否已處理電子郵件？
確認沒有刪除這些電子郵件的收件匣規則，或將其移至側邊資料夾。 例如，收件匣規則可能會攔截主旨中的特定寄件者或特定字組。 此外，請檢查：
- 電子郵件用戶端 (例如 Outlook、Gmail) 的垃圾郵件設定
- 電子郵件伺服器 (例如 Exchange、Microsoft 365、G-suite) 的寄件者限制/垃圾郵件設定/隔離設定
- 您電子郵件安全性設備 (例如 Barracuda、Cisco) 的設定。
您是否不小心將動作群組取消訂閱？
注意
請記住，如果您取消訂閱動作群則，則也會取消訂閱通訊群組清單中的所有成員。 您可以繼續使用通訊群組清單電子郵件地址。 不過，您必須通知通訊群組清單的使用者，如果取消訂閱，則也將取消訂閱整個通訊群組清單，而不是只有使用者本身。 解決此問題的作法是在動作群組中個別新增所有使用者的電子郵件地址。 一個動作群組最多可以包含 1000 個電子郵件地址。 然後，如果特定使用者想要取消訂閱，則可以取消訂閱而不會影響其他使用者。 您將也能夠查看已取消訂用的使用者。
警示電子郵件會提供從動作群組取消訂閱的連結。 若要檢查您是否不小心取消訂閱，請進行下列任一動作：
- 在入口網站中開啟動作群組，並查看 [狀態] 欄位：
- 搜尋您的電子郵件以確認取消訂閱：
若要再次訂閱，請使用您所收到取消訂閱確認電子郵件中的連結，或從動作群組移除電子郵件地址，然後再次加以新增。
您是否因將多個電子郵件傳送至單一電子郵件地址而超過服務限制？
電子郵件的速率限制為每個電子郵件地址每小時不超過 100 封電子郵件。 如果您超過此閾值，則不會傳送其他電子郵件。 請檢查您是否收到訊息，指出您的電子郵件地址已暫時受到速率限制：
如果您想要在沒有速率限制下接收大量通知，請考慮使用不同的動作，例如：
- Webhook
- 邏輯應用程式
- Azure 函式：
- 自動化 Runbook
這些動作不會受到速率限制。
![[警示歷程記錄] 索引標籤的螢幕擷取畫面，並經過警示處理規則的歸併。](media/alerts-troubleshoot/history-tab-alert-processing-rule-suppression.png#lightbox)
我未收到預期的簡訊、語音電話或推播通知
如果您可以在入口網站中看到引發的警示，但未收到已設定的簡訊、語音電話或推播通知，請遵循下列步驟：
警示處理規則 是否隱藏了該動作？
按一下入口網站中引發的警示，然後查看記錄標籤中是否有隱藏的動作群組：
如果那是無意的行為，您可以修改、停用或刪除警示處理規則。
簡訊/語音：您的電話號碼正確嗎？
檢查國家/地區代碼或電話號碼的簡訊動作是否有打字錯誤。
簡訊/語音：您是否已超過服務限制？
簡訊和語音電話的速率限制為每個電話號碼每五分鐘不超過一則通知。 如果您通過此閾值，將不會發出通知。
- 語音電話 - 檢查您的通話記錄，並查看您在前五分鐘是否接到 Azure 的其他來電。
- 簡訊 - 請檢查您的簡訊記錄，是否有訊息指出您的電話號碼已受速率限制。
如果您想要在沒有速率限制下接收大量通知，請考量使用不同的動作，例如：
- Webhook
- 邏輯應用程式
- Azure 函式：
- 自動化 Runbook
這些動作不會受到速率限制。
簡訊：您是否不小心將動作群組取消訂閱？
開啟您的簡訊記錄，並檢查是否已選擇取消來自此特定動作群組 (使用 DISABLE action_group_short_name 回覆) 或來自所有動作群組 (使用 STOP 回覆) 的簡訊傳遞。
若要再次訂閱，請傳送相關的簡訊命令 (ENABLE action_group_short_name 或 START)，或從動作群組移除簡訊動作，然後再重新新增。 如需詳細資訊，請參閱動作群組中的簡訊警示行為。
您是否不小心封鎖了電話上的通知？
大部分的行動電話都可讓您封鎖來自特定電話號碼或短代碼的電話或簡訊，或封鎖來自特定應用程式 (例如 Azure 行動應用程式) 的推播通知。 若要檢查您是否意外封鎖了電話上的通知，請搜尋您電話作業系統和型號的特定文件，或使用不同的電話和電話號碼進行測試。
預期的動作未觸發
如果您可以在入口網站中看到引發的警示，但其設定的動作並未觸發，請遵循下列步驟：
警示處理規則是否隱藏了該動作？
按一下入口網站中引發的警示，然後查看記錄標籤中是否有隱藏的動作群組：
如果那是無意的行為，您可以修改、停用或刪除警示處理規則。
Webhook 是否觸發？
來源 IP 位址是否遭到封鎖？
將要從中呼叫 Webhook 的 IP 位址新增至允許清單。
您的 Webhook 端點是否正常運作？
請確認您已設定的 Webhook 端點正確，且端點正常運作。 檢查您的 Webhook 記錄或檢測其程式碼，以便進行調查 (例如，記錄傳入的承載)。
您是否使用正確的格式來呼叫 Slack 或 Microsoft Teams？
這些端點都需要特定的 JSON 格式。 請依照這些指示，改為設定邏輯應用程式動作。您的 Webhook 是否沒有回應或傳回錯誤？
呼叫 Webhook 動作群組時，通常會遵循下列規則：
- 叫用 Webhook 時，如果第一次呼叫失敗，則會重試至少 1 次，並在各種延遲間隔中重試最多五次 (5 次重複嘗試) (5 秒、20 秒、40 秒)。
- 第 1 到 2 次嘗試之間的延遲為 5 秒
- 第 2 到 3 次嘗試之間的延遲為 20 秒
- 第 3 到 4 次嘗試之間的延遲為 5 秒
- 第 4 到 5 次嘗試之間的延遲為 40 秒
- 第 5 到 6 次嘗試之間的延遲為 5 秒
- 如果嘗試呼叫 Webhook 失敗，則 15 分鐘內不會有任何動作群組呼叫端點。
- 重試邏輯假設可以重試呼叫。 狀態代碼：408、429、503、504，或
HttpRequestException、WebException或TaskCancellationException允許重試呼叫。
- 叫用 Webhook 時，如果第一次呼叫失敗，則會重試至少 1 次，並在各種延遲間隔中重試最多五次 (5 次重複嘗試) (5 秒、20 秒、40 秒)。
動作或通知發生多次
如果您收到一次以上的警示通知 (例如電子郵件或簡訊)，或警示的動作 (例如 Webhook 或 Azure 函式) 已觸發多次，請遵循下列步驟：
這真的是相同的警示嗎？
在某些情況下，會在大約同一時間同時引發多個類似的警示。 因此，可能看起來像相同的警示多次觸發其動作。 例如，活動記錄警示規則可能設定為在事件啟動和完成 (成功或失敗) 時引發；且不會篩選 [事件狀態] 欄位。
若要檢查這些動作或通知是否來自不同的警示，請檢查警示詳細資料，例如其時間戳記和警示識別碼或其相互關聯識別碼。 或者，在入口網站中檢查引發的警示清單。 如果情況如此，您將需要調整警示規則邏輯，否則請設定警示來源。
動作會在多個動作群組中重複嗎？
當警示引發時，其每個動作群組都會獨立處理。 因此，如果動作 (例如電子郵件地址) 出現在多個已觸發的動作群組中，每個動作群組就會呼叫一次動作。
若要檢查已觸發的動作群組，請查看警示記錄索引標籤。您會看到警示規則中已定義兩個動作群組，以及藉由警示處理規則新增至警示的動作群組：
動作或通知具有非預期的內容
是否發生中斷而觸發使用後援電子郵件提供者？
動作群組使用兩個不同的電子郵件提供者以確保電子郵件通知傳遞。 主要電子郵件提供者具有復原性且快速，但偶而可能會發生中斷。 發生中斷時，次要電子郵件提供者會處理電子郵件要求。 次要提供者僅是後援解決方案。 由於提供者的差異，自次要提供者傳送的電子郵件可能有降級的電子郵件體驗。 降級會導致電子郵件格式和內容稍有不同。 由於電子郵件範本在兩個系統中不同，因此無法在兩個系統間維持對等。
後援解決方案產生的通知包含備註，指出：
「這是降級的電子郵件體驗。 這表示格式可能稍有不同或可能遺漏詳細資料。 如需降級電子郵件體驗的詳細資訊，請參閱這裡。」
如果您的通知未包含此備註且收到警示，但相信某些欄位遺失或不正確，請檢查承載格式。
設定警示規則時使用的格式為何？
每個動作類型 (電子郵件、Webhook 等) 都有兩種格式 – 預設、舊版格式，以及常見結構描述格式。 當您建立動作群組時，您可以指定動作的格式。 動作群組中的不同動作可能有不同的格式。
例如，針對 Webhook 動作：
檢查在動作層級指定的格式是否符合您的預期。 例如，您可能已開發回應警示 (Webhook、函式、邏輯應用程式等) 的程式碼，其預期為一種格式，但稍後在動作中，您或其他人指定了不同的格式。
此外，檢查適用於活動記錄警示、適用於記錄搜尋警示 (Application Insights 和記錄分析)、適用於計量警示、適用於常見的警示結構描述，以及適用於已淘汰的傳統計量警示的承載格式 (JSON)。
記錄搜尋警示通知不包含搜尋解果。
自記錄搜尋警示 API 2021-08-01 版開始，已從警示通知承載中移除搜尋結果。 搜尋結果僅適用於使用舊版 API (2018-04-16) 建立的警示規則。 依預設，透過 Azure 入口網站建立的新警示規則將使用較新版本建立規則。 請依照記錄警示規則建立體驗的變更的指示，了解使用更新版本的變更和建議調整。
針對已解決的記錄搜尋警示通知，MetricValue 欄位包含「NULL」。
這是原廠設定。 具狀態記錄搜尋警示會使用以時間為基礎的解決邏輯，而非以值為基礎的邏輯。 警示是因為時間經過而獲得解決，並非由任何值解決，因此 Azure 監視器會傳送 NULL 計量值。
維度清單為空白或警示標題不包含維度名稱
當您有未傳回結果的記錄搜尋警示規則時，警示可以如預期引發，但維度清單為空白或警示標題不包含維度名稱。 當查詢未傳回資料列時，資源識別碼欄位 (這是填入維度和標題欄位的基礎) 為空白。
活動記錄警示中遺漏資訊
活動記錄警示以寫入至 Azure 活動記錄的事件為基礎，例如建立、更新或刪除 Azure 資源的事件、服務健康狀態和資源健康情況事件，或 Azure Advisor 和Azure 原則的結果。 如果您收到以活動記錄為基礎的警示，但您需要的部分欄位遺失或不正確，請先檢查活動記錄其中的事件。 如果 Azure 資源未在其活動記錄事件中寫入您要尋找的欄位，則這些欄位不會包含在對應的警示中。
電子郵件、簡訊或推播通知中遺漏自訂屬性。
自訂屬性僅會傳遞至動作的承載，例如 Webhook、Azure 函數或邏輯應用程式。 通知 (電子郵件/簡訊/推播) 中不會包含自訂屬性。
警示處理規則未如預期運作
如果您可以在入口網站中看到引發的警示，但相關的警示處理規則未如預期般運作時，請遵循下列步驟：
是否啟用警示處理規則？
檢查警示處理規則狀態欄位，以確認已啟用相關的動作角色。 依預設，入口網站只會顯示已啟用的警示規則，但您可以變更篩選來顯示所有規則。
如果未啟用，您可以加以選取並按一下 [啟用] 來啟用警示處理規則。
是否為服務健康狀態警示？
警示處理規則不會影響服務健康狀態警示。 因此，如果您已針對包含服務健康狀態警示的範圍設定警示處理規則，而服務健康狀態警示位於範圍內，警示處理規則也不會影響這些服務健康狀態警示。
警示處理規則是否處理您的警示？
選取入口網站中引發的警示，然後查看 [歷程記錄] 索引標籤以了解是否已處理警示處理規則。
以下是隱藏所有動作群組的警示處理規則範例：
以下是新增其他動作群組的警示處理規則範例：
警示處理規則範圍和篩選條件是否符合引發的警示？
如果您認為警示處理規則應該已引發但卻未引發，或不應該引發但卻已引發，請仔細檢查警示處理規則範圍和篩選條件，並將其與引發警示的屬性比較。
在 Azure 入口網站中建立、更新或刪除警示處理規則時發生問題
如果您在嘗試建立、更新或刪除警示處理規則時收到錯誤，請遵循下列步驟：
檢查權限。
您應該具有監視參與者內建角色，或與警示處理規則和警示相關的特定權限。
檢查警示處理規則參數。