針對 Azure 監視器警示中的問題進行疑難排解
本文討論 Azure 監視器警示和通知中的常見問題。 Azure 監視器警示 會在監視數據中找到重要條件時主動通知您。
如需針對 Azure 計量或記錄搜尋警示進行疑難解答的特定資訊，請參閱：
疑難解答之前
如果警示如預期般引發，但適當的通知未如預期般執行， 請先測試您的動作群組 ，以確保其已正確設定。
否則，請使用本文其餘部分的信息來針對您的問題進行疑難解答。
我未收到預期的電子郵件
如果您在 Azure 入口網站 中看到引發的警示，但未收到您設定的電子郵件，請遵循下列步驟：
警示處理規則是否隱藏電子郵件？
按兩下入口網站中引發的警示，並查看隱藏 動作群組的 [歷程記錄] 索引標籤：
動作類型是否為「電子郵件 Azure Resource Manager 角色」？
此動作只會查看訂用帳戶範圍和類型 為 User 的 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
這些動作都沒有速率有限。
我未收到預期的簡訊、語音電話或推播通知
如果您在入口網站中看到引發的警示，但未收到您設定的SMS、語音通話或推播通知，請遵循下列步驟：
警示處理規則 是否隱藏了該動作？
按兩下入口網站中引發的警示，並查看隱藏 動作群組的 [歷程記錄] 索引標籤：
如果那是無意的行為，您可以修改、停用或刪除警示處理規則。
簡訊/語音：您的電話號碼是否正確？
檢查國家/地區代碼或電話號碼的簡訊動作是否有打字錯誤。
簡訊/語音：您是否已超過服務限制？
每個電話號碼每五分鐘一次的簡訊和語音通話費率限制不超過一個通知。 如果您通過此閾值，則會捨棄通知。
- 語音通話 - 檢查您的通話記錄，並查看您在前五分鐘內是否有與 Azure 不同的通話。
- SMS - 檢查您的 SMS 歷程記錄是否有訊息，指出您的電話號碼速率有限。
如果您想要在沒有速率限制的情況下接收大量通知，請考慮使用不同的動作，例如：
- Webhook
- 邏輯應用程式
- Azure 函式：
- 自動化 Runbook
這些動作都沒有速率有限。
簡訊：您是否不小心取消訂閱動作群組？
開啟您的 SMS 歷程記錄，並檢查您是否退出宣告此特定動作群組的 SMS 傳遞（使用 DISABLE action_group_short_name 回復），或從所有動作群組（使用 STOP 回復）。
若要再次訂閱，請傳送相關的SMS命令（ENABLE action_group_short_name或 START），或從動作群組中移除SMS動作，然後再重新新增。 如需詳細資訊，請參閱動作群組中的簡訊警示行為。
您不小心封鎖了手機上的通知嗎？
大部分的行動電話都可讓您封鎖來自特定電話號碼或短代碼的電話或簡訊，或封鎖來自特定應用程式 (例如 Azure 行動應用程式) 的推播通知。 若要檢查您是否意外封鎖了電話上的通知，請搜尋您電話作業系統和型號的特定文件，或使用不同的電話和電話號碼進行測試。
預期的動作未觸發
如果您在入口網站中看到引發的警示，但其設定的動作未觸發，請遵循下列步驟：
警示處理規則是否隱藏動作？
按兩下入口網站中引發的警示，並查看隱藏 動作群組的 [歷程記錄] 索引標籤：
如果那是無意的行為，您可以修改、停用或刪除警示處理規則。
Webhook 觸發程式嗎？
來源IP位址是否遭到封鎖？
將 Webhook 從呼叫的 IP 位址新增至您的 allowlist。
您的 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 資源未在其活動記錄事件中寫入您要尋找的欄位，這些欄位就不會包含在對應的警示中。
電子郵件、SMS 或推播通知中缺少自定義屬性。
自定義屬性只會傳遞至動作的承載，例如 Webhook、Azure 函式或邏輯應用程式。 通知中不會包含自定義屬性（電子郵件/SMS/push）。
警示處理規則未如預期般運作
如果您在入口網站中看到引發的警示，但相關的警示處理規則無法如預期般運作，請遵循下列步驟：
是否啟用警示處理規則？
檢查 [警示處理規則狀態] 字段，確認已啟用相關的動作角色。 根據預設，入口網站只會顯示已啟用的警示規則，但您可以變更篩選以顯示所有規則。
如果未啟用，您可以選取警示處理規則並按下 [啟用] 來啟用警示處理規則。
這是服務健康情況警示嗎？
服務健康情況 警示不會受到警示處理規則的影響。 因此，如果您已針對包含服務健康情況警示的範圍設定警示處理規則，而服務健康情況警示位於範圍內，則警示處理規則不會影響它們。
警示處理規則是否處理您的警示？
在入口網站中選取引發的警示，並查看 [歷程記錄 ] 索引標籤，以查看是否已處理警示處理規則。
以下是隱藏所有動作群組的警示處理規則範例：
以下是新增另一個動作群組的警示處理規則範例：
警示處理規則範圍和篩選是否符合引發的警示？
如果您認為警示處理規則應該已引發但未引發，或它不應該引發，但已引發，請仔細檢查警示處理規則範圍和篩選條件，並將其與引發警示的屬性進行比較。
在 Azure 入口網站 中建立、更新或刪除警示處理規則時發生問題
如果您在嘗試建立、更新或刪除 警示處理規則時收到錯誤，請遵循下列步驟：
檢查許可權。
您應該具有 監視參與者內建角色，或與警示處理規則和警示相關的特定許可權。
檢查警示處理規則參數。